mirror of
https://github.com/zeek/zeek.git
synced 2025-10-02 06:38:20 +00:00
1ede6bf7fe
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.
16 lines
751 B
Text
16 lines
751 B
Text
# @TEST-EXEC: bro -C -r $TRACES/tls/chrome-63.0.3211.0-canary-tls_experiment.pcap %INPUT
|
|
# @TEST-EXEC: btest-diff ssl.log
|
|
# @TEST-EXEC: btest-diff .stdout
|
|
|
|
# This is a trace that uses a completely non-standard way of establishing TLS 1.3; this seems
|
|
# to be an undocumented extension where the TLS version is negotiated via the server sending back
|
|
# an supported_versions extension (which, according to the RFC is strictly prohibited).
|
|
#
|
|
# This only seems to happen with Chrome talking to google servers. We do not recognize this as
|
|
# TLS 1.3, but we do not abort when encountering traffic like this.
|
|
|
|
event ssl_extension(c: connection, is_orig: bool, code: count, val: string)
|
|
{
|
|
if ( ! is_orig && code == 43 )
|
|
print bytestring_to_hexstr(val);
|
|
}
|