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

301–310 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#301

Post by Control8894 »

chaorace wrote: post #286
cricketlover wrote: post #282

Earlier quoted context omitted.

How fan we capture unencrypted packets from the network? I thought you had to run tcpdump or something like that to be able to do that. But you won't be able to run tcpdump if you don't have access to the interface (source or destination), no?

I'm speaking in the context of the parent conversation ("unencrypted WiFi packets"). On wireless networks, all devices share the same "wire", so to speak. Normally that traffic is useless when captured due to encryption, but that's not the case on unencrypted (i.e. public) WiFi.

It doesn't matter if the wifi is encrypted or not. All that matters is that you share the network with an attacker. You can ARP poison just fine, encrypted or open, wifi or wired.

Re: API Shouldn't Redirect HTTP to HTTPS

#302

Post by chaorace »

Control8894 wrote: post #301
chaorace wrote: post #286

Earlier quoted context omitted.

I'm speaking in the context of the parent conversation ("unencrypted WiFi packets"). On wireless networks, all devices share the same "wire", so to speak. Normally that traffic is useless when captured due to encryption, but that's not the case on unencrypted (i.e. public) WiFi.

It doesn't matter if the wifi is encrypted or not. All that matters is that you share the network with an attacker. You can ARP poison just fine, encrypted or open, wifi or wired.

Well, actually... you can only successfully launch an ARP poisoning attack if you're on the same network segment as the impersonated host.

(Yes, I am indeed being pedantic on purpose to prove a point. I offer this parenthetical to you in place of an apology)

Re: API Shouldn't Redirect HTTP to HTTPS

#303

Post by plagiat0r »

It would be great to not listen on tcp/80 for your API, except that acme http-01 uses tcp/80 explicitly for domain validation. So in order to get https, you open http.

Sure, there is dns-01 and tls-alpn-01 but I presume that majority uses http-01 and migrating it is not a trivial matter.

Re: API Shouldn't Redirect HTTP to HTTPS

#304

Post by amscanne »

grantism wrote: post #161
amscanne wrote: post #153

Earlier quoted context omitted.

Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?

What's stopping the MITM just copying that header?

It’s preventing the theft of the API key. The attack can, at most, replay that specific request (which you could also mitigate with a nonce and expiration).

Re: API Shouldn't Redirect HTTP to HTTPS

#305

Post by ric2b »

superkuh wrote: post #63
ozim wrote: post #22

Earlier quoted context omitted.

That is an awful idea - in post Snowden world you encrypt all traffic period. Then you have post Jia Tan world - if there is even slightest remote possibility, you just don't want to be exposed. Just like washing hands after peeing, just do HTTPS and don't argue.

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

ISP's have been known to inject ads into HTTP pages, and ads are the least malicious thing that could be done by an ISP or wifi hotspot.

HTTP MITM is way too cheap and accessible to pretend you're not vulnerable to it constantly or that you need to be a target, you don't.

Re: API Shouldn't Redirect HTTP to HTTPS

#306

Post by ric2b »

superkuh wrote: post #231
cqqxo4zV46cp wrote: post #81

Earlier quoted context omitted.

How is this better in literally any way other than it makes things (in 2024, only very slightly) easier from an ops perspective, and panders to some nerdy fetish for simple ‘read it over wireshark’ protocols? HTTPS-only should be the default. Plain-text information delivery protocols that can easily be MITMd are unsuitable for almost all uses. This just feels like contrarianism.

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…

HTTP MITM doesn't need to be targeted, it could just as well be a crypto-miner script injected into every HTML response that passes through some box.

People need to stop pretending that HTTP injection is complicated enough to only happen in targeted scenarios, it's not, it's completely trivial.

Re: API Shouldn't Redirect HTTP to HTTPS

#307

Post by ric2b »

jkrejcha wrote: post #121
taftster wrote: post #59

Earlier quoted context omitted.

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…

Unless you're talking about DNS snooping, no, you can't see which hostname an HTTPS request is for.

If the IP address is only used to serve one website, sure, you can still see that, but that is very commonly not the case, especially for smaller websites that are likely to use shared hosting.

Re: API Shouldn't Redirect HTTP to HTTPS

#308

Post by ric2b »

smaudet wrote: post #98
taftster wrote: post #59

Earlier quoted context omitted.

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 adversary can see that your users from one region are interested in the weather and can start building a map of that traffic I think this is the most convincing argument, but, I think that some data doesn't care if it is not confidential. The weather is perhaps more pointed, but I think for large protected binaries (either executable or inscrutable, e.g. encrypted or sig protected archives), its a bit moot and p…

Adversaries can see IP addresses, not hostnames, although they can be highly correlated (especially for large websites with dedicated infrastructure instead of shared hosting).

Re: API Shouldn't Redirect HTTP to HTTPS

#309

Post by averageRoyalty »

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

To me, HTTPS is worth it alone to eliminate the possibility of the ISPs of people reading my site from injecting shit (ads, trackers, etc.) into the responses I send to them. It’s completely trivial to set up, there’s really no downside at this point.

To be fair, triviality is relevant to the tooling you run and there are many downsides - extra negotiation and traffic, unsupported on older clients without using up an IPv4 address, certificate expiry, etc.

For most cases these are non issues, but there are many scenarios where those things can outweigh the potential of your ISP modifying/reading. If that's still a concern, you can tunnel through your ISP to a more trusted exit point.

Re: API Shouldn't Redirect HTTP to HTTPS

#310

Post by j5155 »

JohnFen wrote: post #299
j5155 wrote: post #285

Earlier quoted context omitted.

I’d disagree that there has to be a trade off at all. Using hardware security keys or device based passkeys, secure authentication is actually pretty convenient now.

I disagree that hardware security keys or passkeys are more convenient. I ditched them because they greatly complicated authentication for me.

Interesting; I have had the opposite experience. Many websites will directly enroll my Yubikey and will even let me use it instead of a password, and logging in is as simple as touching the button at the prompt. It’s honestly much simpler then using a password for me, and MUCH more convenient then pulling out my phone for 2fa codes (especially for the university site’s painfully short session times)
Post reply on HN