Brain Dump

SSL

Tags
security networking

A network protocol which runs above TCP/IP and allows the creation of a secure see page 7, communication channel between a sender and receiver.

A [see page 7, secure protocol] that runes above TCP/IP and allows users to encrypt data and authenticate a servers/vendors identity securely. It allows clients and servers to select cryptographic algorithms or ciphers that they both support using CipherSuites in the handshake.

SSL supports several cryptographic algorithms which must be agreed upon between the client and the recipient at the handshake. example protocols include: SSL_RSA_With_RC4_128_MD5 of the form SSL_ASYMMETRIC-ALGORITHM_With_SYMMETRIC-ALGORITHM_MAC-ALGORITHM.

Protocol Stack

SSL is [see page 9, split] into several sub-protocols.

Handshake Protocol

The [see page 10, handshake] verifies the server and allows the client and server to agree on an encryption algorithm. This is done before any data is transmitted. We also establish a session-key at this stage.

On the handshake the client [see page 15, sends] a list of cipher algorithms they support and the server then responds with the ciphers used for the session-key, any subsequent communications (using the session key) and for message verification (checksums).

TODO: [see page 32, Review] from this. The specific [see page 21, process] is:

  1. Generate a challenge (nonce/random-number) and send alongside a ClientHello message to server. Note: If the client is trying to resume a previous handshake they may send the session id now as well.
  2. Server sends a encrypted Certificate message containing its certificate. Note: Just before this it sends the ciphers to be used and TLS version mentioned above in a ServerHello message.
  3. The client verifies the certificate (see below).
  4. Client generates a pre-master session-key, encrypts with servers public key and sends to server.
  5. Server decrypts pre-master session key, then encrypts and returns the original challenge with the pre-master session key.
  6. The server [see page 22, now] generates a new challenge (signing with its certificate and encrypting with its private key) and sends it to the client.
  7. The client calculates the message-digest on the challenge and server certificate, and then encrypts it with its private key and its certificate; sending the result back to the server.
  8. The server decrypts the message-digest, and verifies the client certificate, sending the session identifier back to the client.

Note: Steps 1-5 performs server-authentication and steps 6-8 authenticates the client. In many cases we don't need to authenticate the client but some systems may require the client to be authenticated (example: banks).

Change Cipher Spec Protocol

Used to [see page 25, change] the encryption being used by the client and server. It is normally used as part of the handshake process to switch to symmetric key encryption.

Alert Protocol

Used to explain the [see page 27, severity] of a message and provide a description.

For example a fatal error will lead to the immediate termination of a connection (other connections in the same session may continue) and the session IDs may be invalidated to prevents them being used to open new sessions.

Record Protocol

[see page 29, Splits] the data that needs to be sent into fragments which are each compressed, encrypted and can be sent separately.

After compression, but before encryption, the MAC address is added to the fragments (using a previously agreed open MAC algorithm (example: SHA256)).

Vulnerabilities

  • Failing to [see page 45, check] SSL certificates.
  • [see page 46, Certificate Authority] gets hacked or fake certificates were issued.

Countermeasures

HPKP

A security concept where browser [see page 47, remembers] the public key of domains it connects and refuses new certificates for that domain with a new key.

This was essentially abandoned in 2017 due to their being no way to recover from a browser storing a wrong public-key (among other security concerns).

Certificate Transparency

A collective [see page 47, initiative] to publicly share info on all issued certificates.

Essentially keep a record of all issued certificates and keep track of any rogue-certificates which we can then revoke.

Organisations can check if a rogue certificate is issued in their name.

Links to this note