Related: "New Visual Studio 2013 Security Feature: ASP.NET Identity"
Developers and IT professionals regularly use the term SSL when speaking about securing network communications. However, the term SSL has technically been retired for over a decade. I'm probably being too pedantic, but I figure that if so many of us regularly use what's arguably the wrong term for something so fundamental to what we do, then it's likely that there are several different aspects of this important technology that we don't realize 'when tackling daily tasks. As such, I thought it would be worthwhile to take a quick review of some key points about SSL or TLS.
SSL is Dead -- Long Live TLS
According to Wikipedia, SSL was initially developed by Netscape. The first real version of the protocol to see usage was SSL 2.0, which debuted in February 1995. SSL 3.0 addressed several different security flaws from the previous version that was released in 1996. There was, however, no further or subsequent version past SSL 3.0 as it was completely replaced by TLS 1.0 in 1999.
Although TLS actually identifies itself as SSL 3.1 during initial handshake operations, the reality is that TLS is better thought of as a replacement to SSL rather than being a mere successor. To be more specific, SSL 3.0 and TLS 1.0 are different enough that they're not actually compatible. As RFC 2246 states, “The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate.”
It's also worth mentioning, of course, that some of the differences in the ways that SSL and TLS are commonly believed to differentiate can stem from some variant ways in which these security protocols have been implemented by larger vendors or solutions providers. For more information see this answer on StackExchange's security site. Otherwise, TLS has seen several different minor revisions since 1999, including TLS 1.1 and the current version, TLS 1.2 that was released in August 2008.
TLS Serves Two Primary Functions
TLS is most commonly associated with HTTPS, but it's also heavily leveraged to secure a host of other types of communication, such as to secure connections to RDP, SQL Server, and virtualization hosts and clients. In addition, it's also useful to secure FTP, SMTP, VOIP, and a host of other 'Internet and network' protocols. In terms of how it actually secures communications, it does that by serving two primary functions: authentication and encryption.
Authentication is, ultimately, handled by means of certificates, which help clients and servers validate the identity of one another through the use of public key infrastructure and certificate authorities. More importantly, this aspect of TLS can be bypassed in the case of self-generated certificates (i.e., certificates where no trusted third party is used to help authenticate the identity of the endpoint in question).
Related: "OWASP Top 10 Project: Security Vulnerabilities for ASP.NET"
Once identity is established, TLS then enables encrypted communications between endpoints to prevent snooping or tampering of communications, which secures communications from any outside parties. Overall, the means and mechanism of how TLS is initialized (typically within a fraction of a second) is a great example of just how complex and non-trivial something we all take so much for granted can be when it comes to actual implementation details. Along those lines, I know of no better overview of how all this stuff works' than Jeff Moser's excellent overview blog post entitled, "The First Few Seconds of an HTTPs Connection."
TLS is Not Perfect
As amazing, complex, and pivotal as TLS is to securing every-day communications and scores of things that we effectively take for granted, it's not perfect. In fact, it's something that should highlight just how hard it is to get 'security right'' when it comes to any development task. For example, just look at some of the revisions to TLS 1.1 and 1.2 -- in terms of the security holes they fixed as outlined on Wikipedia. Or take a quick peek at some of the known attack vectors that TLS has either addressed or is currently addressing.
Sadly, it's also worth pointing out that as amazing and powerful as TLS has been over the years, recent revelations that the NSA interjected their own back door' into the Dual_EC_DRBG encryption algorithm have severely weakened the validity of certificate authorities and have made TLS much more prone to man-in-the-middle attacks and decryption at the hands of the NSA. Granted, it's arguable that TLS remains relatively effective against anyone who is NOT the NSA, but (while I'm no cryptologist) it also seems logical to assume that since a backdoor does exist that very intelligent individuals or highly motivated groups are busy trying to find said backdoor to further their own goals. In other words, it's safe to say that the NSA have ruined the party for the rest of us by means of their cheating and subverting such critical security components leveraged so heavily in modern computing.
