Ask Slashdot: Does SSL Validation Matter? 243
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?"
I'd say (Score:2, Informative)
Get DNSSEC hosted SSL-keys working (Score:4, Informative)
When SSL keys can be distributed through DNSSEC, there's no need for CA-granted domain-only certificates. Then you can have just "extended validation" certificates from CAs.
Re:I want my free encryption (Score:5, Informative)
Can it altogether. (Score:5, Informative)
As someone else already pointed out, browsers by default do not even warn you if a site's cert is invalid. Why? Because so many sites had invalid certs that people became intolerably annoyed at the constant warnings and just shut them off anyway.
That same study concluded that there are too many Certificate Authorities today, and they do an inadequate job of validating their customers before issuing certificates. Some CAs issued multiple certs to the same party, others actually issued the same certs to multiple parties! (Definitely a no-no.)
It's a broken system. Not because of bad design, necessarily, but because of the failures of people who administer it.
DNSsec is a better solution to Domain Validation. (Score:5, Informative)
Domain Validation (DV) certs are not the same as OV, Organizational Validation, or EV, Extended Validation, certs. Web SSL certs are OV or EV. DV certs are intended to validate that the FQDN is valid (i.e. correctly owned by the domain). This is the job that DNSsec is meant to address in many ways. There's already been public discussion on some of the crypto forums such as mozilla-crypto (ok, for some value of "public" - but it's not a closed list). The DNSsec crowd have asked about putting certificate signatures in DNSsec and the entrenched CA crowd got all up and in arms and huffy about it. But DV certs would just tie the certs to the domain owners, and that's all, which is exactly what can be done in DNSsec. And, yes, we all know, the domain could be faked but that's not the point. The point is to tie a certificate back to the domain owner or not. The OV/EV certs are what validate the organization claiming to own the domain/FQDN. The CA crowd doesn't like the fact that DNSsec can do for free what they can charge money for. DNSsec puts the power totally in the hands of the domain owners (where it bloody well belongs). Now if we could just get certain bloody registrars, like Network Solutions, to let us register our key signing keys, we could get on with things. The root zone (.) is signed. The .org, .net, .com, .edu, and .gov zones are all signed and numerous other ccTLDs are signed. Godaddy and others are reported to be accepting DNSsec registrations. Where is Network Solutions? A sleep at the switch last I looked. And OpenDNS continues to pout, whining "I donwanna... Use DNS Curve or I'm gonna cry." DV certs are a solution in search of a problem and DNSsec is a better solution.
Re:DNSsec is a better solution to Domain Validatio (Score:2, Informative)
NetSol is Verisign, which is a CA. Of course they aren't excited about DV-equivalents...
Re:SSL decisions in secret? (Score:4, Informative)
Well... The fact that it became known does not speak much for their secrecy, and secrecy in this regard is a very relative term, even if the group ever intended it to be a "secret society Illuminate". Sometimes (and I've seen it happen all too often) someone accuses people of discussing things "in secret" only because they weren't a member and the membership signup was not obvious to a 3 year old. Without knowing more about the specific list and group, it is impossible to judge their motives based on an unsubstantiated claim of a "secret mailing list".
I've been a member of "closed" mailing lists before and continue to be to this day. It's generally a question of someone vouching for you. Example... In the dark early days of the Internet and the Robert Morris Worm incident, we had two parallel security lists. To get on the Zardoz list, you merely had to sign up. To get on the ISIS list, you had to have some vouch for you in the "bang path" (uucp notation) between you and them.
More recently, certain mailing lists, such as the recently defunct VendorSec mailing list,. required a discussion amongst the members for you to join. Especially, in security circles, there's a matter of trust and reputation and the very real problems of disruptors , some of whom are "state sponsored" (the government really doesn't like it when you can protect your privacy and your security - you should depend on them for that, right? They long for their good old days of ITAR). Sometimes (SERIOUSLY) some of those lists are there discussing things of a serious enough nature that we don't want the "bad guys" to have a heads up. Some of us have to collaborate in a trusted manner somehow and, yes, we're going to get accused of "operating in secret". But it's just a matter of knowing who you are communicating with and can trust them. This doesn't sound like that kinda list but I would love to know what list it was. There are probably a dozen or more lists on the net right now discussing this very issue, probably including one or more IETF lists. It's generally not a "cabal" and I've never found it hard to join one if you have the reputation to be trusted.
Re:Get DNSSEC hosted SSL-keys working (Score:4, Informative)
OpenDNS lives in it's own little ghetto and can be safely ignored as usual.
Re:The scam will always win -- its all about the s (Score:5, Informative)
Which you cannot guarantee, therefore you cannot use them to validate identity.
The entire industry -- from scamming fees out of site owners to fooling the consumer and coercing and co-opting the browser authors -- is predicated upon the single critical idea that certs imbue a transaction with safety because you know who you're talking to. But the fact is, you don't have any idea who you're talking to; and furthermore, you cannot, and furtherestmore, the cert couldn't tell the user or the browser or the source site if the folks at both ends were the "right ones" even if it was true. All the cert does is implement intermediate communications line security -- as far as we know, presuming the NSA hasn't done what we all know it would most like to do and is either in the process of doing or has already done.
If there were such a thing as a "secure implementation" (which there isn't -- you have no idea where the hack will come from... a business associate? The cert authority? A lover? An intrusion? Use of force? Installation error? Stray gamma ray? Bad chip? Browser vulnerability? Language vulnerability? Worm? Virus? Some combination of the foregoing? Or etc., ad infinitum), certificates still wouldn't assure you it was in place. Claiming that they in any way validate identity is purest scamming.
No. The fact is that as far as we outside the government know, the SSL mechanism presently legitimately encrypts between points, IE the intermediate channel. The next fact is that certificates cannot, period, end of story, provide validation, nor have they ever done so. It's a scam to say that they do if you understand them; if you don't understand them -- and by that, I don't mean just the mechanism, I mean the environment they exist in and are expected to function in and the ways and means people are known to go to to get around such efforts, and the immense benefits available from doing so when they are circumvented -- then you're simply ill-informed and wrong.
Again, we are not. We are talking about the impossibility of implementation, in response to the bogus claim that identification and authentication are possible with the certificate mechanism. Which Verisign (used here as a placeholder for every CA) knows, and is why Verisign and etc don't seriously try to do it. They know perfectly well it's a scam. If they give you something to point at, like the hilarious methods they claim provide your identity (never mind the site's identity), then you'll be misled into trying to address the wrong issue. The actual issue is that this is a scam and cannot work at all, not just that the CAs have no serious knowledge who the certificate holders really are. It's not about identification and authentication. It's about the illusion of identification and authentication. All they have to do is put up a solid enough false front to make it look like they're trying, then misdirect the tech types into tech issues instead of thinking about how the whole system works, and they're golden.