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.

src/analyzer/protocol/ssl/tls-handshake-protocol.pac

@@ -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);

testing/btest/Baseline/scripts.base.protocols.ssl.tls13-experiment/.stdout

@@ -0,0 +1 @@
+7e01

testing/btest/Baseline/scripts.base.protocols.ssl.tls13-experiment/ssl.log

@@ -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

testing/btest/scripts/base/protocols/ssl/tls13-experiment.test

@@ -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);
+	}