0

This question already has an answer here:

At the moment, I am trying to understand TLS in depth, thus reading RFC 5264. In section 6.1 the Connection State of the TLS Record Protocol is explained:

A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, an encryption algorithm, and a MAC algorithm. In addition, the parameters for these algorithms are known: the MAC key and the bulk encryption keys for the connection in both the read and the write directions. Logically, there are always four connection states outstanding: the current read and write states, and the pending read and write states. All records are processed under the current read and write states. The security parameters for the pending states can be set by the TLS Handshake Protocol, and the ChangeCipherSpec can selectively make either of the pending states current, in which case the appropriate current state is disposed of and replaced with the anstehend state; the pending state is then reinitialized to an empty state. It is illegal to make a state that has not been initialized with security parameters a current state. The initial current state always specifies that no encryption, compression, or MAC will be used.

What I take from this excerpt is that the TLS Record Protocol requires certain parameters (encryption keys, MAC algorithms, etc. ) to be set in order to work in a secure manner. The TLS Handshake Protocol provides most relevant parameters. At the very begining of the TLS Handshake, the security parameters aren't set ("no encryption, compression, or MAC").

But I don't get this part:

Logically, there are always four connection states outstanding: the current read and write states, and the pending read and write states. All records are processed under the current read and write states.

What do they mean by read state, write state and pending state?

marked as duplicate by SilverlightFox, techraf, Rory Alsop Aug 18 '16 at 14:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

0

From another post on this site:

It's the state of the encryption. The pending state includes new encryption keys, and initialization vectors. There is a write key for sending data, and a read key for receiving data. The state of the keys and resulting IVs are the read and write states.

So when the current read/write state is overwritten with the pending read/write state it means that the new encryption keys and IVs are to be used for future communication. Until a new Change Cipher Spec message is received.

The significance of these states is that they keep track of the cryptographic state as data is being encrypted and decrypted. When a new key is negotiated these states are updated to use the new key that was negotiated between the peers. Key renegotiation is common among most cryptographic protocols.

Not much to add, that answer pretty much covers it.

  • I found this part in the RFC 5246, which may help further, to understand the states: "The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys. Reception of this message causes the receiver to instruct the record layer to immediately copy the read pending state into the read current state. Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state." – Hansi Aug 17 '16 at 7:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.