Bug #2393
closed
One way TLS traffic not properly identified
Added by Austin Taylor almost 7 years ago.
Updated about 1 year ago.
Description
Suricata does not properly identify TLS traffic that only has one-way communication. Bro seems to properly identify the traffic and extract the TLS fields, but Suricata does not. I've tried using both netflow and flow, but both were unsuccessful in identifying the attached PCAP as TLS.
Files
Related issues
1 (1 open — 0 closed)
- File deleted (
ssl_not_parsing.pcap)
- File deleted (
Screen Shot 2017-12-21 at 4.14.51 AM.png)
- File deleted (
Screen Shot 2017-12-21 at 4.15.26 AM.png)
- File deleted (
Screen Shot 2017-12-21 at 4.15.50 AM.png)
- Assignee deleted (
Victor Julien)
- Priority changed from Urgent to Normal
Files deleted on Austins request.
- Assignee set to Austin Taylor
- Target version set to TBD
Do we have enough details for that issue?
Andreas, please see attached files. Please let me know if you need additional information.
- Related to Task #2278: tracking: failing better added
- Related to Task #2757: improve protocol detection added
- Status changed from New to Assigned
- Assignee changed from Austin Taylor to Mats Klepsland
With --set stream.async-oneside=true the flow record does show the app_proto as tls, but I get no tls records.
Mats can you take a look into that?
What kind of logs are you looking for ?
eve.json ? tls.log ?
For both of these, they require a certificate to log something.
And this is not the case in this pcap as it is client side only.
I confirm that with --set stream.async-oneside=true the TLS app layer is indeed recognized and parsed
Code is in log-tlslog.c (and similar test in output-json-tls.c) :
if (((hlog->flags & LOG_TLS_SESSION_RESUMPTION) == 0 ||
(ssl_state->flags & SSL_AL_FLAG_SESSION_RESUMED) == 0) &&
(ssl_state->server_connp.cert0_issuerdn == NULL ||
ssl_state->server_connp.cert0_subject == NULL) &&
((ssl_state->flags & SSL_AL_FLAG_LOG_WITHOUT_CERT) == 0)) {
return 0;
}
- Related to deleted (Task #2757: improve protocol detection)
- Status changed from Assigned to Closed
Looks like this is fixed with --set stream.async-oneside=true
Also available in: Atom
PDF