Customer Success Testimonial: Recovery is Everything
Was it Iran?
Abdulhayoglu has also taken heat for claiming the counterfeiters were acting on behalf of the Iranian government, even though his sole support for that contention is Iranian IP addresses used to hack into the RA's system and to test the validity of one of the forged certificates.
Even after the purported hacker stepped forward to say he acted on his own and provided incontrovertible proof he had access to one of the forged certificate's private key, Abdulhayoglu has continued to insist the attack could only have been carried out by a well-funded, state-sponsored actor.
His claim is that the attackers used a “zero-day vulnerability followed by reverse engineering” of code taken from the reseller's fully-patched server.
According to an interview the purported hacker gave to Rob Graham, CEO of Errata Security, the zero-day exploit involved a SQL injection, which is the most common form of attack on the internet. The code that was reverse engineered was written in Microsoft's C#, which unlike languages such as C++, is extraordinarily easy to decompile.
“This is again the attempt by the CEO to be disingenuous,” said Graham, whose company regularly carries out penetration tests to gauge the security of clients' systems. “We've done hacks like this, so when he says it was so complex it must have taken a team, no. We've done simple hacks like that that took one person one day.”
Whatever exaggerations or unsubstantiated claims Abdulhayoglu has bandied, the CEO should be commended for admitting the shortcomings of the industry he is part of. He was a founding member of the CA/Browser Forum, the group that got extended validation certificates off the ground. He also backs other industry initiatives to improve SSL security, including the Certification Authority Authorization Resource Record currently under consideration by the Internet Engineering Task Force.
Another proposal under consideration is known as the DNS-based Authentication of Named Entities. It would go a long way to locking down the SSL system, but it requires the implementation of DNSSEC, or DNS Security Extensions. The cryptographic system for improving the security of the internet's domain-name lookup system has been gaining steam, but it's got a long way to go.
Another initiative includes the Google Certificate Catalog, which indexes technical details of all SSL certificates spotted by the search engine's agents
Given the growing sophistication of hacks that have hit Google and what many believe could be hundreds of other companies – virtually all of which count on SSL to secure their internal networks – here's hoping the industry puts aside its security theater antics and heeds his calls for reform.
“It's pretty crappy, but it's what it is now,” White Hat Security CTO Jeremiah Grossman said, referring to the SSL system. “It is definitely weak. It could fall down at anytime.” ®
COMMENTS
Mostly a problem of trust, broken CRL and bad programming then?
So it seems that most of the problems here are either as a result of -
1. Sloppy string validation in Common Names and URL bars
2. Massive proliferation of "trusted" entities who may or may not have good security practises or even be trustworthy at all
3. Broken revocation methods
4. Un-revoked certificates using obsolete hashing or encryption methods
I've been working with SSL/TLS for a bunch of years now and 2, 3 and 4 have been obvious for a LONG time. 1 is more interesting because you would have thought you'd be extra, extra careful in a security application, if only because the programmers are working on security systems!
Apart from CN validation though, the problems here are HTTPS problems, not SSL or TLS problems. SSL has many wider applications than securing the web. These frequently do not involve any public authority trust at all, have manual revocation methods, cipher suite restrictions and no plaintext-to-encrypted bridge.
The fundamental difficulty here is that the problem is almost impossible to completely solve. A little like DRM (which can be summed up as "how do I give the content and the key to someone, but prevent them using the two together in ways I dislike?"), the trust problem comes down to "How do we establish a relationship of trust between two parties that have never met?". The solution we have been using so far is to involve a third party that the user has never met either. When there were only a handful of these third parties it was perhaps not too much of a stretch; now I look at firefox and there at least 50 "authorities" each with a couple or more root certificates. I know several of them have issued bad certificates in the past and others have been compromised. But if I get rid of them I lose the ability to 'secure' a lot of comms, though secure is the wrong word. Tricky.
tl;dr - The HTTPS infrastructure is in need of a lot of work. SSL/TLS itself less so.
We are all too lazy
One key problem is that we are all too lazy to bother deciding who we want to trust. This is too difficult! We are happy to rely on browser vendors huge list of root CA's from organisations who obviously do not have adequate security and are happy to sell that "secure feeling" of a $10 certificate.
This problem is unlikely top be solved by some technical solution such as improved protocols IMHO.
Perhaps our browser needs some kind of "trust mode". When in "banking mode" it will not trust domain validated certififates. When in "Dissident mode" it will drop trust in Chinese certificates or whatever local regime I do not trust. Etc.
Best regards
Steen
I shouldn't need to have a CA sign my cert
Cert signing is a racket. I have to buy a cert from a CA, a cert which expires in a few years and bestows zero trust in my site. The only reason I'm buying a cert at all is to stop the browser from complaining about the cert.
Why can't I as an individual generate my own cert and sign it with a PGP key? When a browser encounters a site with a PGP signed cert it could present the user with a notification to inspect the web of trust and then choose to trust the site or not based on that. It could sit between a self signed cert and a CA signed cert in the security model - enough for personal & small businesses to use but probably not something a bank or ecommerce store might use.
I'm aware that there are some free CAs, but obtaining a cert is almost as odious as it is for a commercial CA. In either case, the CA isn't providing my site with any extra trust, it's just shutting the browser up.
I'm surprised that some of the free / open source browsers and SSL impls don't realize the chilling effect this is having secure communications and do something to rectify it.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Customer Success Testimonial: Recovery is Everything
