What does everyone think of making some change for 2.5 so that certificates from SSL aren't logged in the files.log by default? I've heard grumblings about the number of certs that show up from quite a few people and personally noticed that the number of certificates will dwarf all other files types pretty badly which makes the output look a bit weird since very few people are ever interested in looking at those files in the files.log.
Certificates would still be passed through the files framework, so it's not an architectural change, it would all be related to just not doing the log. There is one minor issue that this brings up though in that right now certificate hashes are all given in the files.log. We could move them elsewhere like x509.log or ssl.log, but I'm curious if anyone had thoughts on what they think would be most useful?
.Seth
I think kind of like having the certificates being handled as files by default. However, I see that most people who run clusters in production do not want that information in files.log. So - from my point of view, it might make sense to have a policy script that filters certificates from files.log and adds the hashes to x509.log; and we have that auto-loaded by default in local.bro.
Would that make sense?
Johanna
I agree that having the certs logged to files.log creates a lot of noise that can be painful to wade through. The downside to placing the hashes in x509.log is that would require a 2nd step of turning the fuid’s into cuid’s when searching for activity involving a given cert hash. What about the idea of having files.x509.log & simply diverting pkix-cert to that log by default? Keeping “files” in the name, allows one to search for <hash> in files*.log and use unix tools to grab the conn details. Quite useful when you have a mixed list of cert hashes and other hashes of interest.
- Keith