3

I'm studying the SSL/TLS protocol, more specifically its handshake. I know that initially, a client sends a Client Hello message to the server which includes the TLS version supported by the client.

I have an application that uses HTTPS connections, implemented with WinHTTP in the client and Apache Java in the server. I'm tracing the HTTPS traffic with Wireshark, which looks like this:

Client Hello,         version-TLS 1.2
Server Hello,         version-TLS 1.2
Client Key Exchange,  version-TLS 1.2
Client Cipher spec,   version-TLS 1.2
Application data,     version-TLS 1.2
Encrypted alert       version-TLS 1.2  [from client]
FIN                   version-TLS 1.2
ACK                   version-TLS 1.2

I don't know what Encrypted alert means (in Wireshark it is displayed as Encrypt alert (21)) - since it is sent by the client I'm assuming it's a Close notify alert.

A few seconds after the initial session is closed, a new session starts as follows:

Client Hello,         version-TLS 1.0
Server Hello,         version-TLS 1.0
Client Key Exchange,  version-TLS 1.0
Client Cipher spec,   version-TLS 1.0
Application data,     version-TLS 1.0
Encrypted alert       version-TLS 1.0  [from client]
FIN                   version-TLS 1.0
ACK                   version-TLS 1.0

From this, I conclude the version changes, and so the cipher.

This doesn't seem to happen every time: Sometimes a new session will use TLS 1.2, sometimes it falls back to TLS 1.0. What's the reason of this?

Steven Volckaert
  • 1,193
  • 8
  • 15
Vishal Santharam
  • 133
  • 1
  • 1
  • 6
  • 1
    Can you log the negotiation in (one of or both of) your respective libraries? You should be able to retrieve details more easily that way. You can only speculate when you have just network data. – deed02392 May 15 '14 at 09:50
  • @deed02392 thank you, but currently i dont have access to any of the Logs. All i want is an initial thought where to begin. – Vishal Santharam May 15 '14 at 10:01

1 Answers1

2

Your logs are partial; you don't show all packets. Notably, there cannot be in SSL an "application data" record if a handshake has not been completed, and a complete handshake (abbreviated or not) necessarily contains two "change cipher spec" messages. Also, note that when a system sends several successive handshake messages (as is common for a server: the ServerHello is usually followed by a Certificate and then a ServerHelloDone), the messages will usually be wrapped within the same record.

As for versions, there are two of them in SSL: the protocol version negotiated in the ClientHello and ServerHello, and the one used in the record headers. They do not necessarily match (although they should, at least after the pair of hello messages). You should inspect these field more thoroughly.

After a "change cipher spec", subsequent records are encrypted, so Wireshark cannot see their contents; only the general type (handshake, alert, application data...) is visible, because it is part of the record header. This is why you see "encrypted alert".

Some clients will try several versions: they first begin with a high announced version, but they don't like what they see, they may try again with another announced maximum version. This may be what you observe.

This answer is a detailed introduction to SSL/TLS, which should help in analysing recorded handshakes.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475