I am diagnosing our SSL/TLS implementation and would like to FULLY dissect FTP traffic. I have enabled SSL for FTP Port 21 and supplied the proper RSA Private Key key pair file. Wireshark is nicely deciphering the command connection and showing details. This is very helpful. Data on the other hand is being transferred on separate connections between randomly selected ports using resumed TLS sessions. Wireshark shows these as "FTP Data" but these remain encrypted and unreadable. Is there any way to have Wireshark process FTP Data as SSL/TLS connections and decrypt the data content? Specifically, I get an occasional (very rare) Decryption Error reported by the FTP client and would like to use Wireshark to identify whether the error is in the encryption on the server (SSL/TLS code that I have written) or with the client (FileZilla - GNU). But, it would just help to understand how to employ Wireshark properly. Can anyone help? asked 24 Jul '15, 09:34  bscloutier |
One Answer:
As you found out when you entered the RSA key details in Wireshark for the command channel, you need to specify the port. The data connections are taking place over randomly selected ports so you don't know in advance what port will be used. Therefore, once you find a conversation that you want to decrypt, you're going to have to make an entry for THAT session, based on the port that is used, and then you'll probably want to delete the entry when you're done, since it is only good for that one session. The bigger difficulty is that resumed sessions are being used. The FTP data is not encrypted using the RSA key. It is encrypted using a session key. The RSA key is used to encrypt the session key, which is then communicated between the client and server. So when you configure Wireshark with an RSA key, Wireshark uses the RSA key to decrypt the session key, and then uses the session key to decrypt the traffic. In a resumed session, the session key is not transmitted between the client and the server. They reuse the session key from the earlier session that is being resumed, so Wireshark will not be able to pull the session key out of the packet stream. IF you have the original SSL session in your trace, you should be able to pull the session key from that stream. I would filter on the session ID (ssl.handshake.session_id) of the resumed session to see if the original session is present. If it is, you can export the session key by going to File > Export SSL Session Keys. Once you've exported the session key, go to Edit > Preferences > SSL. Use the Browse button next to the input field labeled "(Pre)-Maste-Secret log filename" and browse to the session key file that you exported. At this point, the data stream should be decrypted. Obviously this is a manual, time-consuming process, and it's not one I've actually tried before. answered 24 Jul '15, 11:07  Jim Aragon Understood. The session keys appear to export. My capture contains the complete interaction between client and the device (server). There we 4 sessions and the Master-Key for each appears in the file. I then browsed to the file and selected it for the (Pre)-Master-Secret log filename. The FTP-Data session won't decrypt yet. I tried both Decode As... SSL and going to preferences to set the (random) port. The latter dialog though asks for a protocol I guess for the dissector. I put 'ftp' but no joy... yet. (24 Jul '15, 11:50) bscloutier Manually decoded the client_hello for the resumed FTP Data connection and confirmed that the referenced RSA Session-ID is in the exported session keys file. (24 Jul '15, 12:06) bscloutier GOT IT! Disabled the FTP Data protocol and the data connections then decrypt if I right-click for the connection and Decode As... SSL! So apparently the protocol overrides the requested decoding. (24 Jul '15, 12:22) bscloutier Congratulations. As I think about this more, I don't think the procedure of exporting the session key is necessary as long as the original session and the resumed session are in the same trace, only if they are in different trace files. (24 Jul '15, 12:28) Jim Aragon You are correct. I removed the exported file reference from the SSL dialog and ran a new session in a clean capture. The data connections decode but I do have to use Decode As... and select SSL for those that I need to see. The requirement though is that the FTP-DATA protocol be NOT ENABLED. Still it would be nice for the ftp dissector to somehow trigger the decoding for related connections. This will be helpful now as I expand the set of cipher suites my TLS is offering (with RC4 being dropped by some). I also can make the changes to support TLS v1.2 too. Thanks! (24 Jul '15, 12:58) bscloutier |
can you provide a sample capture file and the keys?
I can. What would you do with them?
Try to accomplish the decryption that you're asking for?
Kurt, thanks for the offer but I need to be able to do this routinely. It's not a one-time decoding exercise although I can see where you might have figured out the correct procedure for me. It is much more educational to struggle through it and hammer out the solution with a little assistance.
It would seem to me though that the SSL 'ftp' disector could figure out that it needs to pass the master-key to the ftp-data dissector. This could occur somehow on its own.