-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace httpreplay with something faster #2314
Comments
How about using a TLS inspection proxy instead of dumping TLS secrets that have to be post-processed with httpreplay? Some TLS proxies can generate PCAP files with decrypted TLS traffic on the fly. |
yes in past i was using mitmproxy for that, but i don't remembe why i dropped it |
Maybe mitmproxy didn't provide much value over the current implementation? The TLS traffic and sslkeylogfile.txt from mitmproxy probably still had to be post-processed (decrypted) in order for Suricata to inspect it, right? |
as far as i remember, i might be wrong rigth now, mitmdump was dumping decrypted already pcap https://docs.mitmproxy.org/stable/#mitmdump |
The one disadvantage with using an inline proxy is some malware could detect on the naming/properties used by the CA. |
Replace httpreplay with something faster
Summary
Httpreplay is used inside of CAPE to decrypt TLS traffic so that it can be processed by Suricata. Due to its pure-python implementation, it is extremely slow.
Context
On my local instance, CAPE took ~960 seconds to process a ~250MB PCAP with httpreplay. When the same PCAP with httpreplay disabled, it only took 16 seconds.
Replacement considerations
The text was updated successfully, but these errors were encountered: