Bug #7406
closedeve: Alerts with app_proto=tls no longer logs the tls app data
Description
Prior to change of fixes to ticket #6846, the application data is reported in almost every alerts, now the application data is barely included in the alert events.
Upon reviewing the recent updates, I've identified two significant changes that compromise the consistency and accuracy of application data reporting:
1. Inconsistent reporting for multiple alerts that belong to a single packet.
With PACKET_ALERT_FLAG_TX, a UDP DNS packet will no longer include the DNS section in the connection alert, while the DNS alert will. Although this change may seem logical, it constitutes a breaking change in a minor version update.
2. Missing reporting of application data in TLS Alerts
The application data for TLS (and potentially other protocols) is no longer reported in the TLS alert. As one can see from the below code, the sslsession is the alstate set to the flow, but it would never translates to PACKET_ALERT_FLAG_TX.
uint64_t txid = PACKET_ALERT_NOTX;
if ((alert_flags & PACKET_ALERT_FLAG_STREAM_MATCH) ||
(s->alproto != ALPROTO_UNKNOWN && pflow->proto == IPPROTO_UDP)) {
// if there is a stream match (TCP), or
// a UDP specific app-layer signature,
// try to use the last tx
if (pflow->alstate) {
txid = AppLayerParserGetTxCnt(pflow, pflow->alstate) - 1;
alert_flags |= PACKET_ALERT_FLAG_TX;
}
}