4 ms·
I think the point here is that there's also no way to distinguish a http request from an attack. It's fair enough to an argue that a self-signed cert could be
by lucideer 7y ago
I think the point here is that there's also no way to distinguish a http request from an attack.
It's fair enough to an argue that a self-signed cert could be an attack, but so could any http request.
> a no-cert (unencrypted) connection can be distinguished from an attack on an encrypted connection: the browser knows a priori (through the protocol in the URL) that the connection is supposed to be unencrypted.
I don't understand how that allows one to distinguish it from an attack. Knowing that a connection is supposed to be unencrypted is just equivalent to knowing that a connection could be under attack.
- knome 7y agoRightly punishing the connection for having the trappings of security when it actually lacks it doesn't mean we need to punish openly insecure traffic. End users have been told time and again that http is insecure, and so it's fine to leave it. End users should also be able to trust that https means secure without having to distinguish between secure and secure unless I'm being mitm'd and needing to understand what any of that means.
- mrob 7y agoMost end users have no idea what HTTPS is. They've just been (incorrectly) taught that the padlock means it's secure. Disable the padlock for self-signed HTTPS, and disable the CA-signed HTTPS-only features, and it becomes strictly better than HTTP.
- namibj 7y agoEspecially because there is no way to MITM a connection with perfect-forward-secrecy only if it ends up serving a self-signed certificate, because the connection first negotiates an ephemeral key with which everything, including the certificate, will be encrypted. This means that with eSNI and at least one CA-signed cert on the IP, any attacker runs the risk of having to spoof the CA-signed certificate.
- zozbot234 7y agoA sophisticated attacker might know that you were going to connect to a self-signed site, though. Interestingly though, private DNS (DoH, etc.) might help further shroud this fact from the attacker. All in all, I'd say that the browser should still throw up a full-page warning because of the implications of TOFU, but it can be one where the "continue to site" option is clearly shown even to a naïve user, and not hidden behind a spoiler.
- namibj 7y agoThen maybe fall back to DANE and thus restrict this to zones signed with more than 1024bit RSA?
- lucideer 7y agoTo echo @mrob's comment (not sure why they've been downvoted), relying on user-understanding of HTTP -vs- HTTPS is considered a failed experiment, and actively discouraged. Chrome in particular are moving to bring this into the browser UI by marking HTTP sites as insecure (rather than relying on users understanding that HTTPS is secure, which they don't).
- yencabulator 7y agoThe http version can't access secure cookies; https with the wrong cert can use the secure cookies of the real https site.
- mrob 7y agoSo disable secure cookies by default for self-signed certs. The scary warnings can be shown when the user tries to enable them.
- ivanbakel 7y agoIn other words, "open users up to social engineering attacks to make my web-dev life easier".
- lucideer 7y agoYou misinterpreted the above commenter. The suggestion is to disallow self-signed contexts access cookies set in authoritative contexts.
- ivanbakel 7y agoI don't see that as the biggest problem. If we repeat what was said in the above comment: > ...disable secure cookies ... for self-signed certs. ... the user ... enable[s] them. So you make a self-signed cert for your website which needs secure login, and you tell your users to turn on secure cookies so that you can safely store their credentials in the browser. Then your website gets MITM'ed with another self-signed cert, which either 1. can access the same cookies, because the domain is the same 2. can't, because the cert is different But in the second case, you've already conditioned users to log in to your website with the cert being self-signed, so they'll just log in again. If the browser complains that the attacker's cert isn't the same as the old cert, or makes the user re-enable secure cookies with a warning, then the user has been conditioned to do that too - and an extra message of "we changed the cert, ignore your security warnings" will convince lots of users with doubts.