Ask Slashdot: Does SSL Validation Matter?

An anonymous reader writes "Right now, in an email list excluded from the public eye, some bright people are discussing the future of SSL. Under debate is (a) do they allow DV (domain only validation) certificates to continue to exist (exist for e-commerce use? only encryption use?) or do they require a higher degree of certificate validation? (b) Do they allow certificates to be issued with non-unique common names (certificates used on internal networks, think your exchange server) or do they ban the practice? If this were 'hypothetically' a heated debate going on right now and you could chime in, what would you say?"

Comments

All about money not security.

[TheLink]

From my cynical POV, the industry is all about money and little to do with security. From the browser makers to the CAs.

The browsers by default won't warn you if say your US bank's server cert is one day signed by CNNIC (China) while you're in China. Or vice versa.

The CAs (Verisign, Comodo etc) have been known to sign certs that they shouldn't. And the browser makers don't kick those who repeatedly screw up.

Cost is too high

[karl.auerbach]

The barrier to entry for a cert authority to be recognized by browsers is too high, as a consequence the price for certificates is too high - it is based on near-monopoly conditions.

god validation v. group validation

[Onymous Coward]

I've been using the following to help me validate certificates:

http://perspectives-project.org/

They have a bunch of systems that monitor SSL certs for changes. They call them "notaries". You can run a notary, too.

It helps to make sure the cert you're seeing is what everyone else is seeing and no one is doing a man-in-the-middle attack on you.

The scam will always win -- its all about the scam

[fyngyrz]

1) Stop selling the idea that certificates "verify" who you're talking to. They don't. They never did. As soon as I compromise your server -- easily done, as history shows -- I have your certificate. If it is remote across your network, a little more work, but still, soon I'll have it. Now you have still encryption of the intermediate channel, but the wrong person is catching the data.

2) Tell the truth for once, and let people know that certificates provide encryption of the intermediate channel, hardening ONLY that channel against interception (but NOT proofing it.) ID is NOT provided, only an invalid assumption of ID built out of the lies of Verisign and its co-scammers.

3) Stop "allowing" certificates at all. We can easily make them at zero cost, and we should. The whole "Verisign" thing is a complete and utter scam, and always has been, one with the collusion of the browser makers with the fake warnings and "scare the user" policies. Giving ownership of the encrypted data channel to profit making operations was a stupid, stupid move, and has served only to cripple e-commerce from the day it began -- it's one more useless and endless cost for the small entrepreneur to have to absorb, and therefore in the end, the consumer. Further, it has evolved into a higher stakes / cost game of buying that little green verification bar in some browsers. Scams upon scams.

...but of course, this will never be fixed, because the whole "that's who you're talking to" scam is big, big money (extorted from merchants and others who want to provide encryption to the general public), and big money wins out over reality every bloody time.

Doesn't matter how "smart" the people are working on this. They'll go with the money.