After having its SSL and EVSSL certificates deemed untrustworthy by the most popular browsers, VASCO announced that DigiNotar, filed a voluntary bankruptcy petition and was declared bankrupt today. This is unsurprising, since a report issued by security audit firm Fox-IT, who has been hired to investigate the now notorious DigiNotar breach, revealed that things were far worse than we were led to believe.
DigiNotar had to fall.
However this does nothing to solve the more fundamental problem of third party trust built into HTTPS/SSL.
With hundreds of CA’s today, each and every one of them posses the technical ability to sign fraudulent certificates which the browsers would validate as genuine. This is a real hurdle for the IT community.
I had a long discussion with Lennie, another poster here on osnews, about some alternative ideas. I believe his “convergence” video link does an excellent job highlighting the issues and potential solutions.
http://www.osnews.com/thread?488772
Personally I favor DNS based solutions which eliminate the underlying need for third party CA’s.
Edited 2011-09-20 23:49 UTC
Seems the encryption scheme behind old HTTPS-protocols in combination with current browser implementations might be broken as well:
http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/
We’ll see what this really means on Friday.
The new protocols are from 2006 and I think support for it in IE started on Windows Vista.
I wonder if this means Microsoft will release an update of their SSL-library for Windows so IE will be fixed to.
An other problem Firefox and Chrome do not support the new protocols yet.
Opera supports it, but it is disabled by default, it is also disabled on IE on Vista and Windows 7 because it is not compatible with all webservers.
Some of the webservers (SSL and TLS/1.0) do not allow browser with newer protocols (TLS/1.1 and TLS/1.2) to connect.
Wow, that is quite a stunning revelation.
The attackers could inject the malicious javascript payload into unencrypted traffic, and then command the browser to pound away at the HTTPS server sending known plaintexts for the attacker to analyze. This part is well known, but I’m quite shocked to hear that SSL is vulnerable to known plaintext attacks.
Given how they claim that the fixes break compatibility with all software running on millions of websites and web browsers anyways, this would be an excellent opportunity for software updates to include support for non-CA based authentication/encryption mechanisms.
Looking further down the line, it would be very nice if all traffic could be secured using the same infrastructure: SSH, email, http, vpn, voip, etc. When I punch in XYZ.com in any client, I should be automatically secured without the need to manually exchange keys.
Who today manually verifies SSH keys? How many people exchange their VPN keys through an unsecure source like email or an unverified SSH connection? We need an easier, more universal solution. And I think it’s within reach, but the tricky part is getting a solution widely adopted.
Edited 2011-09-22 00:59 UTC
Old versions of the SSL/TLS protocols are vulnerable to known adaptive plaintext attacks.
So an attacker has to be able to send a plaintext based on the analyzes of the HTTPS-traffic he/she sees and inject it in the HTTPS-traffic.
Which he/she can with JavaScript from an other page.
The problem is 3 things:
1. the browser allows pages on domain-X to talk to other domains. You don’t even need JavaScript for that, it has always been possible.
2. the browser re-uses the same HTTPS-connection (or session-cache) for different pages
3. biggest problem is that that the old protocols don’t seem to go away.
It is like the IE6-problem for webdevelopers.
For example all versions of IE on Windows XP do not support TLS/1.1 and TLS/1.2. They have no protection against this problem.
But most other browsers and server do not supoprt it either and those that support it have it turned off by default.
Because there are servers that only speak the older protocols which refuse to talk to clients that say they _also_ support the newer protocols.