OpenSSL Secure Renegotiation

Question

Has anyone tried to do secure renegotiation on OpenSSL and verify it using WireShark? I can't seem to do a secure renegotiation as far as RFC 5746 is concerned.

I tried to issue the connection command "R" as suggested here. However, when I look into the packet captured by wireshark it shows the message is encrypted. In RFC 5746, it says that renegotiation should be in the ClientHello instead of encrypted handshake message.

I also tried the "reconnect" option on client and both sess_out and sess_in. After the handshake, I inspect all of the packet captured, it just doesn't seem to be having any verify_data in RenegotiationInfo field.

• I understand that by default OpenSSL will disable legacy renegotiation.

• This happens when using Cipher suite ECDHE-RSA-AES128-SHA but not AES256-SHA

Answer 1

The "secure renegotiation" issue is about what happens when doing a second handshake within the context of the first. That's what you do with R in the openssl s_client command; but it implies that the second handshake is encrypted, so it is expected and normal that you see only "encrypted handshake" messages. If you want to see the message contents, use the -msg command-line option on OpenSSL; it will print an hexadecimal dump of the handshake message before encryption. For instance:

$ openssl s_client -connect nameofsomeSSLserver:443 -msg
(...)
    Start Time: 1388406589
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
R
RENEGOTIATING
>>> TLS 1.1 Handshake [length 00eb], ClientHello
    01 00 00 e7 03 02 52 c1 67 3f 99 89 75 92 fa e6
    97 f3 c3 8a f5 2c 30 ba bd 0c 20 e9 1e 3c eb 4b
    3c 2f 85 ec cd 24 00 00 64 c0 14 c0 0a c0 22 c0
    21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
    84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
    03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
    9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
    41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
    12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00
    5a ff 01 00 0d 0c 63 74 19 13 be ac 02 22 04 ed
    81 61 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
    00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
    00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
    00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
    00 11 00 23 00 00 00 0f 00 01 01

In that ClientHello, we can see the different parts:

• 01 00 00 e7: a ClientHello of size 231 bytes (0xE7).
• 03 02: protocol version (TLS 1.1 in this case).
• 52 c1 ... cd 24: the "client random" (32 bytes).
• 00: empty session ID (the client wants to negotiate a new session, not an abbreviated handshake).
• 00 64: length of the list of cipher suites (100 bytes, for 50 cipher suites).
• c0 14 ... 00 03: the cipher suites supported by the client (100 bytes).
• 01 00: one supported compression method: the null compression (i.e. no compression at all).
• 00 5a: length of the list of extensions (90 bytes).
• ff 01: extension type renegotiation_info, as specified in RFC 5746.
• 00 0d: extension contents have length 13 bytes.
• 0c: the renegotiated_connection data has length 12 bytes.
• 63 74 19 13 be ac 02 22 04 ed 81 61: that's a copy of the 12-byte contents of the Finished message from the client during the previous handshake.
• then come a few other extensions.

So this message indicates a "secure renegotiation" as per RFC 5746.

---

The -reconnect command-line option does something completely different: it connects, does the handshake, then closes the connection, and then reconnects with a new connection, and tries to resume the session. Session resumption is quite the opposite of secure renegotiation: session resumption is about reusing the master secret of a previous connection over a new one, while secure renegotiation is about making a new master secret while keeping on the same connection.