8

I am trying to debug a TLS handshake between two SIP trunk endpoints: .75 and .82. Mutual authentication is being used.

.75 sends:

  • Client Hello
  • Certificate, Client Key Exchange
  • Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
  • Encrypted Alert

.82 sends:

  • Server Hello, Certificate, Certificate Request, Server Hello Done
  • Change Cipher Spec, Encrypted Handshake Message
  • [FIN, ACK]

From the wireshark trace on .75, the details of the Encrypted Alert is: Content Type: Alert (21)

How do I know what causes the failure from 82?

Yusuf
  • 83
  • 1
  • 1
  • 6

1 Answers1

7

Your .75 machine (the client) sends an "encrypted alert" message. If it does that, then this machine, at that point, believes that the connection is still up and running, and the server will be able to receive the alert message, and in particular decrypt it. Otherwise, what would be the point of sending that message ? Therefore, it is probable that the FIN message from the server has been sent after receiving this alert. Quite possibly, the client sends an alert which triggers the connection closure, and the server reacts by closing the transport medium (the FIN packet).

Note that in a normal handshake, the server will wait for reception of the Finished message from the client (the "encrypted handshake message" after the Change Cipher Spec) before sending its own Change Cipher Spec and Finished. We see that here, so the server was able to process the Finished message from the client, including decryption, MAC verification and message contents.

Assuming that both implementations conform to the standard, the "encrypted alert" message is not a close_notify warning. A close_notify is an alert message which warns the recipient of the intention of the sender to gracefully terminate the connection. The recipient must then reply with a close_notify of its own, marking its acceptance of that fact. Here, the client sends an alert message but no alert message is sent in response by the server, so we might surmise that we are not witnessing a graceful termination with a pair of close_notify. Most plausibly, the client's alert is a fatal alert, which tells to the server that something is amiss, and that the connection is doomed. The server can then only close the transport medium because there is nothing else that it can do at that point.

There is no indication as to what bothered the client enough to make it send an alert; however, there are rather decisive indications that all cryptographic operations went well.

You may want to run two network captures on both systems, so that you may get precise timings for all packets; it helps in reconstructing the actual sequence of events.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • %s/close_notify_/close_notify`/ Nice analysis. – JZeolla Jul 16 '13 at 15:19
  • @Thomas, thank you for the response. I have edited the question to clarify the Alert was 21, which I understand is a fatal error: Decryption failed – Yusuf Jul 17 '13 at 13:45
  • 1
    Actually I may be confusing Content Type 21, which is Alert, with Alert Code 21. Is this case, I think the former is the correct, and therefore I dont know what Alert code was sent. – Yusuf Jul 17 '13 at 13:56
  • The alert message is encrypted, so you cannot see its contents. The _message type_ (which is "handshake", "alert", "change_cipher_spec" or "application_data") is written in the record header, and that's what wireshark shows you; the contents (whether the alert is fatal or a warning, and the actual error code) are inaccessible to wireshark. – Thomas Pornin Jul 17 '13 at 14:05