On Mar 13, 2014, at 12:54 PM, Bernhard Amann <[email protected]> wrote:
> function get_file_handle(c: connection, is_orig: bool): string
> {
> set_session(c);
>
> local depth: count;
>
> if ( is_orig )
> {
> depth = c$ssl$client_depth;
> ++c$ssl$client_depth;
> }
> else
> {
> depth = c$ssl$server_depth;
> ++c$ssl$server_depth;
> }
>
> return cat(Analyzer::ANALYZER_SSL, c$start_time, is_orig,
> id_string(c$id), depth);
> }
>
> I have no idea if that is “matching” or not - in any case, the above C code
> does not work in combination with that
> file handle generation. Thinking about it, it makes sense - the EndOfFile
> function probably calls get_file_handle again for
> that connection, gets a different file handle back (because the counters are
> increased), and hence removal will not work.
Yes, that looks like what would happen.
> …even after reading through the how to, I was not quite clear on the fact,
> that get_file_handle
> has to always return the same value for the same file. Which is impossible to
> accomplish in cases
> like this, because, several certificates are sent over a connection, and you
> do not get any further information
> with the get_file_handle call. So - you more or less have to return differing
> IDs for everything.
Instead of incrementing the depth in get_file_handle, it could increment it in
a x509_certificate handler? That way the handle remains the same between the
DataIn/EndOfFile pairs, but the next DataIn/EndOfFile will get a new file
handle due to the incremented depth.
Not suggesting you change it from using the pre-computed file id method you
currently have, just challenging the impossibility claim :). And I do agree
the whole script-layer generation of file handle string is difficult to
understand/use, but I don’t have any ideas at the moment for helping that...
> Perhaps the EndOfFile functions should get some warning that details in which
> circumstances you can use
> them (probably - static per-connection ID).
I don’t think there’s any limitation/circumstances unique to EndOfFile that
differs from the other FAF APIs.
> Also - it might be nice to throw some kind of reporter warning when EndOfFile
> is called for a file ID that
> does not exists.
>
> If I understood everything right, that should never happen during normal
> operations, should it?
It could be that the file timed out and was already cleaned up before a
protocol analyzer called EndOfFile. I think it can also be the case that a
protocol analyzer only ever calls EndOfFile because a connection got
closed/reset before any file data was seen.
- Jon
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
