On Tue, 2007-03-13 at 15:20 +0000, Hari Sekhon wrote:
does anyone understand how these products can inspect SSL?
The "trick" is actually pretty disappointing:
1) the monitoring device needs to know the private key of one of the
parties
AND
2) the cipher suite in use must NOT implement PFS (Perfect Forward
Secrecy), roughly: the property that someone gaining access to a
long-term key can't derive ephemeral keys and therefore can't decrypt
recorded messages.
The typical deployment scenario is an IDS (or similar) monitoring the
DMZ that a corporate web-server sits in. Getting consent to copy the
private key of the web-server to the IDS that's there to help secure it
is rarely controversial, configuring the web-server's SSL to only
negotiate non-PFS suites (basically using "RSA and random numbers" for
key exchange rather than Diffie-Hellman) only marginally so.
(For a for-profit corporation, preventing the future decoding of
messages by someone who has access to one party's private key (say, a
court-authorised investigator) is a non-starter, corporations are
required to keep correct records long enough for courts to look at them
anyway. Where PFS is relevant is intelligence agents working "in the
field"; sadly these guys probably can't derive benefit from an
SSL-decrypting IDS. :-))
Such a device will flag as a configuration error the presence of any key
exchange for which it knows neither private key, or which has PFS.
- Raz
------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to
http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
to learn more.
------------------------------------------------------------------------
