 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
By a ‘colluding peer’, I meant that both
sides need to negotiate the same policy (e.g. this is sensitive data, so only
allow encrypted traffic or vice versa). I think this boils down to how tight the
admin policy is and also whether it is desirable to allow encrypted/clear
policies for different services to the same server/cluster, which could result
in the unintentionally attack I described below. Thanks, - Ken From: Yaron Sheffer
[mailto:yaronf at checkpoint.com] 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: 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.
|