question regarding session creation

I have written a gsiftp analysis tool for bro, which more or less mimics
the behavior of the regular ftp analysis engine. The authentication
mechanism within gsiftp is a regular ssl handshake which is encoded
within the ftp command session as 'ADAT' commands (as per RFC 2228 if
anybody cares) with the contents of the handshake base64 encoded. There
also exists a SSL handshake decoder (not of my creation) which can
digest regular SSL data connections.

I would like to be able to create a new connection object to analyze the
authentication handshake from within the gsiftp analyzer, but have so
far been unable to get anything to work. The main problem is that for a
connection instantiation, say:

FTP_Conn::FTP_Conn(NetSessions* s, HashKey* k, double t, const ConnID* id,
~ const struct tcphdr* tp)
: TCP_Connection(s, k, t, id, tp)
~ {
~ pending_reply = 0;
~ }

the HashKey and ConnID are the result of the source port+IP and hence a
internal call to create another connection object has problems when it
comes time for that object to be destroyed. I have tried using an
artificial address space to create non-conflicting hash indexes, but
have not found success.

Any thoughts or ideas?


- -----
Scott Campbell
NERSC Security Analyst

If I understand your description correctly, you would like to decode
an independent SSL session inside the gsiftp connection object,
right? So, basically you need the protocol decoding functionality
for SSL, but without the surrounding connection state management.

I am not really familiar with the internals of the upcoming SSL
analyzer, but as far as I know it implements exactly this separation
(because it cannot decide whether it sees an SSL v2 or v3 connection
before having parsed some data). Take a look at the classes
SSL_Interpreter and SSL_InterpreterEndpoint (I think you already
have the code, right? If not, contact me again or, even better, ask
Michael and Benedikt about this (cc'ed; are you guys on the Bro

More generally, the separation of connections and protocol analyzers
could make sense for other applications, too. For example, there are
cases in which we cannot deduce the service from the ports that are
used. Or, we may want to switch the analyzer after some data has
already been read (again, SSL is a nice example: After having
analyzed the handshake of an HTTPS session, we could pass the data
on to the HTTP analyzer) But this would be a major change in Bro's


Thanks for the quick reply.

The problem that I have with using SSL_Interpretor* is that it's creator
relies on the SSL_Connection_Proxy which is the same sort of function
that I can't seem to get working. The *version* of SSL is not
pre-determined, but the connection type is already been assigned. :frowning:

I would do some sort of dreadful hack to get this working (ie create a
new blank creator or something of the sort), but the the
SSL_Connection_Proxy proxy value is used thought the remaining SSL and
X509 code and everything would just break horribly.

This sort of problem may be insolvable with the current design of bro,
at least as far as I understand. I will probably create a new generic
GSI class that just answers questions regarding data handed to it
(example X509 certs and the like) for the time being (since the
necessity for dealing with many of the complexitys of 'real' SSL
connections are not present). It will not be at all interested in
connection data, so there will not be problems assosciated with it of
this nature.

If you (or anybody else) get other ideas, or see something that I missed
please let me know as the solution I am following is less than ideal...

Robin Sommer wrote:

Ah, I see. So, this doesn't seem to be an option. :frowning:

But then I also do not see a real solution to this problem (other
than rewriting and/or copying large chunks of code...)