This one adds a separate new case that has to be parsed differently - if
a hello-retry-request is sent, only the namedgroup is sent - without the
additional key material.
Support for the legacy extension is retained.
The way in which TLS 1.3 is negotiated was changed slightly in later
revisions of the standard. The final version is only sent in an
extension - while the version field in the server hello still shows TLS
1.2.
This patch makes ssl.log show the correct version again.
Now we only parse the SignatureAndHashalgorithm field in cases where it
is present. This change also takes care to respect SCTs, which do
include the SignatureAndHashalgorithm in their digitally-signed struct,
even when used in protocol versions that do not have the
SignatureAndHashalgorithm in the protocols digitally-signed struct.
I also added tests to make sure this does indeed work with TLS 1.1 - it
turns out that so far we did not have a single TLS 1.1 pcap.
It turns out that Chrome supports an experimental mode to support TLS
1.3, which uses a non-standard way to negotiate TLS 1.3 with a server.
This non-standard way to negotiate TLS 1.3 breaks the current draft RFC
and re-uses an extension on the server-side with a different binary
formatting, causing us to throw a binpac exception.
This patch ignores the extension when sent by the server, continuing to
correctly parse the server_hello reply (as far as possible).
From what I can tell this seems to be google working around the fact
that MITM equipment cannot deal with TLS 1.3 server hellos; this change
makes the fact that TLS 1.3 is used completely opaque unless one looks
into a few extensions.
We currently log this as TLS 1.2.
The dpd signature missed a few cases that are used for TLS 1.3,
especially when draft versions (which are all that we are seeing at the
moment) are being negotiated.
This fix mostly allows draft versions in the server hello (identified by
7F[version]; since we do not know how many drafts there will be, we are
currently allowing a rather safe upper limit.
This also rewrites the certificate validation script (which we need for
this) slightly.
This could need a bit of caching, but should generally work very
reliably.
This is a tiny bit evil because it uses parts of the SSL protocol
analyzer in the X.509 certificate parser. Which is the fault of the
protocol, which replicates the functionality.
Now the DTLS analyzer cleanly skips all STUN messages; no warnings
should be logged to dpd.log and parsing should work flawlessly with
intermixed STUN messages.
There was a bug in the new parsing code, introduced in
708ede22c6 which parses validity times
incorrectly if they are before the year 2000. What happens in this case
is that the 2-digit year will be interpreted to be in the 21st century
(1999 will be parsed as 2099, e.g.).
This is a very simple XMPP analyzer that basically only can parse the
protocol until the client and server start negotiating a TLS session. At
that point, the TLS analyzer is attached.
While the basic case seems to be working, I fully expect that I missed
something and that this might break in a lot of cases.
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...
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.
Now the right signer certificate for the reply is looked up (and no longer assumed that it is the first one) and a few compares are fixed. Plus - there are more test cases that partially send certificates in the ocsp message and partially do not - and it seems to work fine in all cases.
Addresses BIT-1212
This also fixes the heartbleed detector to work for encrypted attacks in this
branch again. It stopped working, because the SSL analyzer now successfully detects
established connections, and the scripts usually disable analyzing after that.
(The heartbeat branch should not have been affected)
