So do an unencrypted normal site and an unencrypted attack site (like my spam folder is full of links to).
Most self-signed sites are fine, but because a few are MITM attacks, they should all throw big warnings (which users will learn to ignore, because of poor signal-to-noise).
Most unencrypted sites are fine, but because a few are attack sites, ....
The criteria for a user to enter sensitive info should not be "the connection is encrypted" or even "the connection is encrypted and goes to the server it says it does", but "I know the real-world identity of who I'm talking to".
The criteria to warn the user against entering sensitive info should be the negation of that; "I don't know the real-world identity of who I'm talking to".
The means of warning the user, should be such that the user does not need to act when not trying to enter sensitive info. So rather than pop-ups or interstitials that have to be dismissed -- and that the user can learn to dismiss -- there should be some persistent UI cue (like the green "Citigroup Inc (US)" beside the address bar) that the user can check when needed.
Browser: "Bad cert! The world's gonna end!"
User: "That's just a discussion forum, I don't care."
Browser: "Bad cert! The world's gonna end!"
User: "That's Joe's blog, I don't care."
Browser: "Bad cert! The world's gonna end!"
User: "yeah yeah, that's nice"
Browser: "Bad cert! The world's gonna end!"
User: "Would you shut up already!"
User: "...Why is my bank account empty!?"
I don't understand why you keep saying "attack site". The problem the self-signed cert warning addresses isn't malicious sites; it's attackers who intercept TLS connections to online banks and swap out the Verisign certificate with a self-signed certificate.
The warning isn't about the site; it's about the connection.
> it's attackers who intercept TLS connections to online
> banks and swap out the Verisign certificate with a self-
> signed certificate
How is a MITM attack with a self-signed certificate any different than redirecting a user to a HTTP site instead of an HTTPS site? Do you really think that 'Joe Sixpack' knows the difference between http and https the way that you do?
You're saying that users can distinguish between the following possibilities:
- A site is over http, so it's insecure (and no big red warning).
- A site is over possibly compromised https with a big red warning, so it's insecure.
- A site is over verified https with a big green "everything is ok" light, so it's secure.
You seem to think that the average user knows that HTTPS needs a "red light/green light" system, but HTTP does not (because it's inherently insecure). I posit that the average user doesn't 'get' the difference between http with no warning and https with a green light. Why not have a system that is simple for the end-user? E.g.:
- green light == secure
- no green light == insecure
- no need to differentiate between http/https for
the average end-user
I'm really having trouble following your argument here. The only reason the user wouldn't know who he's talking to is shenanigans. You're complaining about the shenanigans alert.
Most self-signed sites are fine, but because a few are MITM attacks, they should all throw big warnings (which users will learn to ignore, because of poor signal-to-noise).
Most unencrypted sites are fine, but because a few are attack sites, ....
The criteria for a user to enter sensitive info should not be "the connection is encrypted" or even "the connection is encrypted and goes to the server it says it does", but "I know the real-world identity of who I'm talking to".
The criteria to warn the user against entering sensitive info should be the negation of that; "I don't know the real-world identity of who I'm talking to".
The means of warning the user, should be such that the user does not need to act when not trying to enter sensitive info. So rather than pop-ups or interstitials that have to be dismissed -- and that the user can learn to dismiss -- there should be some persistent UI cue (like the green "Citigroup Inc (US)" beside the address bar) that the user can check when needed.