th5/testdata/Server-TLSv11-FallbackSCSV

>>> Flow 1 (client to server)
00000000  16 03 01 00 63 01 00 00  5f 03 02 6e 78 cc 6a ea  |....c..._..nx.j.|
00000010  13 aa a8 20 76 7d 32 ca  c7 3f be 88 36 ae fb c3  |... v}2..?..6...|
00000020  ca 95 35 70 54 20 3b 18  3b ba 82 00 00 14 c0 0a  |..5pT ;.;.......|
00000030  c0 14 00 39 c0 09 c0 13  00 33 00 35 00 2f 00 ff  |...9.....3.5./..|
00000040  56 00 01 00 00 22 00 0b  00 04 03 00 01 02 00 0a  |V...."..........|
00000050  00 0a 00 08 00 1d 00 17  00 19 00 18 00 23 00 00  |.............#..|
00000060  00 16 00 00 00 17 00 00                           |........|
>>> Flow 2 (server to client)
00000000  15 03 02 00 02 02 56                              |......V|
crypto/tls: support TLS_FALLBACK_SCSV as a server. A new attack on CBC padding in SSLv3 was released yesterday[1]. Go only supports SSLv3 as a server, not as a client. An easy fix is to change the default minimum version to TLS 1.0 but that seems a little much this late in the 1.4 process as it may break some things. Thus this patch adds server support for TLS_FALLBACK_SCSV[2] -- a mechanism for solving the fallback problem overall. Chrome has implemented this since February and Google has urged others to do so in light of yesterday's news. With this change, clients can indicate that they are doing a fallback connection and Go servers will be able to correctly reject them. [1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html [2] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/157090043 2014-10-16 01:54:04 +01:00			`>>> Flow 1 (client to server)`
crypto/tls: enable ChaCha20-Poly1305 cipher suites by default. This change enables the ChaCha20-Poly1305 cipher suites by default. This changes the default ClientHello and thus requires updating all the tests. Change-Id: I6683a2647caaff4a11f9e932babb6f07912cad94 Reviewed-on: https://go-review.googlesource.com/30958 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> 2016-10-12 18:53:35 +01:00			`00000000 16 03 01 00 63 01 00 00 5f 03 02 6e 78 cc 6a ea \|....c..._..nx.j.\|`
			`00000010 13 aa a8 20 76 7d 32 ca c7 3f be 88 36 ae fb c3 \|... v}2..?..6...\|`
			`00000020 ca 95 35 70 54 20 3b 18 3b ba 82 00 00 14 c0 0a \|..5pT ;.;.......\|`
crypto/tls: switch to OpenSSL 1.1.0 for test data. We will need OpenSSL 1.1.0 in order to test some of the features expected for Go 1.8. However, 1.1.0 also disables (by default) some things that we still want to test, such as RC4, 3DES and SSLv3. Thus developers wanting to update the crypto/tls test data will need to build OpenSSL from source. This change updates the test data with transcripts generated by 1.1.0 (in order to reduce future diffs) and also causes a banner to be printed if 1.1.0 is not used when updating. (The test for an ALPN mismatch is removed because OpenSSL now terminates the connection with a fatal alert if no known ALPN protocols are offered. There's no point testing against this because it's an OpenSSL behaviour.) Change-Id: I957516975e0b8c7def84184f65c81d0b68f1c551 Reviewed-on: https://go-review.googlesource.com/30821 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> 2016-10-11 18:08:57 +01:00			`00000030 c0 14 00 39 c0 09 c0 13 00 33 00 35 00 2f 00 ff \|...9.....3.5./..\|`
			`00000040 56 00 01 00 00 22 00 0b 00 04 03 00 01 02 00 0a \|V...."..........\|`
			`00000050 00 0a 00 08 00 1d 00 17 00 19 00 18 00 23 00 00 \|.............#..\|`
			`00000060 00 16 00 00 00 17 00 00 \|........\|`
crypto/tls: support TLS_FALLBACK_SCSV as a server. A new attack on CBC padding in SSLv3 was released yesterday[1]. Go only supports SSLv3 as a server, not as a client. An easy fix is to change the default minimum version to TLS 1.0 but that seems a little much this late in the 1.4 process as it may break some things. Thus this patch adds server support for TLS_FALLBACK_SCSV[2] -- a mechanism for solving the fallback problem overall. Chrome has implemented this since February and Google has urged others to do so in light of yesterday's news. With this change, clients can indicate that they are doing a fallback connection and Go servers will be able to correctly reject them. [1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html [2] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/157090043 2014-10-16 01:54:04 +01:00			`>>> Flow 2 (server to client)`
			`00000000 15 03 02 00 02 02 56 \|......V\|`