I was looking through the working of SSL V3, and found that a connection state is defined by a set of things, including
I couldn't found the use of these in the SSL protocol.
As I understood from reading, after having a handshake, SSL creates a 48 byte master secret, which is used in encryption and this secret is shared by both client and server.
For what are these four values used?
In TLS (that's the standard name for SSL; TLS 1.2 is like "SSL version 3.3"), client and server ends up with a shared secret (the "master secret", a 48-byte sequence; when using RSA key exchange, the master secret is derived from the "premaster secret" which is the 48-byte string that the client encrypts with the server public key). That shared secret is then "extended" into six values:
The "extension" uses the PRF described in section 5; it can be thought of as a hash function with a flexible output length.
TLS main purpose is to keep data confidential; however, it also aims at maintaining data integrity: if someone or something, willingly or not, alters data in transit, then the receiver must be able to reliably detect it. Detecting alterations is important in many protocols; moreover, if an attacker can modify data, he can often handcraft precise alteration which, when sent to the peer in lieu of the correct data, may result in reactions which leak information about the encrypted data. Therefore, we not only want to detect alterations for the own sake of integrity, but also because unconstrained alteration may result in a confidentiality breach.
So we need encryption (for confidentiality) and integrity control (to support confidentiality, and because integrity is also needed by itself). This calls for several algorithms, typically AES for the symmetric encryption part, and HMAC for the integrity control. HMAC is a Message Authentication Code algorithm, which is a kind of "hash function with a key" (HMAC is built over a true hash function, like SHA-256, with a key inserted "the right way"). The HMAC value is computed by the client with its "client write MAC key" and appended to the record data; the server will recompute the HMAC value and see if it matches the one which was sent.
The encryption part requires a key (and an IV for symmetric encryption algorithms which use CBC mode, and this is subject to a few subtleties which depend on the SSL protocol version, so I will not detail these here). The MAC also needs a key. Using the same key for two distinct algorithms is, as a general rule, not recommended at all: there may be unwanted interactions between the two algorithms, an improbable but not impossible event which has not been thoroughly studied. So, to be on the safe side, we generated two keys, one for encryption and one for the MAC. The two keys come from the master secret, but the derivation mechanism is like a hash function, so it supposedly makes it impossible to guess the MAC key even if you know the encryption key, and vice versa.
Since TLS has a key derivation function (the "PRF") which can produce outputs of arbitrary length, it was easy to mandate production of encryption and MAC keys distinct for both directions (the key used by the client to encrypt data -- and that the server uses to decrypt received data -- is distinct from the key used by the server to encrypt data it sends to the client). Using distinct keys avoids problems with attackers who could otherwise get a copy of an encrypted record sent by the client, and feed it back to the client as if it was sent from the server. With distinct keys, the client will reject the attempt, because the HMAC value will not match what the client expects (it will be a HMAC computed with the client write MAC key, not with the server write MAC key).
There are newer symmetric encryption modes which do the encryption and the MAC with the same key in a controlled way, e.g. GCM -- and AES-with-GCM can be used with TLS although you may have a hard time finding compatible implementations (this is rather new).
SSL does more than just encrypt the data. It also protects it from undetected modification. To do this, when it encrypts data, it also generates a cryptographical checksum (which is termed a message authentication code or 'mac') of the plaintext record, and includes that in with the encrypted record. Now, to make sure that someone in the middle can't compute their own mac if they modify the record, the computation of these mac's use keys (which are ultimately derived from the master record, just like the encryption keys are). On decryption, the decrypter also computes the mac of the plaintext it got (using its copy of the keys), and compares it to the mac within the record; if they are identical, then the record was not modified in transit.
So, the client_write_mac_secret is the secret key used to protect records that the client sends (writes) and the server receives; the server_write_mac_secret is the secret key used to protect records that the server sends, and the client receives.
Note that both sides has both secrets; the client uses client_write_mac_secret to protect the records it sends to the client, and the server uses client_write_mac_secret to validate the records that it receives from the client.
server_write_key and client_write_key?
$\endgroup$