 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi Ken, Yoav, I agree with Ken that the policy needs not
be black and white, but for a different reason. Some people will treat deep
packet inspection by middleboxes as an optional service: you want it for most
traffic, but some traffic is too sensitive and you choose to prioritize
confidentiality over malware protection. This model is definitely susceptible to
attacks by infected endpoints that can control the IPsec stack, and e.g. attack
a server using encrypted traffic. You don’t really need a “colluding”
peer – most peers will probably accept either an ESP-null or an ESP-encrypted
proposal. But admins may be willing to take this risk. Thanks, Yaron From: ipsec-bounces at ietf.org
[mailto:ipsec-bounces at ietf.org] On Behalf Of Grewal,
Ken Quote … “Our use case is an edge device that inspects all traffic, and drops
things it doesn't understand, such as non-NULL ESP and possibly SSL (they might
make an exception for HTTPS, but do a MiTM attack against the SSL) ” I do not think a typical policy will be
black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns will
be mixed in reality (encrypted Vs. clear) and policy will dictate how a given
traffic stream in inspected and if it is opaque then take the associated action
(drop / bypass / apply QOS rules / send a different path in the network /
etc…). e.g. There may be a secure channel to transfer highly sensitive
data (e.g. payroll, company secrets, etc.) which should be encrypted and it may
be undesirable to categorize this under a general rule – this is a simple
extension of the firewall function. The ‘bait and switch’ attack
where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted
may also be possible unintentionally. E.g. Connection to a server (cluster /
farm) to gain access to a ‘normal’ service uses ESP-NULL and then
at a later stage, where the previous connection was torn down and a new one
built, the connection is obtaining some sensitive data and is now using
ESP-Encrypted. On the outside, the connection attributes look the same (same
server IP, same client IP (but may be different client due to NAT), same SPI
– SPIs can be reused for new connections to preserve fast lookups
algorithms at recipients), but underneath the connection is to access a
different resource (may be using a different port or service above the IP layer).
If the intermediate device has a cached rule (based on the previous connection)
indicating the traffic is clear, it will lead to falsely inferring the contents
of the payload and undesirable results. This goes to my point on cache eviction
policy for heuristics based intermediate devices, as highlighted in a separate
thread. Reuse of the same ‘tuple’ with different traffic
characteristics may be infrequent, but still plausible. I agree with Yoav that this attack may
also be possible intentionally between two colluding parties, where the policy
indicates all traffic is ESP-NULL. Thanks, - Ken From: Dragan Grebovich wrote:
I don't think the use case is to inspect
every packet like that. I also don't agree with what you wrote in #4. If
the appliance is willing to pass ESP-non-NULL, then it doesn't really care
about content inspection. That is fine, and probably the more common case, but
in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device that
inspects all traffic, and drops things it doesn't understand, such as non-NULL
ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM
attack against the SSL) So for each packet, the processing
is something like this:
Of course it's possible for the endpoints
to cheat, start of with ESP-NULL, and then after the heuristics marked it as
OK, begin encryption. This "attack" will work if all your policy says
is "ESP must be NULL". But that is not an interesting policy. Real
policies will require deeper inspection of the internal flows, so the cost of
the heuristics becomes negligible, as it only requires looking at the first few
packets of each ESP SA.
Email secured by Check Point |