[Bro-Dev] Better Handling of User Agents in Software Framework

Vlad Grigorescu vlad at grigorescu.org
Mon Dec 14 07:51:40 PST 2015

I'm not thrilled with those user agents are being handled right now, and
I'm curious to get some thoughts. Take, for example the Safari user-agent
string of:

> Safari/11601.3.9 CFNetwork/760.2.6 Darwin/15.2.0 (x86_64)

Right now, this gets parsed as:

> name=Safari,
> version=[
>       major=11601,
>       minor=3,
>       minor2=9,
>       minor3=<uninitialized>,
>       addl=CFNetwork/760
> ],
> unparsed_version=Safari/11601.3.9 CFNetwork/760.2.6 Darwin/15.2.0 (x86_64)

RFC 7231 says:

> "The User-Agent field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]), which
together identify the user agent software and its significant subproducts."

What I would like to see is this user-agent generate three separate entries
in software.log:

> Safari 11601.3.9
> CFNetwork 760.2.6
> Darwin 15.2.0 (x86_64)

I think this is a better representation of the software that's actually
running on the machine (they're running this version of Safari, this
version of the CFNetwork library, and this version of the Darwin kernel).

Taking this to the server-side, given:

> Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8j-fips mod_auth_kerb/5.4

I'd like to see:

> Apache/2.2.25 (Unix)
> mod_ssl/2.2.25
> OpenSSL/0.9.8j-fips
> mod_auth_kerb/5.4
> PHP/5.4.13

All of those are pieces of software running on that system, and maintaining
it as a user-agent is a construct from HTTP, which I don't feel belongs in
the software.log. Another warning sign that this is an area that could use
some work is the comment above Software::parse:

> # Don't even try to understand this now, just make sure the tests are

Curious to hear thoughts on this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20151214/0f20f25f/attachment.html 

More information about the bro-dev mailing list