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

111–120 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#111

Post by andrewaylett »

comex wrote: post #85
znpy wrote: post #67

Earlier quoted context omitted.

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.

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 you're serving web traffic and API traffic on the same domain, which many services are, then not listening on port 80 may not be possible. Even if you do use a different domain, if you're behind a CDN then you probably can't avoid an open port 80. I do keep port 80 closed for those of my services I can do so for, but I don't have anything else that needs port 80 to be open on those IPs.

I think Stack Exchange's solution is probably the right one in that case -- and hopefully anyone who hits it will do so with dev keys rather than in production.

Re: API Shouldn't Redirect HTTP to HTTPS

#112

Post by Control8894 »

rascul wrote: post #83
Wowfunhappy wrote: post #66

Earlier quoted context omitted.

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

> • It's not a real security concern if you're on a private network. I'm not convinced that private networks should be assumed secure by default.

Perhaps, but the other realistic option is a self-signed cert. Since browsers refuse to implement any kind of TOFU or otherwise 'trust history', a self-signed cert is pretty much exactly equivalent to no TLS at all.

Re: API Shouldn't Redirect HTTP to HTTPS

#113

Post by dTP90pN »

Control8894 wrote: post #106
HL33tibCe7 wrote: post #94

Earlier quoted context omitted.

MITM generally refers to someone who can intercept and modify traffic, i.e. they sit “in the middle”, between you and your recipient, reading/modifying/relaying traffic. “Passive eavesdropper” is often used to describe what you talk about. Someone on an unencrypted WiFi network sniffing your traffic isn’t really “in the middle” at all, after all.

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#114

Post by Control8894 »

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.

> for example, an attacker within range of an Wi-Fi access point hosting a network without encryption

The monkey in the middle doesn't get to "relay" anything either, but he can sure see it going over his head.

Re: API Shouldn't Redirect HTTP to HTTPS

#115

Post by o11c »

Dylan16807 wrote: post #61
Aachen wrote: post #16

Earlier quoted context omitted.

We are. Slowly, due to lots of legacy, but surely getting there. See the small steps over the years where it was first an add-on to force https-only mode (HttpsEverywhere, 2011), then browsers started showing insecure symbols for http connections (e.g. in 2019: https://blog.mozilla.org/security/2019/10/15/improved-securi... ), and more recently I think browsers are starting to try https before http when you don't spe…

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

Firefox has a similar bug, but for DNS rather than connection.

Re: API Shouldn't Redirect HTTP to HTTPS

#116

Post by xboxnolifes »

tomsmeding wrote: post #103
bigstrat2003 wrote: post #96

Earlier quoted context omitted.

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.

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

> Sure, you get more scary warnings if you set your browser to "warn if it's http", but then you're asking for it.

Defaults. They matter.

Re: API Shouldn't Redirect HTTP to HTTPS

#117

Post by akira2501 »

g15jv2dp wrote: post #24
akira2501 wrote: post #2

> Servers can now send HSTS along with the initial HTTP-to-HTTPS redirection response > Node.js's built-in fetch happily and quietly followed those redirects to the HTTPS endpoint. Okay.. does nodejs fetch respect HSTS?

How would that even work? It's up to the developer to consider the response and act correctly on it.

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?

Re: API Shouldn't Redirect HTTP to HTTPS

#118

Post by tsimionescu »

HL33tibCe7 wrote: post #94
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…

MITM generally refers to someone who can intercept and modify traffic, i.e. they sit “in the middle”, between you and your recipient, reading/modifying/relaying traffic. “Passive eavesdropper” is often used to describe what you talk about. Someone on an unencrypted WiFi network sniffing your traffic isn’t really “in the middle” at all, after all.

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

Re: API Shouldn't Redirect HTTP to HTTPS

#119

Post by comex »

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

But not listening on port 80 will also usually break the application. Though I suppose the same API key may be used by multiple applications, or multiple copies of an application configured differently.

edit: and even if there's only one application, yet for whatever reason it doesn't get taken down despite being broken, revoking the key now still prevents against a MITM later.

Re: API Shouldn't Redirect HTTP to HTTPS

#120

Post by tsimionescu »

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…

I don't think people would consider 1 or 3 to be MITM. MITM requires someone who is, well, in the middle: you connect to the MITM, and they connect to your destination. 2 is clearly a MITM.

Also, while 1 is arguably a case of "physical access", I don't think 3 is. If you have a tap in an ISP, you don't have "physical access" to any of the endpoints of the HTTP connection. Otherwise, you could say you have "physical access" to literally every machine on the internet, since there is some physical path between you and that machine.

For another example, Kubernetes started as IPv4-only, and there are still plenty of plugins that have IPv4-only features.

Post reply on HN