12 ms·
> overridable “Untrusted Connection” error Allowing users to click past security warnings is a really bad idea. How is a user supposed to know the difference b
by r1ch 10y ago
> overridable “Untrusted Connection” error
Allowing users to click past security warnings is a really bad idea. How is a user supposed to know the difference between untrusted because of SHA-1 deprecation and untrusted because of a MITM?
- kkl 10y agoAs far as I know almost all browser security warnings are overridable. The only one that comes to mind that does not have a click-through option is when a HSTS-enabled site fails a validation check.
- r1ch 10y agoThis one in particular feels very strange, since there's actually nothing bad actively happening with the connection, it's more of a policy decision.
- coldpie 10y agoMy understanding is that you can't know that nothing bad is actively happening with the connection since SHA-1 is no longer a strong hash, so it's basically (hand-wave) no different from an HTTP connection.
- bandrami 10y agoSo why don't they present any warning on HTTP connections? It's not "basically no different" from an HTTP connection, it's strictly better than an HTTP connection, but not as good as a cert made with a more modern hash. (For that matter the same argument applies to self-signed certificates: you're still keeping a third party from snooping on the phishing attempt the MITM is giving you, which is itself a Good Thing.)
- coldpie 10y agoI agree, insecure HTTPS should be treated like HTTP. But this issue has been argued to death, especially over self-signed certs, and our side lost.
- kevincox 10y agoAll major browsers are moving towards this. Starting with the tiny icons changing colors they are beginning to make HTTP as insecure. Yes, it's very slow but at least they have started moving.
- MrRadar 10y agoIf you have explicitly dis-trusted a certificate you can't click-through either.
- rocqua 10y agoI think HPKP might also suffer the same issue.
- kkl 10y agoIt depends on who you ask, but I personally don't think hard certificate validation failures are a bad thing.
- rocqua 10y agoHKPK has the potential problem that losing / compromising 2 keys leaves your site unavailable until the pin expires.
- kkl 10y agoThis is a common theme in this thread but I'll re-state it here: Web browsers cannot reliably distinguish between a configuration mistake and an attack. For this reason, I think hard HPKP fails are a good thing. For those who opt-in to HPKP, this is a risk one takes in exchange for greater control over certificate validation.
- amiraliakbari 10y agoQuite a few are only overridable in about:config, like: (if I recall correctly) * DH short exchange keys * NTLM1 passwords
- smoyer 10y agoI just went digging through the about:config options and couldn't find a way to force SHA-1 off. Why are they gradually rolling this out to beta users if they've purposely downloaded the Developer Edition?
- sbierwagen 10y agoThere's a couple fatal errors, ERR_CERT_CONTAINS_ERRORS, ERR_CERT_REVOKED, ERR_CERT_INVALID, ERR_CERT_NOT_IN_DNS: https://github.com/adobe/chromium/blob/cfe5bf0b51b1f6b9fe239c2a3c2f2364da9967d7/content/browser/ssl/ssl_policy.cc#L78 https://github.com/adobe/chromium/blob/cfe5bf0b51b1f6b9fe239... Not sure which one of these catches HSTS failures.
- Karunamon 10y agoNot allowing users to visit sites they are directing their computers to visit is a worse idea. The computer's job is to do what I tell it to do, not what Mozilla thinks is best for me. Forgetting this leads to wonderful issues like the eight year old dupe certificate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=435013 https://bugzilla.mozilla.org/show_bug.cgi?id=435013
- tptacek 10y agoThe problem is that when there's an adversary in the picture (when there isn't, you may as well not encrypt at all), your computer isn't doing what you tell it to. TLS doesn't work if you don't enforce authentication. When people visit TLS URLs, they're asking the browser to establish a TLS connection. When attackers make that impossible, it's the job of the browser to refuse, on the user's behalf, to downgrade to an insecure connection.
- Karunamon 10y agoSplitting hairs. The user is almost never directly controlling whether the connection is to be secured or not, they're clicking on a link, and even less so nowadays with the existence of things like HSTS. It should be the browser's job to inform the user if it can't meet Mozilla's definition of security, but if accessing the information is more important at the time, it needs to get out of the way with an override and honor the intention of retrieving the information.
- tptacek 10y agoIf the net effect of the override is that users routinely click through the warnings, then the security of the whole system depends on how well we can educate random end-users on the TLS security model. That's not going to work.
- Karunamon 10y agoAnd your alternative of not allowing the user to access what they have clearly stated the intention to access isn't acceptable either.
- geofft 10y agoWhy is there a difference? At this point we believe that SHA-1 is vulnerable to MITMs. There are of course plenty of SHA-1-using sites that aren't being MITMed, but there are also plenty of sites with invalid certificates that aren't being MITMed, either (or sites that are being MITMed in benign ways), and the browser doesn't distinguish between those and real MITMs.
- jrochkind1 10y ago> How is a user supposed to know the difference between untrusted because of SHA-1 deprecation and untrusted because of a MITM? The whole reason SHA-1 is being deprecated is because it's judged no longer strong enough to protect against MITM. So I'd say it's intentional and desirable to treat SHA-1 like MITM, rather than to try to get the user to distinguish. User's don't have the capacity to distinguish between, and shoudln't have to, any category of "someone may be viewing and/or altering the content in this connection." They are moving to judging SHA-1 such a category.
- makomk 10y agoExcept that SHA-1 is strong enough to protect against MITM and will be for the immediately foreseeable future. Well-financed attackers could probably achieve a collision but that doesn't get you very far these days.
- jrochkind1 10y agoThen you disagree with the browser vendors decision to gradually remove support/warn for SHA-1 entirely? They seem to disagree with you.
- user5994461 10y agoSHA1 is perfectly fine. Warning: The above sentence may not be right in 5-10 years so they are starting to shut it down now. I personally find the schedule rather aggressive. Stop issuing certs this year, block it next year. What's the average cert lifetime? 1-2-3 years? This is gonna give some warnings.
- spydum 10y agoSHA1 may not be defeated yet, but since it has been found weak, we would be foolish to continue using it. It does us little good to wait until it's actually broken. Especially since we have sha2 as a sufficient replacement.
- 10y ago