- Plain text now identified with BOMs for UTF8,16,32
(even though 16 and 32 wouldn't get identified as plain text, oh-well)
- X.509 certificates are now populating files.log with
the mime type application/pkix-cert.
- File signatures are split apart into file types
to help group and organize signatures a bit better.
- Normalized some FILE_ANALYSIS debug messages.
- Improved Javascript detection.
- Improved HTML detection.
- Removed a bunch of bad signatures.
- Merged a bunch of signatures that ultimately detected
the same mime type.
- Added detection for MS LNK files.
- Added detection for cross-domain-policy XML files.
- Added detection for SOAP envelopes.
The only thing that is missing is a signature to detect the protocol (it
has no well-known port).
Reassembly is kind of fidgety - at the moment we only support
re-assembling one simultaneous message per direction (which looking at
our test-traffic might not be a problem). And I am not quite sure if I
got all cases correct...
But - it works :)
that already has been delivered to the analyzer, not just future data.
No testcase because this is hard to reproduce, this was only found due
to mistakenly triggering an error in life traffic at a site...
This commit mostly does a lot of refactoring of the current SSL
analyzer, which is split into several parts.
The handshake protocol is completely taken out of the SSL analyzer and
was refactored into its own analyzer (called tls-handshake-analyzer).
This will also (finally) make it possible to deal with TLS record
fragmentation.
Apart from that, the parts of the SSL analyzer that are common to DTLS
were split into their own pac files. Both the SSL analyzer and the (very
basic, mostly nonfunctional) DTLS analyzer use their own pac files and
those shared pac files.
All SSL tests still pass after refactoring so I hope I did not break
anything too badly.
At the moment, we have two different modules in one directory and I
guess the way I am doing this might be an abuse of the system. It seems
to work though...
that already has been delivered to the analyzer, not just future data.
No testcase because this is hard to reproduce, this was only found due
to mistakenly triggering an error in life traffic at a site...
intermediate chains that it encounters on the wire and use those to try
to validate chains that might be missing intermediate certificates.
This vastly improves the number of certificates that Bro can validate.
The only drawback is that now validation behavior is not entirely
predictable anymore - the certificate of a server can fail to validate
when Bro just started up (due to the intermediate missing), and succeed
later, when the intermediate can be found in the cache.
Has been tested on big-ish clusters and should not introduce any
performance problems.
* origin/topic/jsiwek/broker:
Fix build warnings, clarify broker requirements, update submodule.
Rename comm/ directories to broker/
Rename broker-related namespaces.
Improve remote logging via broker.
Disable a stream's remote logging via broker if it fails.
Improve some broker communication unit tests.
Adapt to a broker API change.
BIT-1319 #merged
Basically, at least some rdp certificates specify a completely invalid
and nonsensical value for theyr key type. OpenSSL does not like this and
refuses to parse the key in this case. With this change, we detect this
case and special-case it, hinting to OpenSSL what kind of key we have.
This gives us additional information that we would not have otherwhise
in the log file (like key length and the exponent).
