The Future of Web Authentication
Many security experts believe the Internet's trust model is broken. Figuring out how to fix it will take time and collaboration
Web authentication protocols took a pounding last year. Problems with the Secure Sockets Layer and Transport Layer Security protocols, which encrypt all sorts of communication among websites, were at the center of several security breaches. Hacks of high-profile certificate authority providers undermined the security of some of the Internet's biggest brands, including Google and Yahoo; new man-in-the-middle attacks hit the Web; and the powerful Beast vulnerability exposed the most commonly used versions of SSL and TLS.
More Security Insights
White PapersMore >>
- Agile Service Desk: Keeping Pace or Getting out Paced by New Technology?
- Inside Threats: Is Your Company at Risk?
Taken as a whole, it appears the Internet's trust model is broken. However, many security experts aren't ready to scrap SSL. Rather than starting over, they recommend fixing the existing system. It's clear that we need to evolve the way we authenticate on the Web; the question is, how?
"Anything that requires us to migrate the entire Internet to a different protocol isn't going to happen," says Moxie Marlinspike, a noted SSL researcher and co-founder of Whisper Systems, a mobile security software developer that Twitter acquired in November. "Right now, particularly in this space, ideas are easy, but it's getting it done that's the hard part."
How We Got Here
Netscape created SSL in the 1990s as a way to encrypt sensitive information transmitted as part of online transactions--from login credentials to financial transactions. TLS 1.0 came out in 1999 (nearly identical to the then-current SSL version), and new versions have followed. While TLS is the most advanced protocol for authenticating online transactions, common parlance often refers to it as SSL.
Web authentication rests on the integrity of the certificate authorities. CAs check the identities of websites and issue public key infrastructure certificates, which are then used to verify websites' authenticity and enable the transmission of encrypted information between Web browsers and SSL servers.
When a person wants to view or interact with an HTTPS site--a secure site that uses the SSL protocol--the Web browser requests that the Web server identify itself. The server provides a copy of its SSL certificate, and the browser decides if it trusts the certificate and the site before agreeing to exchange encrypted data (see diagram, below).
The weak links in the SSL scheme are that there's no overarching system or authority to rate, rank, or approve CAs, and there are no standards for how certificates are issued. It's up to the browser vendor to decide whether to trust a specific CA, and those vendors haven't been careful enough with those decisions.