Commit graph

5 commits

Author SHA1 Message Date
Johanna Amann
e14eddeb97 SSL Analyzer: track connection direction by messages
This PR changes the way in which the SSL analyzer tracks the direction
of connections. So far, the SSL analyzer assumed that the originator of
a connection would send the client hello (and other associated
client-side events), and that the responder would be the SSL servers.

In some circumstances this is not true, and the initiator of a
connection is the server, with the responder being the client. So far
this confused some of the internal statekeeping logic and could lead to
mis-parsing of extensions.

This reversal of roles can happen in DTLS, if a connection uses STUN -
and potentially in some StartTLS protocols.

This PR tracks the direction of a TLS connection using the hello
request, client hello and server hello handshake messages. Furthermore,
it changes the SSL events from providing is_orig to providing is_client,
where is_client is true for the client_side of a connection. Since the
argument positioning in the event has not changed, old scripts will
continue to work seamlessly - the new semantics are what everyone
writing SSL scripts will have expected in any case.

There is a new event that is raised when a connection is flipped. A
weird is raised if a flip happens repeatedly.

Addresses GH-2198.
2022-06-24 18:35:44 +01:00
Jon Siwek
7967a5b0aa General btest cleanup
- Use `-b` most everywhere, it will save time.

- Start some intel tests upon the input file being fully read instead of
  at an arbitrary time.

- Improve termination condition for some sumstats/cluster tests.

- Filter uninteresting output from some supervisor tests.

- Test for `notice_policy.log` is no longer needed.
2020-08-11 11:26:22 -07:00
Robin Sommer
789cb376fd GH-239: Rename bro to zeek, bro-config to zeek-config, and bro-path-dev to zeek-path-dev.
This also installs symlinks from "zeek" and "bro-config" to a wrapper
script that prints a deprecation warning.

The btests pass, but this is still WIP. broctl renaming is still
missing.

#239
2019-05-01 21:43:45 +00:00
Johanna Amann
f39efd0317 Recognize TLS 1.3 negotiation correctly.
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.
2018-03-27 14:58:06 -07:00
Johanna Amann
1ede6bf7fe Add TLS 1.3 fix and testcase.
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.
2017-09-09 22:25:49 -07:00