Hacker News new | past | comments | ask | show | jobs | submit login

I agree. An HTTPS connection with an untrusted certificate has exactly the same security as a plain HTTP connection. So don't use HTTPS without trusted certificates. It's confusing to end-users and, by instilling the click-through reflex, is damaging the security of the Internet.

It is vanishingly unlikely that Mozilla is ever going to include cacert.org among their trusted CAs, because hundreds of thousands of people use Firefox to access their banks, and there are plenty of smart security people that work at and with Mozilla.




The algorithmic security of unsigned HTTPS is the same as HTTP. Luckily, Mozilla already has a method of displaying such a page - leaving out the lock icon and colored background. There should be no "click through" unless you're proposing a user click OK for every http page they visit as well.

PKI is a hard problem, and CAs do it well for brick and mortar identities. However, that is certainly not the end of the story. The reason someone would choose to run SSL without paying for a certificate is that they believe most everything should be encrypted, but do not value the security properties provided by CAs.

You still haven't said why Mozilla should arbitrarily block the use of HTTPS in such a fashion. Should GPG prevent me from verifying a signature if it is not in my web of trust?

The only thing a basic SSL certificate (from one of the 47 (!) default CAs) does is guarantee ownership of a domain. This is exactly what CAcert does. Visiting paypal.com, I see the name of the company and country in green, from a higher assurance certificate where more thorough checks were done. This is what banks should be using.


You're steadfastly avoiding answering a really basic question:

If Mozilla "accepted" self-signed certs (to some definition of "accepted"), what should it do when someone browsing to onlinebanking.bankofamerica.com receives a self-signed cert that an attacker has spliced into the connection? It sounds like you want to make the warning for that condition less severe. Your browser cannot tell the difference between your personal self-signed cert on your own app, and an attacker's self-signed cert appearing on a BofA connection.


If the user is already interacting with onlinebanking.bankofamerica.com and the certificate changes, that's a serious error.

If the browser has a longer-stored certificate for onlinebanking.bankofamerica.com (say because they've bookmarked it), and the level of the certificate changes, that's an error.

If the browser has no idea about onlinebanking.bankofamerica.com (perhaps the user typed it in, probably without the https prefix), then the user must verify the security properties of the site. This is what a user must do now, as there may be no redirect to https, or redirect to an arbitrary https. If the site sends a certificate signed by an unknown CA, the user would not see a lock icon, blue background, green company name, etc.


I missed this comment because it's 4 days old, and I waste too much time here so that's like 5 clicks back through my comment history. But here's the answer to that: the first time you connect to a site, your browser has no certificate to "remember". People are unwilling to accept a security model that doesn't protect their first access to B of A, especially when a security model that does is available.


(And who knows if you'll get this. Interesting that HN fails at direct discussions)

The current usage model doesn't protect my initial access to BoA without me verifying that:

1. I've got a https connection

2. I haven't been redirected away to a rogue (SSL) site

You see the (https url)->(page retrieval) process as uniformly trusted (correct me if I'm wrong). I see stratification based on which third parties are doing the verification. Perhaps I'll have to wait for the emergence of a protocol explicitly designed for such things.


(1) is why browsers have a little "key" icon.

(2) is not a real problem; your browser won't let you hit a "rogue" SSL site without clicking through a scary warning.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: