[Snort-devel] [ekr at ...168...: Re: format string in ssl dump]

Martin Roesch roesch at ...48...
Wed Dec 20 00:02:11 EST 2000


Oops, forgot to respond to all...

Eric Rescorla wrote:
> 
> Todd Lewis:
> > On Tue, 19 Dec 2000, Martin Roesch wrote:
> > > Basically what I'm imagining that we'd
> > > like to do is to treat it as a decoder plugin to Snort which would fill in
> > > various data structs that would then be passed to the detection elements of
> > > the system.
> > >
> > > Sounds reasonable?  I'm not sure if this is what Fyodor is thinking, but it
> > > sounds pretty reasonable to me. :)
> >
> > I want to make sure that I understand first.  What would the API for
> > this look like?  Where would this plug in?
> This is pretty much the answer I'm looking for as well.
> 
> I sort of envision there being two interfaces to ssldump, an "in" and
> an "out". One passes SSL data into the in interface and the
> decoded and decrypted traffic appears on the out interface.
> 
> IN
> ssldump is relatively modular so one could either wire it up directly
> to the network and let it handle TCP reassemble or pass it reassembled
> TCP data as it becomes available.
> 
> OUT
> Currently I don't have anything implemented here. ssldump just handles
> the traffic internally, but having a modular out interface is on
> my TODO list for other reasons. The primary problem has to do with
> output of the parsed SSL traffic. The plaintext itself is no
> problem because it's basically unstructured. However, the SSL
> handshake contains quite a bit of strutured data and I need to cook up
> output interface for this data.

In the existing system (Snort 1.X) we'd make this into a preprocessor like the
http_decode plugin.  So what you'd get in is a decoded packet stream and what
we'd expect out is the same packet with the encrypted payload "normalized"
back into plaintext.

The HTTP decode preprocessor plugin works in a similar fashion.  When it sees
web traffic come in, it automatically examines this traffic looking for
encoded URIs, then converts them to their ASCII equivalent in place in the
packet data.  

Would this be a possibility or would it require too much entabglement with
Snort plugin code?

    -Marty

> As you can see, there's a lot of leeway here so I need to have some idea
> of what snort is going to expect.
> 
> -Ekr

-- 
Martin Roesch
roesch at ...48...
http://www.snort.org




More information about the Snort-devel mailing list