101–110 of 310 posts
Or just add your domain to the hsts preload list and never have to worry about this.
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…
It’s completely trivial to set up, there’s really no downside at this point.
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.
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.
Don't have HTTP available at all
The argument I've heard against not having HTTP at all is that potentially someone might be able to run something malicious on port 80 for that address that the admin is not aware of. People can make up their own minds if that's a good argument or not.
$ curl http://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 123" \
-d '{}'
{
"error": {
"type": "invalid_request_error",
"code": "http_unsupported",
"message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.",
"param": null
}
}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.
"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)
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.
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.
Using HTTPS everywhere is one such rule of thumb.
It’s just not worth expending the mental energy considering every single edge case (while likely forgetting about some) in order to try and work out whether you can cut the corner to use HTTP rather than HTTPS, when using HTTPS is so easy.
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…
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
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,…
Why would they want to do that? Is your weatherman always right?
> 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.
Ah, yes, people are interested in the weather. Wow!
Of course, they could get the same info from observing that users are connecting to the IP address of a weather API provider.
> They also inject a javascript payload into your traffic that starts computing bitcoin hashes and you are blamed for spreading malware.
Got there eventually. Crappy ISPs.