2018-04-24 02:15 PM
One of the big reasons for our recent upgrade to RSA Netwitness 11.1 is the "sslKeys" capability described in the article Decoder: Decrypt Incoming Packets was a desire to have better visibility into email messages traversing our Netwitness Decoders.
I have followed the document, and see the keys installed using the listPems argument, however I do not see any decrypted information when reviewing the sessions on my NW server voa the Investigate tab.
I have manually performed decryption using a packet capture obtained from Netwitness, the key I installed, and Wireshark, and verified that the key works as expected to decrypt the TLS session key and then decrypt the packets. I have even verified that the TLS cipher being settled on between the endpoints is in the FIPS-compatible listing, and is compatible with private-key based decryption (though I also verified that doing manual decryption).
However, it doesn't appear that the packets are being decrypted as expected.
So I thought I'd ask, since the documentation doesn't explicitly state so; does Netwitness 11.1 support opportunistic SSL/TLS decryption? Specifically, as described for the SMTP protocol in RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security?
2018-05-02 02:19 PM
Hi,
If you could provide a sample pcap of this traffic, with the necessary private key, I will take a look at why it's not decrypting. I do not have any sample traffic of this type to give you a complete answer to your question.
2018-05-02 02:35 PM
You can find sample captures here, just look for the "SMTP" ones.
2018-05-02 04:22 PM
The bad news is - no, it will not decrypt in 11.1.
The good news is I was able to decrypt it easy enough with some code changes. I will put this work in our backlog for a future release (hopefully 11.2, but cannot promise anything).
Thanks,
Scott
2018-05-03 10:24 AM
Hello Scott, thank you for checking into this. I'm glad to hear that this might make it into 11.2. Honestly, other than creating metadata for HTTP transactions occurring over HTTPS, it's not entirely clear what sslKeys is meant to do. You can't use the decrypted session to drive further analysis, such as session reconstruction via the GUI, unencrypted packet extraction, file carving, delivery to Malware Analysis...I look forward to it becoming more-useful in the future.
2018-05-03 10:47 AM
So, part of what you say is true, however, file extraction does work. And therefore delivery to Malware Analysis will first decrypt the session, then extract the files before sending them to the client. It does this as long as the tls.premaster meta is present in any session (which is the premaster key used to originally decrypt the session).
Also, NwConsole has a "content" command that will indeed extract the decrypted payload and reconstruct both sides of the session to your local filesystem.
[localhost:50004] /sdk> content session=1 --output-format=text outputDir=/tmp/content renderType=109
cat /tmp/content/1-109-0.merged-decrypted.dat
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> client
EHLO lekensteyn
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< server
250-ubuntu Hello localhost [127.0.0.1]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250 HELP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> client
MAIL FROM: <peter@lekensteyn.nl>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< server
250 OK
421 ubuntu lost input connection
The above is the output from one of the sample encrypted SMTP pcaps on the wireshark site. So, yes, I'm not claiming this is ideal by any stretch (the UI needs to catch up), but the capability is there. Hopefully we will have a more end to end solution in an upcoming release.
2018-09-05 02:40 PM
This capability now exists in version 11.2.
To enable it, you need to tell the HTTPS parser which smtp ports to use when searching for the STARTTLS command.
To do this, navigate to /decoder/parsers/config/parsers.options and add something like this
HTTPS="smtpsPorts=465,995"
just make sure to csv list the ports in use by your POP3/SMTP server and make sure to upload your decryption key using /decoder sslKeys
If you have any questions, just reply to this.
Thanks,
Scott