Ask Your Question

Wireshark showing some TLS traffic as TCP and some as TLSv1.2

asked 2020-01-29 22:55:46 +0000

awalker gravatar image


I am running a CURL request against an F5 VIP, which gets an XML response from a backend server:

i.e. curl -X POST -d @read_req-2 https://x.x.x.x:8443/axis/services/Me... --insecure -H "SOAPACTION: yes" -vvv

The curl request gets a valid response and if I take a tcpdump of the traffic I can see TLSv1.2 packets and can decrypt the TLS1.2 exchange fine with the private key from the F5.

However, if I change the VIP to listen on port 8444 (or 8445 etc) and run the following CURL request:

curl -X POST -d @read_req-2 https://x.x.x.x:8444/axis/services/Me... --insecure -H "SOAPACTION: yes" -vvv

The the curl request gets a valid response again (it all works) but the tcpdump I am taking just shows TCP packets (no TLS, Client Hello etc) and I am unable to decrypt any packets.

I have added the port 8444 to the Wireshark HTTP protocol along with 443 (8443 is not there?) but this does not help.

SSLDUMP on the cli of the F5 is also able to decrypt traffic fine with the private key, for all ports (including 8444 and 8445).

TCP dissectors in Wireshark are all set to re-assemble packets etc -what am I missing to be able to see/decrypt this traffic in Wireshark?

I am running Wireshark Version 3.2.1 (v3.2.1-0-gbf38a67724d0).

Many thanks.

edit retag flag offensive close merge delete


I have added the port 8444 to the Wireshark HTTP protocol along with 443 (8443 is not there?) but this does not help.

So you added 8444 to the "SSL/TLS Ports range" preference for HTTP, but it still didn't recognize port 8444 traffic as HTTP-over-TLS?

Guy Harris gravatar imageGuy Harris ( 2020-01-30 01:40:40 +0000 )edit If the capture has the full TCP handshake then heuristics should see the TLS handshake in packet 4 (Client Hello). Isn't that how 8443 was decoded without being in the config?

Chuckc gravatar imageChuckc ( 2020-01-30 01:59:14 +0000 )edit

Yes - 8444 has been added to the SL/TLS port range for HTP - no change, all packets still TCP..

Yes - agree that heuristics should see packet 4 as a Client Hello (when we use 8443 or 443 it does) - but when we use 8444 (or 8445) Wireshark see all packets as TCP (with the same length/sizes etc as seen with port 8443..)

awalker gravatar imageawalker ( 2020-01-30 09:10:40 +0000 )edit

Ok - I disabled al the protocols and then enabled them one at a time ...just the ones I need:

Ethernet - IP - TCP - TLS -HTTP

Now works a treat - can see and decrypt all traffic!! Hooray!!

Looks like one/some of the previously enabled protocols is clashing and confusing Wireshark - any ideas which.. or why? I will do some more digging around - add some more protocols until it fails again....

awalker gravatar imageawalker ( 2020-01-30 09:19:28 +0000 )edit

Can you post a capture of the TCP handshake and the Client Hello conversation on port 8444?

Chuckc gravatar imageChuckc ( 2020-01-30 13:48:22 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-01-30 14:20:35 +0000

awalker gravatar image

Looks like disabling and re-enabling all the protocols seems to have done the trick - with all protocols re-enabled I can still see all the traffic and decrypt it. No idea what happened but seems to be resolved.

Many thanks

edit flag offensive delete link more


Per the last comment above "disabling and re-enabling all the protocols seems to have done the trick" its now working.
FYI that a global re-enabling of all protocols can lead to things like this where dissectors that are off by default can affect the packet decode:

Chuckc gravatar imageChuckc ( 2020-01-30 15:57:45 +0000 )edit

Many thanks.

awalker gravatar imageawalker ( 2020-01-31 10:37:21 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-01-29 22:55:46 +0000

Seen: 8,538 times

Last updated: Jan 30 '20