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:
- use a different port (for example, 443 for HTTPS instead of 80 for HTTP)
- use protocol specific command (for example, STARTTLS in SMTP or IMAP protocols)
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:
- a client randomly picks a number and encrypt it with the public key of a server, which is included in its digital certificate. Both parties then use this random number to generate a unique session key.
- Diffie-Hellman key exchange that provides forward secrecy, meaning that a recorded encrypted session cannot be recovered later even if the private key is revealed. This forward secrecy can be affected by server-side session management mechanisms. For example, long-lived TLS session tickets defeat it.
Known Attacks Against TLS
- Renegotiation. To protect against it, the client and the server are required to provide all previous handshakes. See RFC 5746 for more details.
- Protocol Downgrade. Newer version of TLS 1.3 (draft) would not allow such downgrades.
- Cross-protocol (DROWN). Uses servers that support SSLv2 to break the RSA encryption and then to obtain the session key for TLS sessions. !OpenSSL implementation of SSLv2 makes such attack real-time with the modest computing power.
- BEAST. Uses Cipher Block Chaining (CBC) vulnerability in TLS 1.0 on the client side using Java applet. It stands for Browser Exploit Against SSL/TLS.
- CRIME. Exploits the weakness in TLS compression to recover a content of a secret authentication cookies and perform session hijacking. To protect against it, TLS compression should be disabled.
- BREACH. Exploits the weakness in HTTP compression that is not practical to turn off.
- Timing attacks on padding. Lucky Thirteen is an example. Can be mitigated in TLS 1.2 by allowing only AES-GCM suite. AES-CBC is vulnerable.
- POODLE. Works only on SSL 3.0. On average takes 256 SSL requests to reveal 1 byte of encrypted message.
- RC4. Now deprecated.
- There are many other attacks (see Wikipedia).
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