Someone mentioned that escrowing the keys so that NIDS systems could decode
the traffic was unsafe and I agree, but leaving your intrusion detection
down to log analysis does, as you so rightly point out, miss lower-level
protocol based attacks. How about a compromise then? A host-based IDS
system that has traditional log analysis but also some local network IDS
functionality, capturing and analysing network traffic non-promiscuously.
Given access to the key material (as it's coresident with the server), could
a system like this decode the SSL traffic in parallel with (or prior to) the
HTTP server and do NIDS type analysis?
Shaun.
> -----Original Message-----
> From: J Edgar Hoover [mailto:zorch_at_RIGHTEOUS.NET]
> Sent: 01 September 2000 19:45
> To: VULN-DEV_at_SECURITYFOCUS.COM
> Subject: Re: SSL & IDS
>
>
> > Even SSL servers write log files ;) Set up a log file watcher that
> > looks for the same patterns as your NIDS.
>
> Not good enough, for much the same reason as sniffing behind a reverse
> proxy.
>
> Neither option protects you from exploitation of the SSL server
> itself. Yeah, you might be able trap malformed URL's, but how
> about SSL
> negotiation exploits? Or, exploits in the logging mechanism?
>
> Remember the SSH remote root bug(s)?
>
> You could look at the packets as a whole though... watch for
> things like
> unusual volume of traffic from one ip or block. Most servers using SSL
> don't have nearly as much data coming from the client as the
> server. Look
> at packet sizes, how often does a client send more than 1k of
> data back to
> the server?
>
> Another angle might be that since you have access to the
> host's keys as
> well as plain text, some crypto-cruncher could work out an
> algorithm to
> detect 'abnormal' traffic.
>
Received on Sep 04 2000
Intro
