I have a website (from a client) that is hitting a WCF Service on my Win 2008 R2 Standard server. The WCF Service is hosted on IIS 7.5. The connection is HTTPS encrypted. I do not have access to the client's server.
In order to debug an issue, I need to examine the request the client is sending. I am using WireShark 1.10.3. for this. I am able to get the decrypted information provided I have WireShark running first and the 2 servers connect using a Full Handshake. WireShark cannot decrypt if the servers are using an Abbreivated Handshake.
Abbreviated Handshake is employing a technique called SSL Session Reuse, where the two servers store the encryption/decryption information in a cache. This eliminates steps needed in a Full Handshake and saves CPU on future requests. I read that the default TTL for this cache is 10 hours, however I have not found where to set that. TLS by specification does a Full handshake when there is no information in either servers cache. After the Full Handshake, it automatically caches the info so it can then do the Abbreviated Handshake.
Since I am debugging, I have to run many scenarios many times.
I have found that the only way for me to ensure that the two servers do a Full Handshake is to reboot my server. This clears the cache and session information and the servers are forced to do a Full Handshake.
Obviously, rebooting my server everytime I come back to testing this issue is not ideal. I did some research and found some articles that suggest I can disable the SSL Session Reuse by setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ClientCacheTime\Value to 0.
http://blogs.msdn.com/b/huizhu/archive/2009/12/17/ssl-_2f00_tls-full-handshake-vs.-abbreviated-handshake.aspx http://support.microsoft.com/kb/247658
The articles suggest that this will disable the caching of the encryption information. However this has not worked for me. Am I missing something?
Is there another way to disable SSL Session Reuse or a way to bust the cache without having to reboot?
Here are some ideas:
1) Have the client clear their session cache, if this is possible and easier than rebooting their server.
2) Send the requests through an HTTPS proxy (e.g., burpsuite). This would most likely require configuring the client to use your proxy. Restarting or clearing the proxy cache would lead to a full TLS handshake.
3) Use a TLS reverse proxy to receive incoming requests on the server IP and port and forward them to the server. No proxy configuration is required at the client. Just restart the proxy to start the full handshake. If the server requires HTTPS, use upstream SSL on the proxy. If the server can use HTTP, you can send traffic in the clear between proxy and server and use Wireshark to directly view the traffic. This might be helpful: https://serverfault.com/questions/583374/configure-nginx-as-reverse-proxy-with-upstream-ssl
4) Flip a bit or drop a packet on an existing TLS connection between client and server. This will cause a fatal alert (integrity check fails, indicating a possible MITM attack), which will invalidate that session and require the next request to initiate a full handshake.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With