At least four web authentication authorities have reported being compromised in as many months, according to research from the Electronic Frontier Foundation that renews serious questions about a technology millions of websites rely on to remain secure. EFF Technology Projects Director Peter Eckersley compiled the data by …
There is a solution pending, sort of.
We can't fix the burgeoning sprawl of CAs -that horse has already bolted.
However we can create a second validation of every certificate via DNSSEC, which means a counterfeit cert becomes detectable by failing a positive check. This is better and easier than the negative OCSP revocation checking that we currently do, or at least it will be when everyone's recursive resolver supports DNSSEC.
Unfortunately the IETF has two groups (DANE and PKIX) both working on this in parallel and there is not yet clarity over which DNS record to use or how. However, the DANE group has just published their scope RFC (http://www.rfc-editor.org/rfc/rfc6394.txt). So there is progress.
DNSSEC doesn't fix the flawed trust model of the CA system
All you are doing by including certificates in DNSSEC is transferring your trust from one centralised and largely unaccountable group of organisations to a (partially) different group of organisations.
Say it was VeriSign that got hacked instead of Comodo and certificates for paypal.com were stolen, you're pWn3d under the CA system when you think you're logging in to PayPal. So let's get our certificates via DNSSEC and we're safe right? Wrong - because the TLD .com is administered by...well done: VeriSign! You are still pwn3d.
We need to start with a completely different trust model, one where individual users can genuinely decide who to trust to verify the authenticity of sites and can modify who they trust without vast swathes of the internet blinking out. Something like Convergence and its flexible notary system is what we need.
Additionally DNSSEC is something that would be of benefit in its own right without being over-burdened with certificates. Trying to lever this additional functionality into a system that has failed to be implemented for years already can only delay its widespread adoption even longer.
You've missed the point in a rush to be negative.
I didn't suggest including certificates in DNS. The suggestion is to include a hash of an existing certificate in DNS, then sign the hash, to provide an additional avenue of verification.
Your point is also made by Marlinspike but he then goes to on to promote Convergence as the dynamic, personal-choice layer (using notaries) building atop multiple functional trust layers. And this DNSSEC mechanism is actually one of them, and he even suggests it in the Convergence talk.
You've also taken the client-side perspective. From a server operator point of view, clients using DNSSEC protects you against *everyone who isn't Verisign* from issuing certificates in your name. No wonder Google are interested (see DNSSEC stapled certs in latest versions of Chrome).
Finally, DNSSEC supports DLV if you don't trust the root. In other words, it already has look-aside notaries.
It seems I have missed a point or two...
...but I wasn't rushing to be negative, simply expressing what seemed logical within the constraints of what I knew. As a result (thanks to your elucidation) I now know a little more and am aware of more things I need to find out about.
If we never question what seems to us to be mistaken in some way for fear of our own misunderstanding being exposed then we limit our means of filling the gaps in our knowledge.
"We can't fix the burgeoning sprawl of CAs -that horse has already bolted."
We can't (plausibly) fix it for everyone. But security-conscious and knowledgeable users can probably fix it for themselves. (I know, this only addresses a small part of the attack tree.)
I'm willing to bet that the vast majority of the SSL-enabled sites I ever visit have certificates signed by a handful of CAs. In fact, they're probably almost all signed by Verisign.
If I do encounter a site with a cert signed by some hole-in-the-wall CA, I'm probably not interested in its contents; and if I am, I'm going to be suspicious.
So, I could write a Firefox extension, along the lines of SSL Blacklist, say, that keeps a list of CA CNs I've approved. If I get a site cert chain that ends in a root cert that's part of the Firefox trust set, but its issuing CA's CN isn't not on the list, the extension warns me and asks me if I want to trust that CA.
Or, of course, I could just decide that I'll likely never want to visit a site with a cert signed by, say, TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı, and delete that root from Firefox's collection of trusted authorities. (Given the number of roots, you'd probably want to do this with a script and some regex matching of CA names.) My proposal's just meant to be a bit more flexible.
This would be more complicated to do for IE (like everything else), but probably still doable. Certainly you can delete trusted certs from the Windows store that IE uses, if all else fails.
Why am I not surprised? OK sure I can see why they might delay notification a day maybe two if the attacker still has access and they are trying to see just what they are upto and securing there systems at the same time but the way places just hold off on informing people of anything let alone a breach of the magnitude that diginotor was is a serious breach of trust.
I would be happy to deal with a company that is honest about security because atleast THEN I can take my own steps after the fact.
NHS "end to end encrypted" webmail "NHS Net" is SSL
The NHS boasts that its webmail is secure, and thus can be used for named patient details.
The security is described as "end to end encrypted" which on inspection is client to central store server over SSL, decryption there of the SSL, and presumably encryption again using keys helped on the server and by its administrators (who are completely trustworthy and immune to any improper pressure) for storage, and then SSL from the server to the browser of the person reading it who will always be the intended recipient.
So is SSL a little less secure?
Anonymous because everyone is very keen to be sure that any potential problem is known and openly discussed so that solutions can be implemented immediately if managerially necessary, and I'd hate to take any credit for bringing anything important up when it should be the IT managers and their contractors who claim kudos.
Do they offer GPG/PGP? That would achieve end-to-end.
What's NHS got to do with it?
FYI, the "end to end encryption" in SSL isn't under scrutiny in this article. The bits that are supposed to make sure that the other side are who they say they are is, and as should be obvious, is found to be severely lacking. So no, SSL isn't more or less secure than before.
But do go to the NHS' webmail site, watch the address bar go yellow or blue or or green, click on the pretty colour, and click on whatever else you have to to get to see the certificate credentials. Look for who issued the certificate, and do your due dilligence research to see if the organisation vouching for the NHS is itself trustable.
Too much work? No idea what above goes on about? Well, that's a problem, but it's been with us from the very beginning. The problems described here are squarely in the business model surrounding the selling of certificates. Were I the NHS I would set up my own trust anchor/"root CA" and do as much as I can with that, just to keep the problems manageable by keeping control firmly in house.
Though a quick search shows they're using redmond's finest. Oh, and from that website: "Warning: By selecting this option you acknowledge that the computer complies with your organization's security policy." Why, what a useful statement to imply from your visitor's actions. And how would you suppose they would know that, eh?
The problem is...
The problem with SSL is not that it itself is insecure (vagaries of renegotiation attacks and crappy implementations aside), but that eCommerce on the World Wild Web uses it in an insecure manner. The NHS may well be using it in the other mode, where the clients are pre-seeded with the certificates of the servers. Not the root signing certificates, but the actual certificates. If you get redirected to a malevolent site, the certificate will not match, even if it was forged to be correctly signed by one of the root certificates.
I contact Fred, and he shows me a document signed by Bill that says that Fred is Fred. I have a list of document signers, and Bill's signature is there. Cool. But what if Bill has been coopted and signed a document that says that Jack is Fred, complete with Jack's biometric identifiers (e.g. photograph!)?
Scenario pre-seeded certificates:
I contact Fred, and he shows me the same document, but this time I already have a copy, given to me in a 100% trustworthy way (that's hard, but not as hard as guaranteeing that Bill is not a signature whore). Now I know that it really is Fred, because only Fred can match the biometrics on the document.
Pre-seeded certificates, sadly, are monstrously inconvenient for use on the WWW. I *could* go to the head offices of each company that I deal with by https and ask them **in person** for a copy of their certificate, and they would just stare at me, "WTF are you talking about?" And do I look like I even have time to go on such a wild goose chase?
Sigh. We have to find a solution, and I have no idea what it is.
Yes, we need a better solution.
The problem is exactly that trust isn't equal to identity and that faceless corporations (CAs) endorsed by other corporations (redmond, mozilla, google, etc.) vouching for the identity of websites, forcing you to rely entirely on their "due diligence" and the sanity of their (arbitrary) paperwork backed by very few guarantees any end-user can make use of, ever, doesn't get you what you need. That is, that you have some sort of assurance that you're talking to who you think you're talking to.
Can't blame them for trying: Back then netscape had to start somewhere, and well, they did. The result is something that models a "chain of trust" or a "tree of trust" rooted at the top, which vaguely fits the usual top-down approach in corporations. And for some reason, hierarchical trees tend to be the perennial favourite of programmers. But even six hundred roots isn't doing the world much good. So something needs to change.
I say we go back to the very beginning, and look at the assumptions there. We're looking for trust, not identity. We're also looking for a system that can deal with vague, fluid, changing notions of same. We're looking for something that's useful in the real world as well as the artificial environment of the wage slave-filled conglomerate.
If you wonder about trust vs. identity: The problem is of course that if you don't know the other side in the first place, there's no point in trying to ascertain it's them. You have no prior knowledge to match against how they check out. In the face of that I'll settle for being reasonably sure we aren't being attacked by a man in the middle.
Even so, you only get that ascertained over the connection between you and their front-end. You haven't an inkling what's going on behind the front. It might be a veritable sausage factory. Anyway, I'll leave that aside for the moment, but it's something that too needs to be dealt with eventually.
There are a couple more things that such a system needs to provide, allow, do, and/or explicitly not provide, withhold, prevent from happening, as the case may be. Which ones can you think of?
I have a slowly crystallising notion of where I want to go; though I've voiced it often enough I won't here. Instead, going on the notion that identity is but a sideshow for establishing trust, share your ideas. What can you come up with?
Security by fiat
This really oughtn't be news. You know, compromise, revoke, new certificate, move on, all is well again. That's what the system was designed for to be robust against, not so?
The deeper problem is that the "trust model" is effectively worthless. For to make use of the model, as a website operator, you hand over a wad of cash to any one of the whatsit 600-odd single points of failure^W^W^W^Wtrust anchors, selected for their outstanding honesty and flawless citizenship by whoever maintains the collection of certificates your browser uses. As an end user, you don't get to choose. You abide by everyone else's choices or you either don't get the data or don't get it in a secure fashion. Which is worse depends on the situation but you aren't empowered to make an informed choice, and anyway you don't need to be informed because you usually don't even get to make that choice.
So you have a security model where, effectively, a number of more or less corporate entities conspire to say "yes, it's all one hundred percent secure and safe, cross our hearts honest". Maybe they'll even get really enthousiastic about it and paint your address bar green instead of gold. Oh rapturous joy!
But the bottom line is that it indeed comes down to being forced to trust the chain of actors, whom you generally don't know nevermind know how well they keep their word, on nothing but their say-so. As an end-user you get no choice at all. As a website operator, well, the only discernible property is the price of the certificate. Why yes, I would go with a certificate from Honest Achmed's Used Cars And Certificates, provided the various repositories finally admit them, oh and of course provided I get a good deal. I mean really now, how is this monetizing of "trust" supposed to be more trustworthy than a used car salesman?
To paraphrase a book on US politics:
We have the best trust money can buy.
my bank says the internet is secure
Let's count the number of ways tht SSL is broken
1) Fucked CA's
realization on a co.uk address