now SSL and ids ( was Re: ssh and ids )

[Jason <security () brvenik com>]

Hi Peter,

Thanks for taking the time to elaborate on this a little, I had 
previously asked some questions about the technology in general and 
hopefully you can respond. I have also read the white paper and have 
some questions.

My initial questions are quoted below and my questions to the white 
paper and comments on your statements are inline. Thank you in advance 
for taking the time to read and discuss...

--- begin quote ---
> This is an interesting area I think deserves more conversation. I
> want to toss out a few questions and hopefully someone will have
> first hand experience and can elaborate.
>
> Simply doing the escrow of the private key allows the capture of the
> symetric key but...
>
> How many simultaneous SSL sessions can be tracked?
>
> What are the DoS potentials to detection by forcing a constant rekey?
>
> How is spoofing handled? If you walk the possible session id space
> and attempt a connection you force every existing session to rekey
> and tracking of each possible session for a period of time, this is
> expensive to track.
>
> When passive what happens if a rekey is missed?
>
> When inline what performance impact can be imposed on the network
> with a $300 SSL acelerator card and a perl script?
>
> What ciphers are supported?
>
> How are new ciphers handled?
>
> What if an unsupported cipher is used?
>
> Does it validate the trust chains? Anything in the SSL session?
> Time...
>
> How does it handle client certs? It cannot possibly know the private
> key for client certs too. IIRC, some servers allow client/server key
> negotiation without requiring authentication.
>
> I understand that the intent is to detect attacks over known SSL
> channels but these are issues I would like to explore deeper. I do
> not think it is possible to properly handle the SSL case without
> terminating and watching behind the termination point and even then
> it does not gracefully handle the client cert issue gracefully when
> authentication is involved.
--- end quote---

In the white paper it is mentioned that the original packet is released 
unmolested once normalization has determined it to be harmless, does 
this imply that should the inspection device normalize differently than 
the target an attack will still pass successfully? I thought that the 
intrushield device attempted to prevent this by performing normalization 
of the traffic and passing the normalized requests on.

For the normalization phase what are the parameters used to determine 
when enough data has passed and it is safe to allow the unmolested 
packets through? I am assuming that you have to queue the entire request 
to completion and then inspect. If this is the case how are pipelined 
requests that can be arbitrarily long handled? What if during the 
pipelined request a rekey is initiated?


Peter_Schawacker () NAI com wrote:

> Hi Marty, 
>
> Since you were kind enough to mention us :-) I thought I would offer two
> comments about what you wrote regarding SSL "key escrow" (is it really
> "key escrow" when the key isn't handed to a third party?) and IDS/IPS.

It is key escrow when there is an opportunity for key recovery. A third 
party need not be involved even though one typically is. The device also 
qualifies as a third party having access to the private key.

> First, remember that storing your web server's private key on an
> external system is something that's done routinely with SSL
> accelerators.  Hardware SSL accelerators are commonplace these days.

This is an area where there is no real standard and the accelerators can 
be simple cards inserted into the host server and accessed with a driver 
or completely separate devices that then act as reverse proxies and 
communicate with the server in the clear. In the case of security and 
defense in depth you prevent a private key compromise in the event of 
server compromise by using a separate device. You can attempt to prevent 
this by using on board hardware accelerators however unless they are 
devices that actually perform the crypto in hardware and only pass the 
encrypted data back a key compromise is assured. It is more prudent to 
offload this to a separate device thus providing no opportunity for 
compromise.

> Second, we fully understand that folks are often squeamish about sharing
> keys, so great care was taken to protect the private keys on the
> IntruShield appliance.  We believe we have found the best possible
> strategy for mitigating private key theft risk while eliminating the
> SSL/NIDS "blind spot".  Through the use of public key cryptography, we
> persist the key in such a way that one would need information that is
> resident only in the sensor, along with information that is resident
> only in the IntruShield Manager in order to recover the key. Having just
> one or the other will not suffice.  I won't bore the list with the
> details, but our implementation is described here: 
>
>         
> http://www.nai.com/us/_tier2/products/_media/sniffer/wp_encr_th_prot.pdf

I like the approach in that it appears that the manager always pushes
the key to the sensor and the sensor never stores the key in non
volatile storage. Splitting the stored server key from the private key
capable of decrypting it is prudent. A compromise between stability and
security but a good one from the information in the paper.

> Should an attacker root your web server, how safe will your private keys
> be?  If your IDS/IPS can't handle TCP/443 to your production web
> servers, you have a blind spot where attackers can operate unseen and
> unhindered.  Which is worse, copying your web servers' private keys to
> your IPS to prevent a web server compromise, or being blind to attacks
> against those same servers?  Frankly, I can't think of a single IDS/IPS
> product that is less secure than a typical web server.  Security is all
> about trade-offs.  This is not a difficult one.

I disagree here completely. If you properly deploy a hardware 
accelerator that is a separate device then both goals are met without 
duplicating keys or introducing additional risk. The inspection device 
can do what it wants with the data in the clear and the server can even 
be rooted by a person inside and they cannot impersonate the server. It 
is a difficult decision when you look at the complete problem, the 
approach of decrypting the traffic destined to the endpoint flies in the 
face of defense in depth and sound crypto principals. Protecting the key 
regardless of stability of the server is paramount. I doubt any 
E-Commerce site would like to have a keypair floating around that can 
impersonate them with all the associated assurances that SSL and a 
trusted third party attempt to add. There are still deployment cases 
where this is less than optimal but those generally revolve around 
authorization and not authentication which can be handled well as a 
separate credential pass over secure channels.

> You also alluded to the problem of covert channels.  I believe that the
> best protection against covert channels is to stop the attacker before
> the back door is installed.  Failing that, a host based IPS/firewall is
> the last, strongest line of defense.  

I agree that the best defense is a good offense. Patching, defense in 
depth, due diligence, policy, and auditing all play a role in this. The 
unfortunate case is that often times the attacker is on the inside where 
you cannot get between them and the target easily. The covert channel 
will still exist and unless you have sound security policy and are 
diligent in monitoring you will lose the game.

Thank you again for taking the time to discuss.
Jason.

> Peter Schawacker, CISSP 
> IPS Technical Evangelist 
> McAfee 
> Office 760 200 4258 
> Mobile 760 880 4258 
> ps () nai com
>
> -----Original Message-----
> From: Martin Roesch [mailto:roesch () sourcefire com] 
> Sent: Friday, June 18, 2004 5:54 PM
> To: Runion Mark A FGA DOIM WEBMASTER(ctr)
> Cc: focus-ids () securityfocus com
> Subject: Re: ssh and ids
>
>
> Hey Mark,
>
> VENDOR ALERT: I'm a vendor and I'm going to talk about my technology.   
> Please take my comments with an appropriate amount of sodium chloride.
>
> Sourcefire's RNA product is capable of isolating/identifying layer-7  
> protocols (including encrypted protocols) and tracking the flows.  For  
> example, if you wanted to find SSH/SSL traffic that it being initiated  
> from outside your network to inside, setting up a query (or automated  
> reporting) is pretty trivial.  Hacker busts into your network and sets  
> up an SSH server, RNA picks it up and can let you know that it detected
>
> a new service and logs the flow data, etc.  Anyway, if you're  
> interested in seeing a demo or talking more, let me know.
>
> As far as IDS being able to do much with encrypted traffic, there's  
> generally not much to do once the session goes encrypted.  You can  
> setup rules in a system like Snort to differentiate between "allowed"  
> and "everyone else" hosts talking to machines on your network pretty  
> easily (and you can query RNA's flow data for the info too).
>
> I know the NAI guys just released a mod to their sensors that allow  
> them to do real-time SSL decryption if you're willing to escrow the  
> private crypto keys on the box (shudder).  There's been talk of  
> implementing the same sort of thing in Snort (ala ssldump) for a while,
>
> but it's never come together...
>
>        -Marty
>
>
> On Jun 18, 2004, at 2:18 PM, Runion Mark A FGA DOIM WEBMASTER(ctr)  
> wrote:
>
>
> > Lets suppose the attacker is mildly sophisticated, and after making
>
> the
>
> > initial assault roots the box and installs a secure backdoor or two.
>
>
> > Is
> > there any IDS capable of isolating data it cannot read, except to
> > monitor
> > authorized port usage of a system or group of systems?  Not to  
> > complicate
> > the question, but when the attacker is using portal gates and all
> > communications traffic is encrypted in normal channels how can an IDS
> > participate?  Monitoring normal traffic patterns seems a bit slow for
> > detection.
> >
> > -
> > Mark Runion
> >
> >
> > ----------------------------------------------------------------------
> > -
> > ----
> >
> > ----------------------------------------------------------------------
> > -
> > ----


---------------------------------------------------------------------------

---------------------------------------------------------------------------