[Snort-devel] [ekr at ...168...: Re: format string in ssl dump]
roesch at ...48...
Wed Dec 20 00:23:35 EST 2000
Eric Rescorla wrote:
> > 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?
> I don't know how the snort plugin code works yet.
It's *very* straight forward. Basically, you register the plugin name and
it's initialization function. Once that is registered, if the rules file
parser sees the name it calls the initialization function, which parses any
arguments to the plugin that are passed in the config file and then hooks your
preprocessing funtion into the chain of preprocessors.
When the preprocessor function is called, it is handed a pointer to the
decoded packet which includes the decoded data link, network, and transport
layers, plus a pointer to the raw application layer data. It is free to do
anything it wishes with this data, including performing its own data
manipulation and calling the alert and logging facilities if it finds
There is sample preprocessor code in the templates/spp*.* files.
> >From the ssldump perspective it's technically straightforward. However,
> I don't think it it really captures what you want. Much of the SSL data
> you care about isn't the plaintext but rather the handshake and alert
> traffic and this apporach wouldn't capture any of that in any interesting
The SSL plugin could include code to examine the traffic in situ instead of
passing it down the stream to the rest of the program. The defragmenter does
this to an extent, as does the latest versions of the http_decode plugin.
Presenting the decoded packet stream to the rest of the program for analysis
by the detection engine is something that the preprocessors can actually
influence, telling the rest of the program to ignore the packet if it wants.
If the packet isn't ignored, it goes through the rest of the preprocessors and
the detection engine by default. You know SSL a lot better than I do, so how
you want to structure things (and what's important) is up to you. People who
code up plugins for Snort are free to do it anyway they see fit.
roesch at ...48...
More information about the Snort-devel