[Snort-devel] SSL decode integration and future directions for Snort

Martin Roesch roesch at ...48...
Tue Dec 19 23:42:47 EST 2000

Todd Lewis wrote:
> On Tue, 19 Dec 2000, Martin Roesch wrote:
> > Hi Tood, et al.
> >
> > I think modularizing ssldump for easy inclusion into Snort and other projects
> > is probably the way to go.  I really see this as an application layer decoder,
> > which is something we hope to introduce into follow-on versions of Snort
> > (modular decoder plugin architecture).
> Do you mean the next release, or some alternate version?

No, we're in code freeze for 1.7 right now.  Probably after we finish up 1.7
the 1.X codebase will go into maintenance mode and we'll begin development of
Snort 2.0.

> > 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?

We're still working to determine this! :)  In 2.0 I want to introduce decoder
plugins which will allow arbitrary protocol support for Snort to be
implemented.  This will apply at all protocol layers from data link up to
application.  What it'll probably look like is a list of pointers to the
appropriate data types placed into the Packet struct and dynamically cast at
run time.  For example, I can envision the Packet struct looking something
like this:

struct _Packet
     void *dlink;
     void *network;
     void *transport;
     void *application;

     /* other stuff... */
} Packet;

Then when a decoder runs it does something like this:

void DecodeEthernet(RawPkt *rawpkt, Packet *p)
    EthHdr *eh;

    /* do stuff... */
    eh = p->dlink = (EthHdr *) rawpkt->raw;
    /* more stuff... */

    DecodeNetworkLayer(eh->ether_type, rawpkt, p);


The DecodeNetworkLayer() contains a sorted list of the active network layer
decoders that are available and calls the appropriate one.  Perhaps it'd be
better to create an array of function pointers (one for each protocol) and
make the call as a dereference into this array:

typedef struct _DecoderNode
     void (*DecodeFunc)(RawPkt *, Packet *);
     char *proto_name;
     /* etc */
} DecoderNode;

DecoderNode NetworkDecode[65536]; /* one per protocol */

Then later on we initialize this when the decoder plugins are registering

NetworkDecode[0x800].DecodeFunc = DecodeIP; /* register the IP layer decoder

This function would be called from the data link layer decoder like this:

if(NetworkDecode[eh->ether_type != NULL)
    NetworkDecode[eh->ether_type].DecodeFunc(rawpkt, p);

This is repeated for the other layers on down.  Application layer decoders
will register themselves on the ports/protocols on which they should be called
on and will fill in data structs that are attached to themselves, which
application aware detection modules would be able to access.  The SSL decoder
might register at another layer (session?) to provide the application layer
decoders with the data they need to do their jobs.  

We're still talking about it, but I'm thinking that we might want to have two
data paths in 2.0, a packet stream and an application stream.  The packet
stream would be what we're all used to now, the application stream would be
the defragemented, reassembled normalized application data that things like
the pattern matcher would like to have.  I'm concerned about the speed and
memory impact of doing something like this, which is why it's a "might" right
now. :)

Or something like this.  I'm still thinking about how I'd like this to look,
so I'm definitely open to suggestions. :)


> --
> Todd Lewis                                       tlewis at ...120...
>   God grant me the courage not to give up what I think is right, even
>   though I think it is hopeless.          - Admiral Chester W. Nimitz

Martin Roesch
roesch at ...48...

More information about the Snort-devel mailing list