TLS & SSL
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols that provide communications security over a computer network. [...] Websites use TLS to secure all communications between their servers and web browsers. (Wiki)
In their essence, these protocols are designed to prevent eavesdropping or tampering. TLS operates directly on top of TCP, which makes it possible for higher-level protocols to be left unchanged while providing a secure connection. This means that below the SSL layer, HTTP is identical to HTTPS.
Note: SSL specifically refers to the proprietary protocol designed by Netscape in the mid 90's. These days, the terms TLS and SSL seem to be used almost interchangeably.
Main properties:
- Connection is private as symmetric cryptography is used to encrypt the data transmitted. Unique keys based on a shared secret (established during a handshake) are generated for each connection.
- Identity of at least one of the parties (typically the server) can be verified using asymmetric cryptography.
- It ensures integrity of the connection since each of the messages includes a message authentication code (MAC).
A third party can theoretically be able to see: IP address, port, data amounts (roughly), encryption and compression algorithms. Since a browser typically needs to request an IP corresponding to a host name from a DNS, a host name might be revealed as well (not the rest of the URL though).
Some common abbreviations:
- SHA: Secure hash algorithm
- MAC: Message authentication code
- HMAC: Hash-based message authentication code
Handshake
The client initiates the handshake, presenting a list of supported cipher suites (these consist of ciphers and hashing functions) and compression methods it supports. The server picks the highest version of TSL/SSL for both of them, and sends the verdict back to the client, typically accompanied by its digital certificate. The client generates a random number, encrypts it using the server's public key and sends it back to the server. It decrypts it utilising its private key and this number then functions as a basis for a unique session key, which serves for encrypting and decrypting data until the connection is closed.
Note: Pseudorandom key generators are almost always used to generate unique session keys (client side in the process described in the previous paragraph). High level of entropy in their generators and initialisation vectors is therefore required for if the session keys can be guessed or inferred, the whole mechanism is compromised.
Digital Certificates
Digital certificate is a proof of the ownership of a public key. If the signature is valid and the examiner trusts the signing authority, the certificate can be trusted.
Certificate Authorities sign digital certificates with their own private keys -> in order to check that a certificate has been issued by a trusted authority, you just need their public key.
Certificate chains exist because, well, in order to trust a certificate authority, you need to get their certificate. Which is signed by something... signed by something... until you reach the root certificate, which is self-signed and you simply implicitly trust it. These root certificates typically come with operating systems.
A few vulnerabilities...
Replay attack, commonly known also as a playback attack, involves malicious or fraudulent repeating or delaying of valid data transmissions. Session tokens or sequence numbers are a common countermeasure. If a unique session key is included in each MAC of a message, it is impossible to later carry out a replay attack.
Heartbleed is a bug in OpenSSL which exploits the trustworthiness of a server. Heartbeat is a mechanism of keeping a connection open even when no data transmission is going on. A client sends a message to a server and expects it to respond with an identical phrase. However, the request also states how many characters the client expects in response. The server always replies with a message containing the requested amount of characters, regardless of the actual contents of the message, which can lead to leaking potentially vital information (such as keys). Best explanation can, naturally, be found on XKCD.
CRIME, which stands for Compression Ratio Info-leak Made Easy, is an attack exploiting the properties of the DEFLATE compression algorithm. If a compression is used while utilising an HTTPS connection, authentication token is often sent along with the request. If the attacker can eavesdrop and manipulate a browser into sending crafted requests, they can supply fake authentication token and then infer whether it (partially) matches the real token by observing the size of the encrypted packets. Really, the problem is that data is compressed before encryption. Amazing, almost precognitive, explanation can be found here.