Slashdot Mirror
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?"
Ask the Chinese. They've been pwning our ass for so long, they know what's secure and what isn't.
What's disturbing is that whoever is allowed on this mailing list imagine that they can make decisions out of the public eye and in secret. I call for them to make their discussions public immediately, with their list open to subscriptions and posting, and all past messages archived on the web for all to read. Failing that, we must ensure that no one respects the decisions of any committee operating in secret, for if they hide from the public, they don't have our interests at heart.
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.
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.
It needs to go away.
SSL has numerous applications and needs that it serves. What we really need is a graduated system of "validity" which allows for things that don't need the "uber-valid" level of certs to operate.
Secondly, the long-standing ripoff in terms of costs extracted from this system are a symptom of this problem, creating and maintaining a monopoly-level stranglehold on doing things that don't need to cost nearly as much as they do.
Personally, I would prefer a decentralized web-of-trust kind of system for all but the highest level of confidence (maybe even for that, too, but I can envision a necessity to still centralize the absolute top layer).
-SS "Teach the ignorant, care for the dumb, and punish the stupid."
Personally, I would prefer a decentralized web-of-trust kind of system
Which means that instead of CAs making money, the airlines will, as people will have to fly to key signing parties in order to get their public keys into the global web of trust as opposed to a local one.
Encryption and identity have to be tied together. It's a fundamental aspect of the mathematics. If you can't verify identity on an insecure channel, encryption is useless, as you could be taking to a man-in-the-middle who just takes the traffic from each end, decrypts it, snoops, reencrypts with another key and sends it on. The only way to ensure non-modification without a cryptographically authenticated identity is with quantum encryption, and that can only be done if you've got a single continuous strand of fiber from one end to the other. Good for inter-office links, but not for e-commerce.
Allow a single site to have either multiple certificates or multiple signatures from different providers. This means that important sites could be signed by e.g. both Verisign and Globalsign, so it would be possible for users to remove trust of a provider without losing the TLS protection. Without this, there will never be a free market for certificates and browser makers will have to include root certificates from even the least trustable providers, so it simply HAS to happen. Fortunately it is relatively easy to implement.
For extra points, implement support for off-site certificate stores so third parties can attest to the validity of a particular key. Groups of users could collaborate to verify the certificates of sites, which could create a level of protection against fraudulent certificates from the primary providers. This proposal is much harder to implement securely.
Finally! A year of moderation! Ready for 2019?
I want my free encryption because I don't trust some 3rd party to tell me whether I should trust the web site that I am visiting. Encryption and identity should never have been tied together in the first place. It's unfortunate that this business method has succeeded as long as it has.
I dont see how you can separate encryption and identity - if you do not know who you are talking to then encryption has no value?
Lets say a man in the middle says - Im your bank, please talk encrypted with me. Then the man in the middle just repeat what you say to your bank until you are logged in.
The download certificate on first meet might provide some security, but would make it difficult to do business with unknown entities.
A recent evaluation showed that 80% of sites with certificates did not have them set up properly anyway.
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.
By the same token, If I don't personally know the CA, then nothing they say about identity is at all meaningful. I care very little what random XYZ corp in China says about the holder of key 0xFD5645EB78. What I care about is that that's the same entity I successfully did business with before, whatever their name is.
Frankly, it's just not all that helpful to know that some random entity had the wherewithal to send Verisign a fax with a letterhead (perhaps theirs, perhaps not) on it.
That is, what matters oin encryption is that the entity you're talking to now is the same one you talked to last week.
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.
Hypothetically, I'd tell them to stop worrying about SSL and get busy rolling out IPv6 where this problem (and several other pressing issues) are solved. But that's because I have an engineering mindset, not a committee one. The answer to "Is this technology out of date or poorly implimented?" is universally yes in my world. Nobody gets it right, and it's a bloody miracle the internet continues to work in spite of its own massive structural deficits.
#fuckbeta #iamslashdot #dicemustdie
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.
The CA/Browser forum (which is dominated by certificate authorities) is proposing to make changes in the way EV certificates are issued. The changes weaken EV certs.
Existing EV cert policy is that EV certs MUST contain the organization name, its business name and address, and its jurisdiction of incorporation. In the proposed draft, (p. 13) "Organization name is OPTIONAL".
This essentially makes EV certificates meaningless. The whole point of an EV certificate is to unambiguously identify the business owning the certificate. So if you need to sue, file criminal charges, or send in a collection agency, you know where to send the process server, cops, or collection agents.
(At SiteTruth, our system considers SSL certificates without a business name and address to have no value in establishing the legitimacy of a company. We've always done this for "domain controlled only" certs, and will now do it for EV certs missing a business name or address.)
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.
NetSol is Verisign, which is a CA. Of course they aren't excited about DV-equivalents...
We do need a class of certificate that simply verifies that we're talking to the host we expect to be talking to (ie. that the name of the host using the certificate matches the name of the host in the URL). That's sufficient for encryption-only purposes, where I'm using SSL not to validate the remote end's identity in any way but merely to prevent eavesdropping on the data stream by third parties. DNSSec addresses some of that, but it doesn't provide the encryption layer that SSL does.
Bluntly put, there's a lot of cases where I don't care about the absolute, real-world identity of the entity I'm talking to, only that I'm talking to the same entity every time. Think the Dread Pirate Roberts.
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.
Doesn't matter how "smart" the people are working on this. They'll go with the money.
I've fallen off your lawn, and I can't get up.
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.
I've fallen off your lawn, and I can't get up.
There are a lot of things that I'm waiting for "until such time as", but I don't foresee "such time" happening within one investment horizon.
Just because you can't do it immediately doesn't mean it isn't worth pursuing.
They won't follow that link; they'll just visit the site's competitor.
I don't see how that would drive traffic to competitors. It doesn't make your service unavailable, it only reminds your customers that they should update their software. For example, try installing the latest version of Firefox while you have an out of date Flash player: As soon as the install finishes you get a page telling you that your Flash player needs an update and supplying a link to Adobe's website to download the update.
This is true especially in cases where no update to support DNSSEC is available at all for a given platform.
DNSSEC doesn't strictly require platform support. Someone could pretty easily create a DNSSEC resolver as a browser plugin similar to this one for any given browser.