we had a similar problem - we solved it by using a F5 as reverse proxi and terminate the HTTPS/SSL session on the F5 and run un-encrypted from there - and pass the traffic through their ASM module which is similar to the IPS module - and in fact afterwards we also pass the traffic through a ASA and IPS module - but now un-encrypted...
Thank you tiwang but it's not a problem for me to not send HTTPS traffic through AIP-SSM. I am fine with not sending HTTPS traffic to AIP-SSM if there's no real use of it as it will be encrypted. So, as I had asked earlier, I just want to know:
- Does it mean there's no use of sending HTTPS traffic to AIP-SSM (unless the purpose is to monitor HTTPS headers and trailers)?
- What kind of protection can be expected by just looking at headers and trailers of HTTPS?
Is there any recommendation whether HTTPS traffic should be sent to AIP-SSM or not?
To evaluate what you get by inspecting the encrypted traffic, you can look at the signatures. These Signatures have "HTTPS" in the name. Of course there are even more signatures that work in general on TCP and so on:
But at least the "Malformed Handshake" Signature caused lots of false positives in my environment.
I don't really have any general recommendations for that. With limited time to work on the sensor I wouldn't care about HTTPS, but if you have some time to implement it, it won't hurt and will give you a little bit better protection.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...