I am having an issue with the three way TCP handshake not working between my client and my server. I am not sure what the problem is but by the time I get to Client Hello, my server has already gone into a server 500 error. I am thinking that there is either a cipher problem or a protocol version problem. Should I use ssldump to do this and are there any instructions on how to set that up? I am running Linux on the server.
If you managed to get an HTTP 500 error, it means that the SSL session was already successfully established, meaning that there were no problems with the handshake.
Whatâs the actual error?
If you want, you can just record a packet capture file using tcpdump and then post it and I can take a look.
tcpdump -i eth0 -w ssl.pcap 'port 443'Also, I would recommend scaling up the verbosity of your webserver logging and check that first before you go âdeeperâ.
I donât see an added benefit of ssldump actually. It shouldnât be able to tell you more than what your webserver could tell you too.
If the problem does exist on another OSI layer level, instead of the application level, tools like tcpdump (or WireShark for a graphical interface 
), thanks @_az, should be more helpful.
Also other network analysing tools to check for MTU issues could be helpful.
Thanks. When I try run tcpdump on the server I get:
bitnami@ip-172-26-1-89:~$ tcpdump -i eth0 -w ssl.pcap âport 443â
tcpdump: eth0: You donât have permission to capture on that device
(socket: Operation not permitted). The client is win7 so tcpdump does work there.
I do have Wireshark running on the client.
Thanks Osiris. How do I increase the verbosity on the Linux server? I am really a windows guy.
OK. I caught the packets on the client with WinDump. Can I attach the dump? Now that I think about it, before the Extension speaks with the server, it first authenticates with google Oauth. Could that interaction (which works fine) leave the system in a bad state, and then when I try to go to my server, the server is already in an error 500?client_dump.pcap (6.4 KB)
It's service dependend, so it depends on the webserver software used. Use Google to find out how.
Also, I'm not sure if this is really SSL/TLS related. I can connect to your server with openssl, I can retrieve the contents of your site (a Bitnami placeholder) with curl, so the TLS part seems to work. I think it's more likely the error comes from the software running on the webserver.
Thanks. That has been my opinion too. What happens is that I can stop the app on the server before it sends any data back to the client. In that situation I can take a look at the chrome debugger and see that the server is already in an error 500. So I am thinking there is a response from the server, although it is not coming from the app. Can you think of a way to nail this down?
Iâm not sure if this forum is the right one for this troubleshooting. The problem doesnât seem to relate to the Letâs Encrypt certificate.
Ok thx. I guess I need to see the packet just after it leaves the server. I have been doing this with wireshark. it just seems that the server 500 error happens pretty early and it doesnt happen at all on my localhost server. I also had it running on a knownhost server under windows, and it also didnât get the error. It has something to do with linux, and not my application
I concur with Osiris, this looks application-level to me. The packet capture you posted is totally normal.
Looking at Wireshark probably isnât going to help you because all of the stuff you want to look at (the application layer traffic) is encrypted.
Itâs usually better to do this stuff at the browser level, or doing some âprintf debuggingâ within the application itself, such as printing the responses before theyâre sent onto the network.
Well, I use debuggers on both the browser side and on the client side. From the debugger on the browser side they look fine they look fine. Same is true of debugger on the server side (xdebug). I did find a bug in Apache that sounds just like this (http://svn.apache.org/viewvc?view=revision&revision=1621602) but it was presumably fixed in apache 2.4.26 and I am using 2.4.33.
I need to find a tool to use on the browser side where I can type in a buffer, and display (or log) what I get back from the server (unecrypted). Do you guys know of such a tool? I did a test with my localhost based server (which works) and then again (with Wireshark) with the remote server (where it doesnât work). I then printed them both to see what is different about the buffers. On the one that works I see:
Client Hello, Server Hello, change cipher spec, finished, magic settings, Headers, Data, settings, window_update, HEADERS, DATA
On the one that doesnât work I see:
Client Hello, Server Hello, Certificate [TCP segment of a reassembled PDU], Server Key Exchange, Server Hello Done, client Key Exchange, change cipher spec, finished, POST /sub/crud/Subit_backend/register HTTP/1.1 (application/json), a bunch of buffers, New session ticket, change cipher spec, finished,
Do these both seem normal to you? It is the same client and same serve code running in both cases.
Uhhh, you should not be able to see this in a packet capture. That would suggest the request was made without TLS.
If you need, you can set your browser's SSLKEYLOGFILE to save the TLS pre-master secret and then configure Wireshark with it, and it will be able to fully decrypt your session.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.