5

TLS server is doing something I don't understand.

  1. TCP handshake executes normally.
  2. SSL Client Hello executes normally.
  3. SSL Server Hello seems normal. Provides certificate, says Server Hello Done.
  4. Dissection shows client issues "Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
  5. Dissection shows server issues "Change Cipher Spec" then "Encrypted Handshake Message"

Client now ACKs, starts to send data. But server ACKs then sends an "Encrypted Alert" and FIN's out.

This has happened just after swapping out certs. The cert presented in the SSL handshake is the new key.

Clue, anyone?

Woody Weaver
  • 101
  • 1
  • 2
  • 8
  • 1
    It sounds like there might have been a protocol violation somewhere, or there is a problem with the new certificate... dig a bit using openssl perhaps? Especially, try using openssl s_client? – Falcon Momot Sep 30 '15 at 03:14

3 Answers3

3

Its probably due to an SNI issue with either the client or some device in the middle, like a load balancer. The load balancing device must be able to present the server name to the backend host as part of the initial Client Hello. see https://en.m.wikipedia.org/wiki/Server_Name_Indication

Jim B
  • 24,081
  • 4
  • 36
  • 60
1

The most important packet is the "Encrypted Alert" as it contains the reason why the connection is closed.

It seems to be a validation error. This means that the certificate is not trusted, or invalid. But the real reason is send via the TLS Alert protocol

Mircea Vutcovici
  • 17,619
  • 4
  • 56
  • 83
  • 1
    Its not a validation error on the cert side or you wouldn't get "change cipher spec" and handshake, which leaves only SNI - very good point about TLS alert- which would of course provide the definitive answer. – Jim B Sep 30 '15 at 22:40
  • TLS alert shows in hex 15 03 01 00 12 e1 54 de 28 35 56 9d d6 d1 1e 25 e7 6e 00 dc bd a7 e5. I think this means 0x15 == alert, 03 01 == TLS 1.0, 0x0012 == length of 18, and then we should see level and description, but I can't understand what it is telling me. – Woody Weaver Dec 10 '15 at 20:54
  • Use Wireshark. It has a protocol dissector for TLS. If it doesn't recognize the stream as SSL/TLS, you can change this with: "Decode As..." from the context menu of a SSL/TLS packet. – Mircea Vutcovici Dec 10 '15 at 21:27
0

I've run into a similar issue with pure-ftpd in explicit TLS mode (FTPS server).

In my case though, there was no Encrypted Alert sent from server; it just Fin'd immediately after key exchange (Change Cipher Spec, Finished message from server → FIN from server). Next, the client sent the Encrypted alert, level 1 code 0 Close Notify (which is expected — unlike the server FIN).

This happened only with one single specific client (a device firmware), and didn't reproduce with other ftps clients.

I haven't dig up the root of the issue, but I suspect we hit a server bug. pure-ftpd uses apache-like fork-per-connection model; and I observed the child process crashing in gdb (exiting with code -1) — which of course leads to the OS closing the socket FD and sending FIN.

One more reason to say its a server bug in my case — the behavior stopped reproducing as soon as we swapped out the ftps server for a different implementation, proftpd.

I don't think this matches the OP case — there, server ends the connection in TLS-appropriate way, with Encrypted Alert — but nevertheless, something to consider for anyone hitting this page.

ulidtko
  • 438
  • 4
  • 13