CAPEv2
CAPEv2 copied to clipboard
kevoreilly
Replace httpreplay with something faster
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
- A golang-based tool leveraging https://github.com/google/gopacket
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
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.
