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