TLS

TLS is defined in RFC 6176.

Since a transport protocol can operate without TLS, there are two way to signal the server to apply it:

Once the client and the server agreed on using TLS, they use handshaking to establish the common parameters. The client presents the server the list of supported cipher and Message Authentication Code (MAC) suites. The server picks the best one that it supports. The server usually authenticates itself by a SSL certificate. The client could and should do the same but in most cases, it does not. See SSL/TLS Issues below.

Session keys are generated in one of two ways:

Known Attacks Against TLS

Other Security Issues

TLS is point-to-point, not end-to-end encryption. A man-in-the-middle attack is possible due to PKI discredit. There are many transparent proxy servers available, which do SSL inspection; for example, !BlueCoat. There are intermediate CAs that have an ability to issue a certificate for any domain name on a fly, meaning that a browser wouldn’t know if it talks to a real web server or a fake one unless the web server is pinned by a developer in the browser or a web server generates its own client-based certificates for mutual authentication. Large corporations, ISPs and government agencies do SSL inspection for their own purposes, be aware of that! For more information, read this report: FIGHTING BACK AGAINST SSL INSPECTION, OR HOW SSL SHOULD WORK

Also, be aware that some certificates might still uses MD5 signatures, which are not secure anymore. It is possible to generate another certificate with the same MD5 signature for a different public key! See Wikipedia article about this - MD5