1

We have connection problems to some 3rd party https endpoints. We checked the network packages via Wireshark to find the problem but we couldn't identify anything yet.

I compared one working and one not working endpoint to see the differences and see a strange type of protocol shown on Wireshark.

Wireshark shows ClientHello as SSL in the packet list. But if I check the SSL layer of the package I see it as Version: TLS 1.2 (0x0303)

Why Wireshark identify this packet as SSL?

Here is the captured packages .pcapng files:

We suspect that maybe this wrong protocol is causing the connection failed.

  • 1
    Because SSL and TLS are the just different versions of the same protocol? – user253751 Feb 3 '17 at 11:01
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 15 '17 at 19:17
2

Wireshark identifies the protocol based on several variables. In this case, it starts out assuming SSL, and then changes it as it goes through its dissection process.

I notice that the good capture contains a handshake session ID, while the bad one does not. I assume this is one of the reasons the bad capture stays at SSL.

In any case, it's clear these are two different client versions, and that's why you're getting resets. You can try allowing older SSL versions on the PA and see if that helps.

Here's a link to a similar question on the Wireshark wiki.

| improve this answer | |
  • Yes, the link looks like the same problem. I also want to asked that if there is a problem on handshake, why server doesn't send any SSL Alert message instead of directly closing connection via RST. Do you have any idea about this? – Yucel Feb 3 '17 at 13:51
1

This question was asked on Reddit not too long ago.

Here was my answer there:

SSL is the original protocol developed by Netscape 1994. This was SSL version 1.0 (major version 1 minor version 0). In 1995, Netscape came out with SSL version 2.0 (major version 2 minor version 0). In 1996, Netscape came out with SSL version 3.0 (major version 3 minor version 0).

In 1999, maintenance of the "SSL" protocol was handed over to the IETF, who renamed it "TLS". They started with TLS 1.0, which was major version 3 minor version 1.

And it continued.... TLS 1.1 is major version 3 minor version 2. TLS 1.2 is major version 3 minor version 3

As you can see, TLS (all the way through 1.2) is mostly minor revisions on SSL 3.0. What you are in fact looking at is a SSL3.0 structured header, advertising the client can support SSL up to major version 3, minor version 3, otherwise colloquially known as TLS1.2.

Hence, Wireshark decodes it as a SSLv3.0 header -- the header format has not changed since SSL3.0. Whereas SSL2.0 is an entirely new header, and if you could force a browser to initiate an SSL2.0 handshake, you would see Wireshark decode it as such. (google turned up this though)

I couldn't find a perfect reference that proves this, but you can make out the gist of it in Appendix E of the TLS1.2 RFC.

Newer versions of Wireshark will correct the protocol label to what was negotiated between the two clients after the Client Hello and Server Hello messages.

If you delete the Server Hello from the capture, you will see Wireshark will continue to label the whole conversation as "SSL 3.0" since it does not know what the agreed version of SSL/TLS was.

| improve this answer | |
0

For reference please see TLS/SSL handshake.

SSL/TLS handshake

Both of clients hello have same content TLSv1.2, the difference in the labeling comes from the fact that in the first instance the negotiation doesn't complete, therefore wireshark labels both packets differently. In pcap files you can see that after client trying to establish SSL connection server replaying with RST, ACK packet. Than again client trying to establish another connection hello is labeled TLSv1.2. But again server is sending RST. Both hello are TLSv1.2 there is only difference how wireshark is labelling them. I would assume that server is misconfigured. I would suggest checking cipher suits used on server.

Possibly the best way to troubleshoot this is by simply trying to connect to the server with openssl.

openssl s_client -connect example.com:443

You should see what cipher is selected in this transaction (if it works at all).

But this post is offtopic for this group.

| improve this answer | |
  • @datagramnetwork Questions about the use of networking tools is on topic. – Ron Trunk Feb 3 '17 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.