2017-06-28 03:13 PM
I'm trying to track down outdated cryptographic protocols and weak cipher suites still being used. I want to put this into a report that list the source and destination ip addresses, the protocol being used, and the cipher suites being used. The problem I'm running into is that both the protocol and the cipher suite get put into the same meta key (crypto). I need one or the other (I think) to go into a different key so I can have them both in the same row of the report. Am I overthinking this or missing something really simple here? Any help would be greatly appreciated!
2017-06-29 01:52 PM
I also want to understand this. I disabled erroneous packet parsers and still see this duplicate behavior. I want the protocol and cipher suite separate, for us it is critical for understanding whether we have encrypted streams using ECDHE that an out of band decryption solution cannot inspect.
2017-06-29 02:35 PM
Like most keys, crypto is overloaded with concepts from different contexts.
While it isn't feasible to create a new key just for SSL/TLS version, it would be possible to move that to the key 'version'. Then a query would be something along the lines of select crypto where service=443 && version="TLS 1.2". Would that help? If so, open a ticket with Support and I'll see about changing TLS_lua.
TLS_lua is one of the example parsers included in the Parsers book if you'd like to take a look at it:
https://community.rsa.com/docs/DOC-41370
It is possible to see both e.g. SSL 3.0 and TLS 1.2 in the same session. TLS_lua identifies protocol version from both the record layer and the server handshake.
2017-07-12 08:31 AM
William,
I think your suggestion of moving SSL/TLS version into the "version" meta key would be tremendously helpful. Thank you for the reply! Are there many changes that would need to be made to the TLS_lua parser? I'm looking at it now and its obviously much different than the log parsers I'm familiar with.
Regards,
James