Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

API Shouldn't Redirect HTTP to HTTPS

jviide.iki.fi

Post reply on HN
Print view View original

121–130 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#121

Post by jkrejcha »

taftster wrote: post #59
codepoet80 wrote: post #38

Earlier quoted context omitted.

You’ve already been shouted down, but thank you for daring to suggest this. I maintain APIs and proxies for APIs for legacy devices, and will continue to suggest that some kinds of APIs remain appropriate for HTTP access. Never do your banking this way, obviously, but where is the harm in allowing older devices to access content in a read-only fashion?

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,…

> 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.

One thing to note is that nothing about HTTPS protects against this type of attack. Assuming your API doesn't have much else going on (most services, probably), an adversary can easily see that you visited mycoolweatherapi.example regardless of if HTTPS is being used or not.

What TLS protects is higher on the network layer cake

Re: API Shouldn't Redirect HTTP to HTTPS

#122

Post by lxgr »

bigstrat2003 wrote: post #96
lxgr wrote: post #8

Completely agree, and arguably why stop at API servers? Depending on server-side HTTP -> HTTPS redirects for security reinforces/rewards bad practices (linking to HTTP, users directly entering HTTP etc.), in a way that makes users vulnerable to one of the few remaining attack vectors of "scary public Wi-Fis".

The push for "TLS all the things" was already a massive overreach that actively made security worse overall, 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). And you want to go even further ? No thank you.

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#123

Post by OJFord »

sdsd wrote: post #35

My personal website (darigo.su) doesn't have HTTPS. I just deployed it a few months ago and haven't really done much with it yet. I guess I'll have to get around to it eventually, but I find charm in small old sites that haven't implemented modern protocol stuff. My site also uses and tags all over the place. Maybe I'll do some more quirky anachronisms, like only serve the site via HTTP 1.0 or something. Who knows. S…

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

  Secure site not available

  Most likely, the web site simply does not support HTTPS.

  However, it’s also possible that an attacker is involved. If you continue to the web site, you should not enter any sensitive info. If you continue, HTTPS-Only mode will be turned off temporarily for the site.

  [Continue to HTTP site]
(Copied from Firefox on Android)

Personally I think that's reason to do it alone, for the price of a free Let's Encrypt cert you can deliver much better UX. You presumably want people to visit your site.

Re: API Shouldn't Redirect HTTP to HTTPS

#124

Post by Brian_K_White »

dTP90pN wrote: post #113
Control8894 wrote: post #106

Earlier quoted context omitted.

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 be…

There's no "relaying" when the the attacker just captures unencrypted WiFi packets from the air, or more traditionally, splits some light out of the fiber line.

I hate to agree but they are right. Endpoint-spoofing and relaying between two spoofed endpoinbts is just one of the possible forms of mitm attack that just happens to be required if you happen need to open and re-pack encryption in order to evesdrop, or if you need to modify the data.

Spoofing the two endpoints to decrypt and re-encrypt, just so that you can evesdrop without modifying the data (other than the encryption) is certainly still "mitm". Yet all the man in the middle did was evesdrop. Becoming two endpoints in the middle was only an implimentetion detail required because of the encryption.

If you are admin of one of the mail servers along the way between sender and recipient and and can read all the plain smtp messages that pass through your hands like postcards without having to decrypt or spoof endpoints, that is still mitm.

So listening to wifi is no less. There is nothing substantive that makes it any different.

For endpoint-spoofing to be required for mitm, you would have to say that mitm only applies to modifying the data, which I don't think is so. Several purely evesdropping applications are still called mitm.

Re: API Shouldn't Redirect HTTP to HTTPS

#126

Post by jedberg »

pixl97 wrote: post #108
comex wrote: post #85

Earlier quoted context omitted.

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 t…

If someone is in your path they can just fake listen to 80 and intercept, then forward your call to 443. Probably best to listen on 80 and trash the token right then as the majority of the time there won't be a MITM and breaking the application will force the developer to change to https

> If someone is in your path they can just fake listen to 80 and intercept, then forward your call to 443.

They can do that whether or not you are listening on port 80 though.

Re: API Shouldn't Redirect HTTP to HTTPS

#127

Post by sdsd »

OJFord wrote: post #123
sdsd wrote: post #35

My personal website (darigo.su) doesn't have HTTPS. I just deployed it a few months ago and haven't really done much with it yet. I guess I'll have to get around to it eventually, but I find charm in small old sites that haven't implemented modern protocol stuff. My site also uses and tags all over the place. Maybe I'll do some more quirky anachronisms, like only serve the site via HTTP 1.0 or something. Who knows. S…

When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Secure site not available Most likely, the web site simply does not support HTTPS. However, it’s also possible that an attacker is involved. If you continue to the web site, you should not enter any sensitive info. If you continue, HTTPS-Only mode will be turned off temporarily for the site. [Cont…

>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!!)

Re: API Shouldn't Redirect HTTP to HTTPS

#128

Post by cryptonector »

znpy wrote: post #67
zepton wrote: post #54

The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.

I've been thinking for about 5 minutes about this comment and what to write but i've come to the conclusion that this is really not the best thing to do, but the correct thing to do. It's not different levels of good or bad... everything else is wrong.

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#130

Post by Brian_K_White »

thaumasiotes wrote: post #75
dfabulich wrote: post #39

The author includes a surprising response from "Provider B" to the HackerOne report. > Provider B: Reported on 2024-05-21 through their HackerOne program. Got a prompt triage response, stating that attacks requiring MITM (or physical access to a user's device) are outside the scope of the program. Sent back a response explaining that MITM or physical access was not required for sniffing. Awaiting response. I think Pr…

> Public unencrypted (or weakly WEP encrypted) wifi, with clients connecting to HTTP websites. Other clients on the same wifi network can read the unencrypted HTTP packets over the air. That's sniffing. The other two are MITM. The sniffer isn't in the middle of anything; you never speak to him.

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.

Post reply on HN