The recent research highlighting the alarming practice of Secure Socket Layer (SSL) Certificate Authority (CA) vendors using the MD5 hashing algorithm (which was known to be broken since 2005) has shown a major crack in the foundation of the Web. While the latest research has shown that fake SSL certificates with MD5 hashes can be forged to perfection when the CA (such as VeriSign's RapidSSL) uses predictable certificate fields, the bigger problem is that the web has fundamentally botched secure authentication.
The problem is that web browsers make SSL entirely optional and it relies on user vigilance and expertise to ensure that the secure authentication mechanism is working correctly. But this is fundamentally unsound because we know that users will almost always make the wrong decision. One study from Harvard showed that most users will ignore an explicit warning of an invalid SSL certificates and more alarmingly, it showed that 100% of test subjects will log in to a webpage with SSL completely turned off. This isn't difficult to believe given that half of all Banks in the U.S. ran online banking sites with no SSL login page and the customers didn't care. It took more than a year of public shaming for the majority of those banks to strengthen their security but even today, we can go to online banking sites like wachovia.com and they'll still ask you to login on a non-SSL webpage. See image below.
This is proof that the Web standard is fundamentally insecure no matter how secure the underlying cryptography is because web browsers defer to the user for security decisions. Anyone wanting to steal a password doesn't need to go to the trouble of generating a fake SSL certificate at a cost of several hundred dollars per certificate, they merely need to set up a fake http://bankofamerica.com, a fake http://GMail.com, a fake http://Salesforce.com, or any other website and the user will gladly hand their password over. DNS hijacking wouldn't even be necessary if the Internet connection is a wireless hotspot because it's trivial to create a fake hotspot.
But there is a 100% reliable way to implement SSL or Transport Layer Security (TLS) authentication securely. For example, most VPN clients and Microsoft Outlook are good examples of how to reliably implement SSL/TLS authentication. All of these secure authentication solutions have one thing in common: they all take the decision of enabling SSL and which certificates to accept out of the user's hands. If SSL is turned off, the application simply doesn't work. If the certificate is invalid, the application simply doesn't work. The responsibility to keep things working correctly now falls on the shoulders of the Information Technology (IT) department where it belongs and users aren't burdened with confusing security decisions which they aren't qualified to handle in the first place. The application simply works without hassling the user and it works securely 100% of the time.
What is needed is an overhaul of the way web browsers handle secure authentication but the challenge is transition to a more secure mechanism while maintaining backwards compatibility. This could be achieved by implementing a mandatory SSL/TLS HTTPS mechanism that could be bolted on to the existing DNS infrastructure and web browsers with the following mechanisms.
The mandatory SSL/TLS HTTPS mechanism would require changes to all modern web browsers but it would work with existing DNS infrastructure. The system would be backward compatible and the mechanism would remain entirely optional. But once a company, a bank, or a cloud application vendor opts in to mandatory SSL/TLS, they will be able to enforce strong authentication policies throughout the entire globe.
Unfortunately, many companies perceive brand names and the perception of security more than actual security itself and they balk at the notion of good mandatory SSL/TLS security. I've known companies that would rather run an invalid out-of-date VeriSign certificate which cost them several hundred dollars than do it properly with a $20 GoDaddy certificate. These attitudes will eventually change once stronger authentication mechanisms are available and standardized and hopefully they'll implement good SSL security. In the long run DNSSEC could facilitate even easier and simpler Public Key Infrastructure (PKI).
To move forward, we first need to acknowledge that the current HTTPS SSL mechanism is completely broken. It's hard for a security professionals like myself to say that because I risk reinforcing the attitude that we might as well not bother with SSL security to begin with since it's worthless to the majority of users. But when the mechanism is so fundamentally broken, it's time that we all stand up and say enough is enough and we need to fix it.
The Internet standards bodies needs to quickly adopt and standardize a custom DNS record for mandatory SSL/TLS. Then Microsoft, Mozilla, Apple, or Google need to implement the changes on their web browser products to enforce the strong SSL policies.
As Robert Graham, co-founder and CEO of Erratasec pointed out, I have the implementation process backwards because implementation has always come before standardization on the Internet. I must have been asleep writing that last paragraph because I should already know better.
Robert Graham: What made the Internet different from all the other competing internetworks of the 1980s was that people would implement something first, then standardize it. OSI failed because standards led implementations.
Either Microsoft or Mozilla should just implement something, and document the DNS format that they will accept. Standards bodies can catch up later.
Microsoft or Mozilla, the two dominant web browser companies, should simply implement something immediately in their respective browsers and document the required custom DNS records. This would be similar to Microsoft's SenderID standard used for mail authentication which was eventually standardized. Then if the mandatory SSL/TLS mechanism gains acceptance, the standards bodies will follow.
Some might ask "what about Extended Validation (EV) certificates"? They suffer from the same problem in that they rely on the user to decide if the security mechanism should be enforced or not which we know this is virtually 100% unreliable. Furthermore, the cost of EV SSL certificates is insane and it addresses a problem that is the least of our worries today. There's nothing wrong with a cheap $20 SSL certificate if the system is systematically enforced correctly. $20 per year is more than reasonable price given the fact that the Certificate Authority (CA) is merely performing an automated email round trip verification and a few math calculations to sign your digital certificate.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services