API Shouldn't Redirect HTTP to HTTPS

There's absolutely nothing you can do to prevent an active MITM attack over HTTP

I'd argue your reasoning is incorrect. By the time your service is developed you would have already changed it to https, as during development every time you tried your API keys sent via http got disabled. So an in-the-wild MITM would never get to see your http request

  > that's more secure, but still not bulletproof

Nothing could possibly be bulletproof. You sent a key over the wire unencrypted. You were in trouble before the data even got to the server to do anything about it.

This approach is a practical choice based on the reality that the bulk of unencrypted traffic is not being actively mitmed and is at most being passively collected. Outside of actually developing cryptosystems, security tends to be a practical affair where we are happy building systems that improve security posture even if they don't fix everything.

One of the approaches mentioned in the article is to just not listen on port 80. Supposedly that’s equally good because the connection should get aborted before the client has the chance to actually send any API keys.

But is that actually true? With TCP Fast Open, a client can send initial TCP data before actually learning whether the port is open. It needs a cookie previously received from the server to do so, but the cookie is not port-specific, so – assuming the server supports Fast Open – the client could have obtained the cookie from a prior connection over HTTPS or any other valid port. That’s the impression I get from reading the RFC, anyway. The RFC does mention that clients should distinguish between different server ports when caching refusals by the server to support Fast Open, but by that point it’s too late; the data may have already been leaked.

Well, nothing you do on the server side will protect a client willing to use http: when an MITM is present: the client can still connect to the MITIM, give away its credentials, and your server won't know.

Still, I agree that this is a very good way to teach your users to not start with http:! And that this is what one should do.

If a malicious party has access to the API key, it should be revoked regardless

This is just a run-of-the-mill DoS attack, with the astronomically unlikely jackpot of additionally invaliding a random unknown user's API key when you get a hit.

If the API key is a UUID or similar in complexity, they'd have to send 5.3 undecillion API keys to make sure all of them were invalidated.

So yes, it would open the door to revoking random API keys, but that's not a bad thing; when using an API key, you should be ready to rotate it at any point for any reason.

You need to actually send them the API key, so not really.

To do that you need to guess or steal the API keys.

Denial of service by blocking API keys is really your happy case when someone malevolent has your API keys.

I mean... it is a lot easier to do, than to program a procedure to revoke an api key.

What about things like unencrypted websockets? Or raw TCP/UDP connections?

It should, but additional server-side mitigations are good for defense in depth. There may be people using a different client-side library, maybe because they use a different programming language.

Best kind of correct.

• It allows retro computers to connect.

• It allows very low power embedded devices to connect without extra overhead.

• It's not a real security concern if you're on a private network.

Even for non-enterprise use cases

I don't think non-enterprise, non machine use cases should be automatically handles, though. Attempting client upgrade is better than not, but we should be more clear about whether our devices are acting safely, i.e. calling out the change, and in the case of http local usage, reminding to use visible, out of band verification methods.

Of course this only works if the default is secure, but I am glad that browser still let me go unencrypted when I really need to, I prefer the giant warning banners...

If that's your threat model then CA TLS is going to make things even worse for you because now the nation state pressure can be centralized and directed through the CA.

There are trade-offs but HTTP has it's place. HTTP is far easier to set up, more robust, far more decentralized, supports far more other software, and has a longer lifetime. For humans who aren't dealing with nation state threat models those attributes make it very attractive and useful.

We should not cargo cult the requirements for a multi-national business that does monetary transactions and sends private information with a website run by a human person for recreation and other humans. There is more to the web than commerce and we should design for human persons as well as corporate persons.

Dogma is how religion works, not engineering. If someone doesn't believe the benefit is worth the cost, they can and should question the practice. Blind obedience to a dogma of "just do HTTPS" is not a reasonable approach.

Does HTTPS also hide the URL request in most logging systems? You can always see the domain (api.example.com) but you cannot see the URL? The benefit being it hides an API key if included in the URL?

Hypothetically speaking, plain HTTP transport even for "read only" content, can be a problem if it can be manipulated in transit.

Let's take a weather service. Seems like weather information is a read-only immutable fact and should not be something that needs protection from MITM attacks. You want to reach the largest audience possible and your authoritative weather information is used throughout the world.

One day, an intermediary system is hijacked which carries your traffic, and your weather information can be rewritten in transit. Your credibility for providing outstanding data is compromised when you start serving up weather information that predicts sunny skies when a tornado watch is in effect.

Additionally, you have now leaked information related to the traffic of your users. Even if the request is just vanilla HTTP-only, an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic. They also inject a javascript payload into your traffic that starts computing bitcoin hashes and you are blamed for spreading malware.

In general, HTTPS protects both your interests and those of your users, even for benign data that doesn't necessarily need to sit behind "an account" or a "web login".

I guess I have to respond with the same thing over and over because there are so many people saying the same thing without reading the replies.

HTTP is better because: it lasts forever without mantainence, it's easier to learn set up with no third parties required, all software can access a HTTP website, it's low resource requirements, and HTTP+HTTPS is perfectly fine.

Whereas CA TLS only lasts a year or two without mantainence, is so complex to set up and keep running that a literal ecosystem of programs (acme, acme2, etc) exist to hide that complexity, only software within the last ~few years can access CA TLS websites because of TLS version sunsetting and root cert expirations and the like, and everyone centralizing in the same CA makes it extremely easy to apply political/social pressures for censorship in a CA TLS only browser world. Additionally requiring third party participating to set up a website makes it harder for people to learn how to run their own and it requires more compute resources.

CA TLS only feels like it should be "required" when the person can't imagine a web browser that doesn't automatically run all untrusted code sent to it. When the only types of websites the person can image are commercial or institutional rather than personal and the person believes all the web should cargo cult the requirements of commerce. Personal websites involving no monetary or private information transactions don't actually need to worry about targeted MITM and there's no such thing as open wireless access points anymore.

400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't authorized to make a request to the URL, which they aren't. Some APIs return redirects which also seems pretty reasonable.

Why do you think 403 is the wrong error code? Based on the spec it seems entirely appropriate to me:

HTTP 403 provides a distinct error case from HTTP 401; while HTTP 401 is returned when the client has not authenticated, and implies that a successful response may be returned following valid authentication, HTTP 403 is returned when the client is not permitted access to the resource despite providing authentication such as insufficient permissions of the authenticated account.[a]

Error 403: "The server understood the request, but is refusing to authorize it." (RFC 7231)

Not sure how I feel about this (extremely arbitrary) distinction. 400 Bad Request maybe implies that no matter how many times you retry the request, it will never succeed. 403 Forbidden maybe implies that some external change in the authentication system could perhaps allow the same request to succeed in the future? So I guess in that lens I can see the logic, but again, seems extremely arbitrary.

What about this then? When the request is made over insecure HTTP, revoke the API key used, but then send the usual redirect response for HSTS. Then, when/if the request gets repeated over HTTPS, notice the key is revoked and so respond to that one with 403.

HSTS is intended for browsers. For API clients the correct behavior (following curl's lead) is probably to never follow/make any redirects by default.

HSTS is a note to the browser to insist on TLS when hitting a website. It is sent as a header, with a timescale, regardless of http/https.

The HSTS header is only effective when it's received over HTTPS. And if it has taken effect, the client won't try to access HTTP anymore, so it won't even know what response it would have gotten from HTTP.

It’s a good option, but you can’t give users a reason for the failure. They might even assume your service is broken.

Because the whole point is a mitm can compromise it, and the mitm can listen on 80 regardless if you turn yours off.

I've done that myself and have consumed many others who have done it, and I don't think it's better. Much better to get a response that tells you to use https for the API. (for browser also a redirect is a must for UX, though our context here is API)

How would the endpoint prevent that?

Honestly, hard disagree. I get the push for HTTPS, but setting up HTTPS nowadays isn't fun. It's more or less 4 steps;

1. Install and run certbot (+the DNS plugin for your DNS provider).

2. Find an nginx config file on the internet that only includes the necessary ciphers to work on modern devices. Then include that config file + lines to your cert paths that certbot spits out into your nginx config.

3. Set up a generic redirect server block to send everything on port 80 to port 443.

4. Reboot nginx.

It's at least better than fiddling with openssl directly, but this isn't fun, it's busywork.

The bigger issue is that a malicious interceptor could inject javascript. The site may not use javascript, but the users almost certainly have it turned on, and accessing a non-https site means that any man in the middle can inject malicious javascript.

HTTPS is about protecting the client.

When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of:

Neither desktop firefox nor chrome seem to do this by default, at least on my Mac (actually I think I'm wrong about Firefox on desktop as well, thanks to a guestbook signer!). Maybe it's a Firefox mobile thing, rather than a modernity thing?

for the price of a free Let's Encrypt cert you can deliver much better UX

I'm going to get around to it, I promise haha.

Btw if anyone does visit the site, please do sign my guestbook: http://darigo.su/33chan (but be warned, a MITM might intercept and alter your comment!!)

not my problem!

Beyond ‘getting a moustache tattoo on your finger’ quirkiness

In that case, seems totally worth it. I, like moustache finger tattoos, am aggressively opposed to worrying about being perceived as cool. I will just have to live with being inexcusable.

Yeah, I should have clarified. Nothing to do with the article really, just a random thought. Sorry if too off-topic!

This is the somewhat depressing but accurate answer. HTTPS doesn't mean you are communicating sensitive or private data, it means you want the client to see what you send them, and not something else.

I disagree. So does Wikipedia ("where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties ... for example, an attacker within range of an Wi-Fi access point hosting a network without encryption could insert themselves as a man in the middle") and so I believe do most people.

"Active MITM" would be how you describe someone who does modify traffic.

And an attacker in each of the scenarios GP mentioned can modify traffic. (For ISP/attacker-controlled networks it's trivial; for other networks you just need to ARP spoof)

I agree that's not a case of MITM, but I do think it's fair to call sitting in range of the same Wi-Fi access point "physical access".

Eve and Mallory are both MITM, in my opinion.

You have to mitm in order to evesdrop on an encrypted channel. If you do nothing but evesdrop, isn't it still mitm? You had to actively replace & spoof the two endpoints, but that is just a technicality required by the encryption, in the end you still only evesdropped, yet it was still called mitm.

So, mere evesdropping is mitm. So, how is evesdropping on unencrypted traffic or wifi traffic meaningfully different than evesdropping by decrypt & reencrypt?

I don't think the term mitm includes a requirement that you aren't talking to who you thought you were talking to, because generally you do still talk to who you thought you were, just not directly.

The traffic may be modified along the way rather than merely copied, or one or the other endpoint may be wholly faked rather than merely relayed, but they also may not be, the attacker may simply relay everything verbatim in both directions, IE pure evesdropping, and the attack would still be called mitm.

Then again, I guess a keylogger is evesdropping and not called mitm.

What scary browser warnings do you regularly get when visiting HTTPS sites?

It’s also not just about avoiding transmitting HTML etc. in plaintext; somebody being able to inject arbitrary scripts into sites you otherwise trust is bad as well.

But as I've said above, I think the HTTP -> HTTPS redirect should have never happened at the HTTP level. If we'd done it in DNS or at least as a new HTTP header ("optional TLS available" or whatnot), we could have avoided locking out legacy clients.

all for the sake of encrypting things that were fine in plaintext

What was fine in plaintext?

because it further ingrained the user tendency to click through scary browser warnings (all for the sake of encrypting things that were fine in plaintext).

Why should there be more scary warnings when more websites use TLS? Sure, you get more scary warnings if you set your browser to "warn if it's http", but then you're asking for it.

Chrome's version of trying https first sure is annoying though.

If a site is down entirely, when chrome can't connect to port 443 it confidently declares that "the connection is not secure because this site does not support https" and gives a "continue" button. Then when you click "continue" nothing happens for a while before it finally admits there's nothing responding at all.

So it gives a misleading error and takes longer to figure out if a site is actually down.

It also says

We didn't have the guts to disable the HTTP interface for that domain altogether, so we picked next best option: all unencrypted HTTP requests made under /api now return a descriptive error message along with the HTTP status code 403.

So close and yet … their misconfigured clients will still be sending keys over unencrypted streams. Doh

Why is it better?

I can't think of large differences. What comes to mind are two human factors that both speak against it:

- Having an HTTP error page informs the developer they did something wrong and they can immediately know what to fix, instead of blindly wondering what the problem is or if your API is down/unreliable

- That page, or a config comment, will also inform the sysadmin that gets hired after you retire comfortably that HTTP being disabled is intentional. Turning something off that is commonly on might be a time bomb waiting for someone who doesn't know this to turn it back on

Edit:

Just saw this reason, that's fair (by u/piperswe) https://news.ycombinator.com/item?id=40505545

If the client can't open a TCP connection to port 80, there's no unencrypted path to send the API keys down

If that immediately errors out on the first try, though, what is the risk of the key being intercepted? The dev would never put that in production, so I'm not sure how the pros and cons stack up. I also loved this suggestion from u/zepton which resolves that concern: https://news.ycombinator.com/item?id=40505525 invalidate API keys submitted insecurely

That’s a terrible argument. If someone can run something on port 80, they have root on the machine, at which point can do whatever they want (including getting rid of whatever existing process was listening on port 80 and replacing it with their own).

I think the original question "Okay.. does nodejs fetch respect HSTS?" goes into the "not even wrong" bucket, for the reasons you point out.

HSTS really only makes sense from a browser perspective (or, rather, a "permanently installed, stateful client" perspective). For an API like fetch it doesn't even make sense as a question IMO.

Just saw you got downvoted, I have no idea why

I've noticed a gradual increase in this behavior during the past ... year maybe? I think for a lot of new people, downvoting equates disagreeing, which is not ideal.

Although, I also have no idea why someone would disagree with a neutral question like GPs, lol.

Hopefully, it's not the beginning of the end for HN as it is a great website.

So if you occasionally forget and use http when you meant https and are worried about the consequences of that, you should just implement your own HSTS checking layer?

Why not just implement your own fetch wrapper that throws if it's not an https connection?

Just do it like a web browser - when you install Chrome it comes with a list of many tens of thousands of domains that had HSTS set when GoogleBot visited it.

Same way as TLS session resumption can be handled by libraries without you having to touch it, or perhaps requiring you to specify a storage file and taking it from there

libcurl supports HSTS, but the client has to specify a file where the state should be stored https://curl.se/docs/hsts.html

Many languages/libraries use libcurl in some shape or form, but whether they set up an on-disk HSTS store or not - I don't know either.

There’s the guy that made _a_ mistake. Then there’s the guy who continues to make the same mistake over and over again.

That second person is way to common in companies that hire from the bottom of the barrel.

It might be optimistic to say that rolling over to a new key is 'at most a dozen clicks'.

Hardcoded keys are a big one. But even just hunting down all config where the key needs to change can be a major hassle. Is there some ci yaml that expects a runner to have the key in a .env file that only runs on major release? Good chance you won't realize that key exists.

Still a great idea to revoke those keys. But it will damage some customers in the short term. And they will be angry, as people often are when you demonstrate their mistake.

You can still return a response...

  400 - HTTP is unsupported, use HTTPS.

That’s something different: that’s for upgrading to TLS within the same connection. As in, approximately http://example.com/ → https://example.com:80/ (but without the URL’s scheme actually being allowed to change), whereas https://example.com/ is https://example.com:443/. I was only a child when RFC 2817 was published, but I’ve never heard of any software that supported it, other than the Internet Printing Protocol which can use it for ipp: URLs, kinda like SMTP has STARTTLS. As for the motivations of RFC 2817, they’re long obsolete: encryption should no longer be optional on these sorts of things so that the parallel secure port problem is gone (not sure when this became actual IETF policy, but I’m going to guess towards ten years ago), and the virtual hosting problem is solved by SNI (supported by everything that matters for well over a decade).

the client still doesn't know that the shared key isn't compromised. What does it even mean for either a client or server to know something is compromised? If Alice and Bob have a shared key, what can they do to ensure Mallory doesn't also have the shared key?

Of course, that is true, but TLS doesn't help with that, either. However, if a reverse proxy (especially if run by a third party) or something else like that is compromised, then HMAC won't allow you to compromise the shared key if the reverse proxy does not know the shared key (unless they can somehow trick the server into revealing it, but that is a separate issue).

An additional issue arises if it is compromised even before the client receives the key for the first time, if it is sent using the same communication channels; in that case, of course neither TLS nor HMAC will help (although certificate revocation may do in this case, but some other method will then be needed to be able to correctly trust the new certificate).

However, different services may require different levels of security (sometimes, hiding the key isn't enough; and, sometimes, encrypting the data isn't enough). How you will handle that depends on what security you require.

Yes, more like a SaaS. Maybe a solution that is tailored to selling API access. Generates a unique URL to the user, or API key, after they sign up for the API service.