История изменений
Исправление LamerOk, (текущая версия) :
Ох, лол. Меня даже вчерашний шторм не разбудил. В общем, посмотрел в RFC.
В TLS 1.2 единственный способ форсировать переговоры - переполнить счётчик пакетов:
6.1. Connection States
...
sequence number
Each connection state contains a sequence number, which is
maintained separately for read and write states. The sequence
number MUST be set to zero whenever a connection state is made the
active state. Sequence numbers are of type uint64 and may not
exceed 2^64-1. Sequence numbers do not wrap. If a TLS
implementation would need to wrap a sequence number, it must
renegotiate instead. A sequence number is incremented after each
record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0.
После первого хендшейка попытки можно игнорить:
7.4.1.1. Hello Request
...
This message will be ignored by the client if the client is
currently negotiating a session. This message MAY be ignored by
the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission
precedence over application data, it is expected that the
negotiation will begin before no more than a few records are
received from the client. If the server sends a HelloRequest but
does not receive a ClientHello in response, it may close the
connection with a fatal alert.
А в TLS 1.3 переговоры вообще запрещены напрямую:
4.1.2. Client Hello
...
Because TLS 1.3 forbids renegotiation, if a server has negotiated
TLS 1.3 and receives a ClientHello at any other time, it MUST
terminate the connection with an "unexpected_message" alert.
If a server established a TLS connection with a previous version of
TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
retain the previous protocol version. In particular, it MUST NOT
negotiate TLS 1.3.
В таком сценарии после хендшейка никакого "служебного" трафика вообще не будет до самого конца сессии.
Исходная версия LamerOk, :
Ох, лол. Меня даже вчерашний шторм не разбудил. В общем, посмотрел в RFC.
В TLS 1.2 единственный способ форсировать переговоры - переполнить счётчик пакетов:
6.1. Connection States
...
sequence number
Each connection state contains a sequence number, which is
maintained separately for read and write states. The sequence
number MUST be set to zero whenever a connection state is made the
active state. Sequence numbers are of type uint64 and may not
exceed 2^64-1. Sequence numbers do not wrap. If a TLS
implementation would need to wrap a sequence number, it must
renegotiate instead. A sequence number is incremented after each
record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0.
После первого хендшейка попытки можно игнорить:
7.4.1.1. Hello Request
...
This message will be ignored by the client if the client is
currently negotiating a session. This message MAY be ignored by
the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission
precedence over application data, it is expected that the
negotiation will begin before no more than a few records are
received from the client. If the server sends a HelloRequest but
does not receive a ClientHello in response, it may close the
connection with a fatal alert.
А в [TLS 1.3] (https://www.rfc-editor.org/rfc/rfc8446) переговоры вообще запрещены напрямую:
4.1.2. Client Hello
...
Because TLS 1.3 forbids renegotiation, if a server has negotiated
TLS 1.3 and receives a ClientHello at any other time, it MUST
terminate the connection with an "unexpected_message" alert.
If a server established a TLS connection with a previous version of
TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
retain the previous protocol version. In particular, it MUST NOT
negotiate TLS 1.3.
В таком сценарии после хендшейка никакого "служебного" трафика вообще не будет до самого конца сессии.