Computer Security MT24, SSL and TLS

1. $C \to S$: $\mathbf{nonce} _ C$, available cipher suites
2. $S \to C$:
   • $\mathbf{nonce} _ S$
   • selected cipher suite
   • $\langle S, pk _ S, \text{Issuer1}, \mathbf{expiry}, \text{SIGN} _ {sk _ \text{Iss1} }(S \parallel pk _ S \parallel \mathbf{expiry}) \rangle$
   • $\langle \text{Iss1}, pk _ \text{Iss1}, \text{Issuer2}, \mathbf{expiry}, \text{SIGN} _ {sk _ \text{Iss2} }(S \parallel pk _ \text{Iss1} \parallel \mathbf{expiry}) \rangle$
   • …(certificate chain establishing $pk _ S$ is indeed the public key of the server)…
3. $C \to S$: $E _ {pk _ S}(\mathbf{version} \parallel \mathbf{nonce} _ P)$
4. $C \to S$: $E _ {ke _ C}(\text{messages 1 to 3} \parallel \text{MAC} _ {km _ C}(\text{messages 1 to 3}))$
5. $S \to C$: $E _ {ke _ S}(\text{messages 1 to 4} \parallel \text{MAC} _ {km _ S}(\text{messages 1 to 4}))$
6. $C \to S$: $E _ {ke _ C}(m _ 1 \parallel \text{MAC} _ {km _ C}(\mathbf{counter} \parallel m _ 1))$
7. $S \to C$: $E _ {ke _ S}(m _ 2 \parallel \text{MAC} _ {km _ S}(\mathbf{counter} \parallel m _ 2))$
8. …etc…

where:

• $\mathbf{nonce} _ P$ is called the pre-master secret
• Then the master secret is computed by $\text{PRF}(\mathbf{nonce} _ P \parallel \text{master secret} \parallel \mathbf{nonce} _ C \parallel \mathbf{nonce} _ S)$ and used to derive:
  • $ke _ C$ and $ke _ S$ are session encryption keys
  • $km _ C$ and $km _ S$, MAC integrity check for messages from $C$ to $S$
  • IVs for these encryptions
  • Here $\text{PRF}$ is a “pseudorandom function”, and $\text{master secret}$ is the literal string “master secret”.
• (note also that $\mathbf{nonce} _ C$ and $\mathbf{nonce} _ S$ are returned by the server and client in steps 4 and steps 5).

At step 3, the client sends their own certificate chain.

Suppose:

• The client uses a block cipher with block size $n$ bytes
• The client does not use randomised encryption, so that the initialisation vectors are deterministic
• We can inject plaintext into the client’s data, pre-encryption

Then:

• We persuade the client to put a $n-1$ byte known prefix before the secret so that we have blocks and bytes $(p _ 1 \parallel \cdots \parallel p _ {n-1} \parallel s _ 1) (s _ 2 \parallel \cdots )$ where each $p _ i$ is a byte we choose and the $s _ i$ are the bytes of the secret; at this point we don’t know $s _ 1$.
• We observe the ciphertext of the first encrypted block $C _ 1$
• We then ask to encrypt $(p _ 1 \parallel \cdots \parallel p _ {n-1} \parallel g)$ for lots of different values of $g$, until we find one that matches
• We can then repeat with a slightly shorter prefix: $(p _ 1 \parallel \cdots \parallel p _ {n-2} \parallel s _ 1 \parallel s _ 2) (s _ 3 \parallel \cdots )$; note now we know $s _ 1$ and so can repeat the same procedure to determine $s _ 2$.

“Browser exploit against SSL / TLS”

Run a blockwise adaptive chosen plaintext attack by using JavaScript the attacker controls to determine secrets.

By measuring how much the server compresses a response, you can work out if a string occurs more than once in the request. This lets you perform an adaptive attack by guessing strings that might be contained in the secret.