Hacker News Reader

Comment by r1ch | Hacker News Reader

> 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?

View on HN

Not 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

The 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.

Splitting 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.

If 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.

And your alternative of not allowing the user to access what they have clearly stated the intention to access isn't acceptable either.

I feel like we're talking past each other. I'm pointing out that when a user is under attack, they're not getting what they clearly stated they wanted. The only conundrum here is that the browser can't tell the difference between "under attack" and "misconfigured". If you want to bang on that conundrum, OK. But this business about user intent doesn't make sense to me.

But the the user is more often than not, not under attack. Think back to the last ten or so security warnings you go while browsing the internet.

How many of them were a result of a pretty blatant configuration error? Things like self signed certs on personal/toy sites, T+1d expiration, subdomains using the main domain's cert (or vice versa), bad local clock, things like that that?

How many of them were ambiguous?

How many of them were unmistakably fishy?

If your breakdown is anything like mine, it'll be 9/1/0.

I speak of intent because the original person I replied to suggested that security warnings should not be dismissable. I vehemently disagree, because it is my decision to make whether accessing the information I clicked on is more or less important than the risks for the particular class of cert problem that presented itself.

Hide it behind an about:config variable or explicit cert trusting or something else, I don't care. That is still superior to telling me that I can't access something for my own protection.

I'm more sympathetic to this argument, and hiding it behind an about: variable seems like about the right way to handle it.

In fact: apart from the sheer ugliness and cryptographic ass-backwardness of the protocol itself, this is my biggest problem with DNSSEC: it takes the exact same set of failure modes and migrates them to the DNS, where there is no error recovery possible. When DNSSEC configurations break, sites simply vanish from the Internet.

The problem with giving users an option is they tend to hit "yes". The current mass outbreak of cryptolocker is heavily based on users get that "Word has disabled macros" prompt and then going and hitting "enable".

Chrome's BADIDEA is a good middle ground. Advanced users have a workaround. Average users generally don't.

As 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.

This one in particular feels very strange, since there's actually nothing bad actively happening with the connection, it's more of a policy decision.

My 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.

So 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.)

I 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.

All 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.

If you have explicitly dis-trusted a certificate you can't click-through either.

I think HPKP might also suffer the same issue.

It depends on who you ask, but I personally don't think hard certificate validation failures are a bad thing.

HKPK has the potential problem that losing / compromising 2 keys leaves your site unavailable until the pin expires.

This 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.

Quite a few are only overridable in about:config, like: (if I recall correctly)

  * DH short exchange keys
  * NTLM1 passwords

I 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?

There'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/cfe5bf0b51b1f6b9fe239... Not sure which one of these catches HSTS failures.

> 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.

Except 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.

Then you disagree with the browser vendors decision to gradually remove support/warn for SHA-1 entirely? They seem to disagree with you.

SHA1 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.

SHA1 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.

SHA-1 still isn't practical to exploit right now. Conditioning users to automatically click through SSL warnings, on the other hand, can be trivially exploited.

Why 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.

Reply on news.ycombinator.com