Cryptography Reference
In-Depth Information
The server automatically resubmits the last request, without fi rst checking to
be sure that it came from the same entity that performed the renegotiation. In
general, an attacker can splice any arbitrary data onto the beginning of a secure
connection and neither side has a way to detect it.
When this fl aw was identifi ed, the quick fi x solution was to disable session
renegotiation completely. However, renegotiation in general is a useful feature,
so work began on patching the security hole. In February, 2010, RFC 5746 was
released and it introduced a new client hello extension, extension 0xFF01,
which permitted secure renegotiation. The solution is simple; if renegotiating,
include the secure renegotiation
Client Hello
extension with the verify data of
the connection that is in effect. An attacker can't fake this; if either side does
not believe that it should be renegotiating, it detects the non-empty verify
data and aborts the connection. Likewise, if the verify data is wrong, this is
detected by the side that accepted the renegotiation request. If a client is capable
of secure renegotiation, it must always include an empty 0xFF01 extension in
its initial client hello.
During an initial negotiation, the client will send a secure renegotiation
extension with one byte of
renegotiation info
; the single byte 0. The server
must indicate that it understands secure renegotiation by responding with
its own renegotiation extension. It's permissible for the
Server Hello
response
to send its own extensions — as long as the client has indicated that it will
understand them.
When the client is ready to perform a renegotiation, it must send a
Client
Hello
with the 12 bytes of verify data that it sent with its most recent
fi nished
message. The server must respond with not only the client's verify data, but
also its own verify data as well — the server will respond back with 24 bytes
of verify data.
For example, consider the handshake that was examined at the end of
Chapter 6. The last two TLS handshake messages were the
client finished
and
the
server finished
message, which included the encrypted verify data on the
client side of
e3945aa7b226794d96cfcaf7
and of
45c4904ac71a5948a7198e18
on the server side. Remember from Listing 6-53 that the verify data is com-
puted using the PRF and the master secret — an attacker without access to
the master secret cannot reproduce the verify data, nor can he eavesdrop
on it, because it was transmitted encrypted. However, both the legitimate
client and server have access to the master secret, as well as the verify data
values themselves. An example of a secure renegotiation is illustrated in
Figure 8-7.
Search WWH ::
Custom Search