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.
This commit is contained in:
Johanna Amann 2017-09-09 22:25:49 -07:00
parent 5efaaf1368
commit 1ede6bf7fe
5 changed files with 33 additions and 1 deletions

View file

@ -487,7 +487,7 @@ type SSLExtension(rec: HandshakeRecord) = record {
EXT_SIGNATURE_ALGORITHMS -> signature_algorithm: SignatureAlgorithm(rec)[] &until($element == 0 || $element != 0);
EXT_SIGNED_CERTIFICATE_TIMESTAMP -> certificate_timestamp: SignedCertificateTimestampList(rec)[] &until($element == 0 || $element != 0);
EXT_KEY_SHARE -> key_share: KeyShare(rec)[] &until($element == 0 || $element != 0);
EXT_SUPPORTED_VERSIONS -> supported_versions: SupportedVersions(rec)[] &until($element == 0 || $element != 0);
EXT_SUPPORTED_VERSIONS -> supported_versions_selector: SupportedVersionsSelector(rec, data_len)[] &until($element == 0 || $element != 0);
EXT_PSK_KEY_EXCHANGE_MODES -> psk_key_exchange_modes: PSKKeyExchangeModes(rec)[] &until($element == 0 || $element != 0);
default -> data: bytestring &restofdata;
};
@ -495,6 +495,11 @@ type SSLExtension(rec: HandshakeRecord) = record {
%include tls-handshake-signed_certificate_timestamp.pac
type SupportedVersionsSelector(rec: HandshakeRecord, data_len: uint16) = case rec.is_orig of {
true -> a: SupportedVersions(rec);
false -> b: bytestring &length=data_len &transient;
}
type SupportedVersions(rec: HandshakeRecord) = record {
length: uint8;
versions: uint16[] &until($input.length() == 0);

View file

@ -0,0 +1,10 @@
#separator \x09
#set_separator ,
#empty_field (empty)
#unset_field -
#path ssl
#open 2017-09-10-05-23-15
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p version cipher curve server_name resumed last_alert next_protocol established cert_chain_fuids client_cert_chain_fuids subject issuer client_subject client_issuer
#types time string addr port addr port string string string string bool string string bool vector[string] vector[string] string string string string
1505019126.007778 CHhAvVGS1DHFjwGM9 192.168.0.2 62873 104.196.219.53 443 TLSv12 TLS_AES_128_GCM_SHA256 x25519 tls.ctf.network T - - T - - - - - -
#close 2017-09-10-05-23-16

View file

@ -0,0 +1,16 @@
# @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);
}