A prove that a normal user doesn’t care and doesn’t understand about the “behind the scene” difference was given to me just yesterday.

He called and told me that he no longer can’t use FF3 because it gives him an error accessing the webgui page of his hosting account, and he now has to use IE6 and asked my to fix the problem for FF3.
The problem was easy, the webgui management account was using https under his own domain address (like https://domain.com/admin) but he does not have a cert for his site, so provider uses a generic self signed one.

Lesson learned: The error page FF3 shows is not up to the task for the normal user. It leads to a workaround even worse, go back to IE6. Yuk…

The only easy method a user understands would be a banner explaining the three different SSL versions, self signed in white with warning, normal SSL in yellow as the user is used to an EV SSL in green, the later two giving the “verified” information as additional data .

Usability study on the user should have been conducted before introducing such a “feature” as this – or it comes down to the question if FF3 is a geeks tool or an end user product.

It’s frustrating to see the hard work of getting clients to use FF getting a bad hit with such bullshit. Sorry, but I’m quite angry about it.

Oliver

The proposal isn’t really a technical change. It’s merely a UI change to be more graceful. It could even display a banner similar to that of a popup notification that the site is using a self signed cert. It’s still better than the current error page implementation. It’s more intuitive for the user who is likely to encounter self signed certs.

Neither do self-signed HTTPS connections, right?

Correct. You get a cookie.

…but if the browser shows the same chrome for it as it does for a CA-signed one, it looks every bit as good as your Financial Institution of Choice or your Secure E-mail Login Page. Funny what might happen if your DNS got hijacked and one of those sites was using a self-signed cert, eh?

I specifically said:

The user interface should indicate that the channel is encrypted and communication is unlikely to be intercepted between the user and the server. It should note if there is any change (just like SSH notifies the user if the signature is changed between sessions). Other than that it should be transparent.

Self signed certificates aren’t an error, and shouldn’t be treated as such. They should be treated as a different grade of SSL, just like we have SSL and EV SSL right now.

You can indicate encryption without implying that the domain is authenticated.

And if I were phishing, I’d just get a domain cert for my phishing domain and use a technique such as:

https ://www.ebay.com:something@example.com/foo/bar

Most users wouldn’t know the difference anyway unless the browser had Phishing protection. No dialog, the site looks secure… end of story.

>Neither do self-signed HTTPS connections, right?

…but if the browser shows the same chrome for it as it does for a CA-signed one, it looks every bit as good as your Financial Institution of Choice or your Secure E-mail Login Page. Funny what might happen if your DNS got hijacked and one of those sites was using a self-signed cert, eh?

Neither do self-signed HTTPS connections, right?

The point is, SSL certificates guarantee that when you are connected to a certain domain, the connection to that domain is secure (authenticated and encrypted) and not hijacked. Whether you trust that domain is up to you.

Phishing works by getting people to trust malicious domains. SSL and PKI do not guarantee that any given site is trustworthy, only that it is who it claims to be. EV certs can associate a business name to a domain, but then you have to decide whether you trust that business.

> By your logic, every NOT https page should display an error message since it too can not be authenticated.

I did not suggest that at all. I made no mention of conventional HTTP. People don’t expect non-SSL sites to be authenticated and browsers do not indicate them as such.

> MitM attacks don’t increase because of SSL. HTTP is just as vulnerable. If you have data to suggest otherwise, please cite it.

This is not at issue. Again, HTTP connections don’t claim to be authenticated.

CA’s don’t do “high quality validation”. Phishers have been using signed certificates for a long time. You can often buy them with a shared hosting account (which you can get with a stolen credit card).

The point is encryption shouldn’t result in an error. The page being encrypted isn’t an error, it’s a feature. The site is no less trustworthy than if it was served over port 80.

By your logic, every NOT https page should display an error message since it too can not be authenticated.

MitM attacks don’t increase because of SSL. HTTP is just as vulnerable. If you have data to suggest otherwise, please cite it.