[Bro-Dev] [Bro-Commits] [git/bro] topic/bernhard/file-analysis-x509: Change x509 log - now certificates are only logged once per hour. (0d50b8b)

[Siwek, Jonathan Luke]

On Mar 13, 2014, at 12:54 PM, Bernhard Amann <bernhard at ICSI.Berkeley.EDU> 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