Live data from Hacker News

Mozilla SSL policy bad for the Web

cs.uml.edu

31–40 of 89 posts

Re: Mozilla SSL policy bad for the Web

#31
Unbelievable. I've been poking about here for like 6 months now. You are all very smart people. Why is this so hard to understand?

If you do not have a valid certificate signed by a CA, SSL is not providing any security.

Yes, the warning you get when you visit a site with an invalid cert is much scarier than what you see if you visit an unencrypted site. But it's the sites that use encryption that users care about, because those are the sites that get their passwords and credit card numbers.

Perhaps you think the browser should make an exception for self-signed certs. After all, there's nothing "wrong" with their signatures. Nothing's expired. No signature fails to validate. Why not just make the URL bar orange or something? Because anyone can create a self-signed cert and sub it into a Bank of America SSL connection.

It sure is annoying that you have to pay $20 every year to keep an SSL cert. I totally agree that this a problem. But right now, without that $20, you have a connection that provides cryptographically zero security. Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem.

Re: Mozilla SSL policy bad for the Web

#32

Having a trusted third party is a pretty big deal in cryptography. Without it, many of the core assumptions of public-key cryptography are invalid. It's a huge part of making sure the other end is authentic. I'd place a lot more trust in Bank A's public key if it was signed by verisign, rather than an unverified third party. Having verisign's public key in my browser elimininates a large class of man-in-the-middle at…

It's not even that complicated.

The problem with not having a valid certificate is this: if both sides can't tie every packet in the SSL handshake back to Verisign or Thawte's pubkey, attackers can inject their own handshake passwords and set the session key.

Re: Mozilla SSL policy bad for the Web

#33
post #17
post #4

Johnathan Nightingale of Mozilla has a good blog post explaining the rationale behind this: http://blog.johnath.com/2008/08/05/ssl-question-corner/ An especially pertinent point from his post: "Several CAs accepted by all major browsers sell certificates for less than $20/yr, and StartSSL, in the Firefox 3 root store, offers them for free."

That's not the bug though. The bug is that the error message a user sees when visiting a self-signed site using HTTPS is much more scary than simply visiting that site on an unencrypted connection, even though by all reasonable standards this is a safer, more private, and more secure action. If we're not going to warn folks about unencrypted links where every proxy in the way is a man-in-the-middle attack waiting to…

The warning says, "Here is a site that claims to be secure. Maybe you thought it was secure, maybe you didn't. Either way, the site is not secure. DO NOT ENTER YOUR PASSWORDS AND CREDIT CARD NUMBERS HERE."

The warning is vibrant because the condition it reports on can be created by an attacker on any SSL connection. That stupid warning might be among the top five security mechanisms on the Internet.

Re: Mozilla SSL policy bad for the Web

#34
post #11
post #4

Johnathan Nightingale of Mozilla has a good blog post explaining the rationale behind this: http://blog.johnath.com/2008/08/05/ssl-question-corner/ An especially pertinent point from his post: "Several CAs accepted by all major browsers sell certificates for less than $20/yr, and StartSSL, in the Firefox 3 root store, offers them for free."

Doesn't change the fact that it pops up a scary unintelligible message and makes you jump through hoops whenever someone tries to visit a site with a self-signed certificate. It's very much a "break the web" situation. As suggested by the original article, the correct behaviour would be to treat it as though there's no security whatsoever. After all, logically, how is being encrypted but unauthenticated worse than be…

How can your browser tell the difference between:

(1)

A connection to onlinebanking.bankofamerica.com in which an attacker has hijacked the SSL handshake and subbed in a self-signed certificate, and

(2)

A connection to https://login.ratemykitten.com?

You appear to be arguing that the warning for this situation should be tuned to (2).

Re: Mozilla SSL policy bad for the Web

#35
post #5

Earlier quoted context omitted.

But what good is encrypted communication if you cant be sure who you are communication with?

What good is verified communication when you can buy an SSL cert with pretty much any fake information you want.

No good at all. Which is why you can't buy an SSL certificate that claims to be onlinebanking.bankofamerica.com.

Re: Mozilla SSL policy bad for the Web

#36
post #9

Earlier quoted context omitted.

If you don't know who you're talking to, then there is no point in encrypting the data, because you're probably talking to the attacker. ("Man In The Middle") Now, the idea of "I'm talking to the same person I talked to last time" is useful, but if the users are all conditioned to accept random certificates without understanding, then when they go back a second time (and the attacker is waiting), they'll agree to the…

If you create an account on happykittens.com, you don't really care if the cert happykittens.com is sending you is signed by a trusted CA. What you care about is that the second time you visit the site, when you log in with your brand new account, that the cert the site sends you is the same you received when you created the account (the site is the same you created the account on). This has nothing to do with the fa…

Key continuity is a fine answer to this problem. Just come up with a way to provide it on every device every user might reasonably want to log in from, for every site on the Internet.

Re: Mozilla SSL policy bad for the Web

#37
post #10

"Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents." I wouldn't be so sure about that.

> I wouldn't be so sure about that. Umm, I would. Running Wireshark or tcpdump to sniff traffic over the wire is easy , and analysis can be done offline at the attacker's leisure. Hijacking DNS and phsishing for users' login credentials to other sites requires a lot more preparation, and in most cases, prior selection of the desired target sites.

(1)

An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. Without SSL in the way, she now owns several thousand bank account logins and Yahoo Mail passwords.

(2)

An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. With SSL in the way, she now owns several bank account logins and Yahoo Mail passwords.

Re: Mozilla SSL policy bad for the Web

#38
post #9

Earlier quoted context omitted.

If you don't know who you're talking to, then there is no point in encrypting the data, because you're probably talking to the attacker. ("Man In The Middle") Now, the idea of "I'm talking to the same person I talked to last time" is useful, but if the users are all conditioned to accept random certificates without understanding, then when they go back a second time (and the attacker is waiting), they'll agree to the…

If you've ever run an e-commerce site, you'll know that payments drop off significantly when browsers start throwing up warning signs.

Which is good, because without that dropoff, your customers security would be an externality to you.

Re: Mozilla SSL policy bad for the Web

#39
post #18
post #6

Also, you can see the "add an exception" in the screen shot. You can manually add an SSL certificate to a white list, it's just a little bit harder, with a few more steps, than the previous YES|NO dialogue. I think this a good thing. 99% of user probably don't need to or shouldn't interact with pages with self-signed certificates. That's a good thing. Self-signed certs should really only be on development pages. I'm…

In this case I disagree. The web is not all corporate, and there is a confusion between encryption and authentication. A certificate, signed or no, is a means to establish a secure connection between Alice & Bob. This ensures no one is snooping or modifying the data passing between them. this is a good thing that should be encouraged in an age when your ISP injects ads and the government keeps tabs on what sites you…

A self-signed certificate does not establish a secure connection between Alice and Bob, because Alice can't verify the certificate. Bob can send his certificate, Mallory can trivially intercept it and replace it with her own, and nobody will be the wiser.

Let's not encourage people to adopt security mechanisms that provide no real security. Let's make the security mechanisms we have today, which are strong enough to stop many governments and all of the largest corporations, cost-effective and easier to deploy. Let's solve the right problems, instead of trying to make ourselves feel better by sugarcoating browser warning messages.

Re: Mozilla SSL policy bad for the Web

#40
post #3

SSL certificates for HTTPS are a big fat scam. Why do I need to pay money to get a certificate, just to provide encryption. Encryption should be separate from identity verification. Of course identity verification should be properly vetted and you should have to pay a fee, and have documents checked etc. If however, you just want to provide security for your users by encrypting http, you should not have to jump throu…

Commercial certificates are not a scam. You're paying for a company (the CA) to certify (via the SSL cert signature) that an identity belongs to someone that has provided proof that they're who they say they are.

You can absolutely do what you're requesting by creating your own CA and signing certs for your sites and distributing your CA cert to your users somehow.

If you can figure out how to reliably provide this service for free you could revolutionize crypto on the internet. You might start by looking at what cacert.org has done to see what problems they've hit and why it's not as easy as it seems.

Post reply on HN