When your trace is running the next step is on client side. This will result in a hard to read trace.
You do not have to disable PFS (Perfect Forward Secrecy)Īfter preparing your vServers you can start your trace.If you use for instance a Content Switching vServer to publish a website, protected with an AAA vServer you need to prepare both your Content Switch and your AAA vServer.
It will be much harder to investigate traffic if multiple clients use the same public IP. Before you enable trace logging prepare your SSL vServers. Keep in mind that it would really help if just one person is using that IP address at that moment. I recommend filtering your trace on your clients public IP address. When running a trace on NetScaler lots and lots of IP traffic is captured. If you have any additions please let me know, and I will be happy to add them to this post. I will not pretend this document covers all, but I had some good successes decrypting traces with the following procedure. I struggled with this topic quite a bit, and documentation (eg. My question is, is there any way for me to tell Wireshark that these messages also originate on the same handshake? I'm not sure I can fix the change of port, since that happens on code I don't have ownership upon.Every now and then it’s necessary to actually look into a SSL stream between client and NetScaler to inspect what’s actually happening. My guess is that, since master secret is computed using the pre master secret and the client and server randoms, Wireshark stops being able to decrypt these messages, as it can no longer tracks them back to the original handshake.
Wireshark then thinks of these messages as belonging to a UDP stream that begins with the stun message that caused this port change, as opposed to with the handshake. Upon further inspection, found out this could have to do with the way Wireshark follows the streams.Īt some point in the communication, there is a change which cause some of the messages to start using a different dst port for UDP. My problem is the following: Not all packets are getting decrypted. I'm using the SSLKEYLOGFILE env variable method for decryption (so the pre-master secret gets dumped and then feeding this file to wireshark). Im currently trying to dissect a WebRTC packets, encrypted with DTLS.
0 kommentar(er)
