decrypted ssl traffic parsing

[MichaelPochan]

We began ingesting decrypted https traffic into our Netwitness packet decoders (10.6.2). The request and response headers and showing up fine and the service is being tagged as 80. However, none of the headers are being parsed by the http_lua parser which parses normal http traffic just fine. The decrypted header formats are the same, but every meta key that the http_lua parser is tied to has an empty value for these sessions. Has anyone else encountered this? We'd like to avoid having to write our own parsers for each individual header field, but if it comes to that it can be done. Just was curious why traffic over 443 that is being identified as 'service = 80' would cause issues with the http_lua parser, especially since it already parses http traffic for us over other nonstandard ports. We are also not seeing any parsing failure errors. 

[EricPartington]

is the traffic coming to your decoder on tcp port 80 or 443 ?

do you have a ssl truncate rule in place if so what is it currently ?

what service (not tcp port) is the traffic being detected as ? http (80) or https (443) ? - I think you answered this one but confirm

if you have a pcap please open a case so that we can take a look at the raw data and see if there is anything that needs to be done.

[MichaelPochan]

We removed our truncate rule and the service is being detected as 80 on tcp port 443. Under Events using the Text view, all the headers are visible but the values aren't being populated into the meta keys. I'll grab a pcap and see if support has any ideas. Thank you for the feedback!