At the end of the TLS handshake protocol,
the server and the client have agreed on three keys,
which they've extracted from the master secret--
a key for a symmetric encryption function, an initialization vector for that encryption,
and a key for a hash function.
The goal now is to protect the traffic between the server and the client.
This will be in the form of requests for webpages.
A typical HTTP request is to get some webpage.
Then the server will send a response.
I should reiterate that TLS protects many kinds of traffic.
The protocol is not specific to HTTP.
What I'm really talking about here is HTTPS,
but the record protocol is the same regardless of how we're actually requesting the traffic.
So this response is the contents of some webpage,
which can be quite long. This could be many kilobytes of data.
We need a way to encrypt that response and send it back to the client.
The responses will call M.
We want both confidentiality and integrity checking,
so we're also going to include a MAC, using the hash function,
so that's going to be HMAC(M).
This uses kh to key the hash function for HMAC.
This is similar to what we talked about in Unit 2
where we're hashing the message, but because it's a keyed hash function,
it depends on the key as well.
Finally, we're going to have some padding to fill up the block size.
Now we want to send this whole response--the result of concatenating
all of these--over the secure channel. We'll call this R.
The way this is done with the TLS record protocol is to use CBC--
that's cipher block chaining mode of operation and some encryption function.
We talked about CBC mode in Unit 2.
As a reminder, this is the way CBC works.
There's an initialization vector.
We break the message into blocks. We'll call those blocks m0, m1, up to m(m - 1).
The first message block is XORed with initialization vector.
The output of that is encrypted using a key.
The key that's used is a key that resulted from the handshake protocol.
This results in the first ciphertext block.
That becomes the input to the next XOR.
That's the way the first response is done,
but in a session there might be multiple responses.
When the next response is done, we don't want to do the whole handshake protocol again.
What happens in the next response, whatever the next message block is--
that's going to be m'0--will be encrypted using CBC mode again
that will produce the ciphertext block at the beginning of the next message.
What we need is an IV here.
We don't want to use the same IV again.
That would make it clear if m0 equals m0'.
The approach that is taken by TLS is to use the last ciphertext block of the previous message
as the IV for the first block of the next message.
This effectively makes it seem like it's one long message.
It seems like this is a good idea.
It's certainly better than reusing the original IV.
It's better than having to do the handshake protocol all over again.
The handshake is quite expensive.
It involves asymmetric cryptographic operations, which are very expensive
compared to the symmetric ones we're using here.
This message does raise an interesting vulnerability.
Let's see if you can figure out what it is using a quiz.
The question is suppose an adversary intercepts the first message.
The adversary learns all the encrypted blocks.
It doesn't learn anything else. It doesn't know the k value of the IV value.
The handshake worked fine.
The question is whether the adversary can learn whether some block is
equal to some guess for that block.
To make this more concrete, suppose the blocks are all 8 bits.
The adversary has intercepted all the ciphertext blocks, but I'll only tell you three of them.
C3 was 10101010. C4 was 01010101. C(n-1)--that's the last ciphertext block--was 11110000,
and what the adversary wants to learn is if the value of m4 was equal to all zeroes.
To do this, the adversary can set the value of m0',
figure out how to make the server give a particular response,
and examine the first ciphertext block.