201–210 of 310 posts
Earlier quoted context omitted.
What's stopping the MITM just copying that header?
There's complicated authentication schemes around hmac that tries to do this, but if you're putting that much effort into it you might as well give up and use https.
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 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 so…
So it's better to have "api.example.com" and "www.example.com" kept separate, rather than using "www.example.com/api/", where API requests will have inflated headers.
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.
Injecting ads by ISPs into http is documented and known - they can inject anything on transit of HTTP it can be done automatically and basically with 0 cost. ISP is one the other all kind of free WiFi.
It is not only “NSA will get me” or only financial transactions. There are new known exploits in browsers and systems found on daily basis.
So reasoning is someone has to be of interest - not true because it is cheap and automated tls is making cost higher for simply scooping stuff.
Earlier quoted context omitted.
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?
Or use a library to do it. The core fetch functionality shouldn't have to deal with HSTS. There may be legitimate reasons to fetch over HTTP even after you received an HSTS header - for testing purposes, for example.
> Why not just implement your own fetch wrapper that throws if it's not an https connection?
That's the developer dealing with HSTS.
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…
I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https? Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating. Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Bei…
HTTPS is about protecting the client.
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.
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 av…
Specifying availability of TLS (and, perhaps, which ciphers are usable, in order to avoid the use of insecure ciphers) by DNS would do, if you can (at the client's option) acquire DNS records securely and can know that they have not been tampered with (including by removing parts of them). (This is independent of whether it is HTTP or other protocols that can optionally use TLS.)
(Actually, I think that using DNS in this way, would also solve "Gopher with TLS"; the format of gopher menus makes it difficult to use TLS, but knowing if TLS is available by looking at DNS records would make it work. Gopher servers can still accept non-TLS requests without a problem, if none of the valid selector strings on that server begin with character code 0x16 (which is always the first byte of any TLS connection, and is very unlikely to be a part of any Gopher selector string).)
It would also help to make cookies unable to cross between secure and insecure connections in either direction (always, rather than needing a "secure cookies" flag).
Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ 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"…
Doesn’t returning a 403 on HTTP break HSTS? https://security.stackexchange.com/questions/122441/should-h... Doesn’t HSTS require only responding to a user via HTTP S (even for error codes).
Earlier quoted context omitted.
I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https? Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating. Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Bei…
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.
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…
Earlier quoted context omitted.
Of course. But I think the poster above was referring to just posting random keys to the server. In other words I don't have your key, or any key, but I have "all of them". The correct response to this though is that "there are lots of keys, and valid keys are sparse." In other words the jumper of valid keys that could be invalidated in this way is massively smaller than the list of invalid keys. Think trillions of t…
Which, like, if posting random keys has any realistic plausibility of collision, malicious revoking of keys is the least of your concerns. People could just hit important data fetch endpoints with random keys, until they find one that’s good, and then have a compromised account.