kris/th5
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
7ef5c9eac8
th5/testdata/Client-TLSv12-ClientCert-RSA-AES256-GCM-SHA384

134 lines
10 KiB
Plaintext
Raw Normal View History

crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
>>> Flow 1 (client to server)
crypto/tls: support AES-128-CBC cipher suites with SHA-256. These were new with TLS 1.2 and, reportedly, some servers require it. Since it's easy, this change adds suport for three flavours of AES-128-CBC with SHA-256 MACs. Other testdata/ files have to be updated because this changes the list of cipher suites offered by default by the client. Fixes #15487. Change-Id: I1b14330c31eeda20185409a37072343552c3464f Reviewed-on: https://go-review.googlesource.com/27315 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-08-18 00:45:47 +01:00
00000000 16 03 01 00 8b 01 00 00 87 03 03 00 00 00 00 00 |................|
crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
crypto/tls: support AES-128-CBC cipher suites with SHA-256. These were new with TLS 1.2 and, reportedly, some servers require it. Since it's easy, this change adds suport for three flavours of AES-128-CBC with SHA-256 MACs. Other testdata/ files have to be updated because this changes the list of cipher suites offered by default by the client. Fixes #15487. Change-Id: I1b14330c31eeda20185409a37072343552c3464f Reviewed-on: https://go-review.googlesource.com/27315 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-08-18 00:45:47 +01:00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 28 c0 2f |.............(./|
00000030 c0 2b c0 30 c0 2c c0 27 c0 13 c0 23 c0 09 c0 14 |.+.0.,.'...#....|
00000040 c0 0a 00 9c 00 9d 00 3c 00 2f 00 35 c0 12 00 0a |.......<./.5....|
00000050 00 05 c0 11 c0 07 01 00 00 36 00 05 00 05 01 00 |.........6......|
00000060 00 00 00 00 0a 00 08 00 06 00 17 00 18 00 19 00 |................|
00000070 0b 00 02 01 00 00 0d 00 0e 00 0c 04 01 04 03 05 |................|
00000080 01 05 03 02 01 02 03 ff 01 00 01 00 00 12 00 00 |................|
crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
>>> Flow 2 (server to client)
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
00000000 16 03 03 00 59 02 00 00 55 03 03 e5 6a 08 9d 28 |....Y...U...j..(|
00000010 49 64 df 4d bd 0e b8 d3 0d af d9 20 78 4a a0 b8 |Id.M....... xJ..|
00000020 0d 12 83 5a 9a 9f 73 fe 53 d6 75 20 d5 6f df 86 |...Z..s.S.u .o..|
00000030 33 7a 02 8c cd f9 a4 8c ff 21 89 29 a4 ee 54 81 |3z.......!.)..T.|
00000040 fc 52 99 f5 0f 1e d3 a5 f9 fe 64 d1 c0 30 00 00 |.R........d..0..|
crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
00000050 0d ff 01 00 01 00 00 0b 00 04 03 00 01 02 16 03 |................|
crypto/x509: require a NULL parameters for RSA public keys. The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA public key must be NULL. BoringSSL enforces this so we have strong evidence that this is a widely compatible change. Embarrassingly enough, the major source of violations of this is us. Go used to get this correct in only one of two places. This was only fixed in 2013 (with 4874bc9b). That's why lots of test certificates are updated in this change. Fixes #16166. Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab Reviewed-on: https://go-review.googlesource.com/27312 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-08-17 23:55:15 +01:00
00000060 03 02 59 0b 00 02 55 00 02 52 00 02 4f 30 82 02 |..Y...U..R..O0..|
00000070 4b 30 82 01 b4 a0 03 02 01 02 02 09 00 e8 f0 9d |K0..............|
00000080 3f e2 5b ea a6 30 0d 06 09 2a 86 48 86 f7 0d 01 |?.[..0...*.H....|
00000090 01 0b 05 00 30 1f 31 0b 30 09 06 03 55 04 0a 13 |....0.1.0...U...|
000000a0 02 47 6f 31 10 30 0e 06 03 55 04 03 13 07 47 6f |.Go1.0...U....Go|
000000b0 20 52 6f 6f 74 30 1e 17 0d 31 36 30 31 30 31 30 | Root0...1601010|
000000c0 30 30 30 30 30 5a 17 0d 32 35 30 31 30 31 30 30 |00000Z..25010100|
000000d0 30 30 30 30 5a 30 1a 31 0b 30 09 06 03 55 04 0a |0000Z0.1.0...U..|
000000e0 13 02 47 6f 31 0b 30 09 06 03 55 04 03 13 02 47 |..Go1.0...U....G|
000000f0 6f 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 |o0..0...*.H.....|
00000100 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 db 46 |.......0.......F|
00000110 7d 93 2e 12 27 06 48 bc 06 28 21 ab 7e c4 b6 a2 |}...'.H..(!.~...|
00000120 5d fe 1e 52 45 88 7a 36 47 a5 08 0d 92 42 5b c2 |]..RE.z6G....B[.|
00000130 81 c0 be 97 79 98 40 fb 4f 6d 14 fd 2b 13 8b c2 |....y.@.Om..+...|
00000140 a5 2e 67 d8 d4 09 9e d6 22 38 b7 4a 0b 74 73 2b |..g....."8.J.ts+|
00000150 c2 34 f1 d1 93 e5 96 d9 74 7b f3 58 9f 6c 61 3c |.4......t{.X.la<|
00000160 c0 b0 41 d4 d9 2b 2b 24 23 77 5b 1c 3b bd 75 5d |..A..++$#w[.;.u]|
00000170 ce 20 54 cf a1 63 87 1d 1e 24 c4 f3 1d 1a 50 8b |. T..c...$....P.|
00000180 aa b6 14 43 ed 97 a7 75 62 f4 14 c8 52 d7 02 03 |...C...ub...R...|
00000190 01 00 01 a3 81 93 30 81 90 30 0e 06 03 55 1d 0f |......0..0...U..|
000001a0 01 01 ff 04 04 03 02 05 a0 30 1d 06 03 55 1d 25 |.........0...U.%|
000001b0 04 16 30 14 06 08 2b 06 01 05 05 07 03 01 06 08 |..0...+.........|
000001c0 2b 06 01 05 05 07 03 02 30 0c 06 03 55 1d 13 01 |+.......0...U...|
000001d0 01 ff 04 02 30 00 30 19 06 03 55 1d 0e 04 12 04 |....0.0...U.....|
000001e0 10 9f 91 16 1f 43 43 3e 49 a6 de 6d b6 80 d7 9f |.....CC>I..m....|
000001f0 60 30 1b 06 03 55 1d 23 04 14 30 12 80 10 48 13 |`0...U.#..0...H.|
00000200 49 4d 13 7e 16 31 bb a3 01 d5 ac ab 6e 7b 30 19 |IM.~.1......n{0.|
00000210 06 03 55 1d 11 04 12 30 10 82 0e 65 78 61 6d 70 |..U....0...examp|
00000220 6c 65 2e 67 6f 6c 61 6e 67 30 0d 06 09 2a 86 48 |le.golang0...*.H|
00000230 86 f7 0d 01 01 0b 05 00 03 81 81 00 9d 30 cc 40 |.............0.@|
00000240 2b 5b 50 a0 61 cb ba e5 53 58 e1 ed 83 28 a9 58 |+[P.a...SX...(.X|
00000250 1a a9 38 a4 95 a1 ac 31 5a 1a 84 66 3d 43 d3 2d |..8....1Z..f=C.-|
00000260 d9 0b f2 97 df d3 20 64 38 92 24 3a 00 bc cf 9c |...... d8.$:....|
00000270 7d b7 40 20 01 5f aa d3 16 61 09 a2 76 fd 13 c3 |}.@ ._...a..v...|
00000280 cc e1 0c 5c ee b1 87 82 f1 6c 04 ed 73 bb b3 43 |...\.....l..s..C|
00000290 77 8d 0c 1c f1 0f a1 d8 40 83 61 c9 4c 72 2b 9d |w.......@.a.Lr+.|
000002a0 ae db 46 06 06 4d f4 c1 b3 3e c0 d1 bd 42 d4 db |..F..M...>...B..|
000002b0 fe 3d 13 60 84 5c 21 d3 3b e9 fa e7 16 03 03 00 |.=.`.\!.;.......|
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
000002c0 cd 0c 00 00 c9 03 00 17 41 04 af 8b 15 ee fc b2 |........A.......|
000002d0 95 b3 38 67 05 c0 3f fd a4 1e 25 e1 58 a2 35 27 |..8g..?...%.X.5'|
000002e0 55 e1 05 01 8d 77 8b 77 b6 d8 23 1f 79 e8 66 cc |U....w.w..#.y.f.|
000002f0 e0 cd 01 1f 37 ab ad c6 dd ae 41 f9 2b 2d 77 b9 |....7.....A.+-w.|
00000300 28 34 5d 27 5d 7a fe 32 86 e4 04 01 00 80 d0 ba |(4]']z.2........|
00000310 8b c2 67 5e 8f 83 8a 32 34 56 4d b7 83 4c 6a 85 |..g^...24VM..Lj.|
00000320 44 24 e5 21 a6 f2 a2 f3 4e 59 bc 86 d9 ed d0 a6 |D$.!....NY......|
00000330 ed 48 ac 3c c4 4b 0c c8 10 34 b0 1a 10 db 7c a6 |.H.<.K...4....|.|
00000340 76 26 15 06 ee 01 22 2f 81 95 3b cd c6 3f fa 24 |v&...."/..;..?.$|
00000350 59 f6 da 4b e1 7d 5e f0 f7 96 cc 67 73 74 c0 76 |Y..K.}^....gst.v|
00000360 50 50 74 87 33 f2 92 66 8f 87 de 5b e2 a4 f8 c4 |PPt.3..f...[....|
00000370 60 c5 ac a9 86 93 fc 81 73 d6 77 da c8 7a db 71 |`.......s.w..z.q|
00000380 61 2c cf ea 23 85 89 70 f4 f4 5a c9 c9 bc 16 03 |a,..#..p..Z.....|
00000390 03 00 2a 0d 00 00 26 03 01 02 40 00 1e 06 01 06 |..*...&...@.....|
crypto/x509: require a NULL parameters for RSA public keys. The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA public key must be NULL. BoringSSL enforces this so we have strong evidence that this is a widely compatible change. Embarrassingly enough, the major source of violations of this is us. Go used to get this correct in only one of two places. This was only fixed in 2013 (with 4874bc9b). That's why lots of test certificates are updated in this change. Fixes #16166. Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab Reviewed-on: https://go-review.googlesource.com/27312 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-08-17 23:55:15 +01:00
000003a0 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 |................|
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
000003b0 01 03 02 03 03 02 01 02 02 02 03 00 00 16 03 03 |................|
000003c0 00 04 0e 00 00 00 |......|
crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
>>> Flow 3 (client to server)
crypto/x509: require a NULL parameters for RSA public keys. The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA public key must be NULL. BoringSSL enforces this so we have strong evidence that this is a widely compatible change. Embarrassingly enough, the major source of violations of this is us. Go used to get this correct in only one of two places. This was only fixed in 2013 (with 4874bc9b). That's why lots of test certificates are updated in this change. Fixes #16166. Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab Reviewed-on: https://go-review.googlesource.com/27312 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-08-17 23:55:15 +01:00
00000000 16 03 03 01 fd 0b 00 01 f9 00 01 f6 00 01 f3 30 |...............0|
00000010 82 01 ef 30 82 01 58 a0 03 02 01 02 02 10 5c 19 |...0..X.......\.|
00000020 c1 89 65 83 55 6f dc 0b c9 b9 93 9f e9 bc 30 0d |..e.Uo........0.|
00000030 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 12 31 |..*.H........0.1|
00000040 10 30 0e 06 03 55 04 0a 13 07 41 63 6d 65 20 43 |.0...U....Acme C|
00000050 6f 30 1e 17 0d 31 36 30 38 31 37 32 31 35 32 33 |o0...16081721523|
00000060 31 5a 17 0d 31 37 30 38 31 37 32 31 35 32 33 31 |1Z..170817215231|
00000070 5a 30 12 31 10 30 0e 06 03 55 04 0a 13 07 41 63 |Z0.1.0...U....Ac|
00000080 6d 65 20 43 6f 30 81 9f 30 0d 06 09 2a 86 48 86 |me Co0..0...*.H.|
00000090 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 |...........0....|
000000a0 81 00 ba 6f aa 86 bd cf bf 9f f2 ef 5c 94 60 78 |...o........\.`x|
000000b0 6f e8 13 f2 d1 96 6f cd d9 32 6e 22 37 ce 41 f9 |o.....o..2n"7.A.|
000000c0 ca 5d 29 ac e1 27 da 61 a2 ee 81 cb 10 c7 df 34 |.])..'.a.......4|
000000d0 58 95 86 e9 3d 19 e6 5c 27 73 60 c8 8d 78 02 f4 |X...=..\'s`..x..|
000000e0 1d a4 98 09 a3 19 70 69 3c 25 62 66 2a ab 22 23 |......pi<%bf*."#|
000000f0 c5 7b 85 38 4f 2e 09 73 32 a7 bd 3e 9b ad ca 84 |.{.8O..s2..>....|
00000100 07 e6 0f 3a ff 77 c5 9d 41 85 00 8a b6 9b ee b0 |...:.w..A.......|
00000110 a4 3f 2d 4c 4c e6 42 3e bb 51 c8 dd 48 54 f4 0c |.?-LL.B>.Q..HT..|
00000120 8e 47 02 03 01 00 01 a3 46 30 44 30 0e 06 03 55 |.G......F0D0...U|
00000130 1d 0f 01 01 ff 04 04 03 02 05 a0 30 13 06 03 55 |...........0...U|
00000140 1d 25 04 0c 30 0a 06 08 2b 06 01 05 05 07 03 01 |.%..0...+.......|
00000150 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 0f |0...U.......0.0.|
00000160 06 03 55 1d 11 04 08 30 06 87 04 7f 00 00 01 30 |..U....0.......0|
00000170 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 03 81 |...*.H..........|
00000180 81 00 46 ab 44 a2 fb 28 54 f8 5a 67 f8 62 94 f1 |..F.D..(T.Zg.b..|
00000190 9a b2 18 9e f2 b1 de 1d 7e 6f 76 95 a9 ba e7 5d |........~ov....]|
000001a0 a8 16 6c 9c f7 09 d3 37 e4 4b 2b 36 7c 01 ad 41 |..l....7.K+6|..A|
000001b0 d2 32 d8 c3 d2 93 f9 10 6b 8e 95 b9 2c 17 8a a3 |.2......k...,...|
000001c0 44 48 bc 59 13 83 16 04 88 a4 81 5c 25 0d 98 0c |DH.Y.......\%...|
000001d0 ac 11 b1 28 56 be 1d cd 61 62 84 09 bf d6 80 c6 |...(V...ab......|
000001e0 45 8d 82 2c b4 d8 83 9b db c9 22 b7 2a 12 11 7b |E..,......".*..{|
000001f0 fa 02 3b c1 c9 ff ea c9 9d a8 49 d3 95 d7 d5 0e |..;.......I.....|
00000200 e5 35 16 03 03 00 46 10 00 00 42 41 04 1e 18 37 |.5....F...BA...7|
00000210 ef 0d 19 51 88 35 75 71 b5 e5 54 5b 12 2e 8f 09 |...Q.5uq..T[....|
00000220 67 fd a7 24 20 3e b2 56 1c ce 97 28 5e f8 2b 2d |g..$ >.V...(^.+-|
00000230 4f 9e f1 07 9f 6c 4b 5b 83 56 e2 32 42 e9 58 b6 |O....lK[.V.2B.X.|
00000240 d7 49 a6 b5 68 1a 41 03 56 6b dc 5a 89 16 03 03 |.I..h.A.Vk.Z....|
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
00000250 00 88 0f 00 00 84 05 01 00 80 2d 1c c8 23 f4 9e |..........-..#..|
00000260 ff fe 30 db 7d 25 41 74 5b 3b e1 f7 c3 92 eb 12 |..0.}%At[;......|
00000270 46 0d f3 3b 4f ff 9c ed d6 f5 4e 3f 58 ad ba 02 |F..;O.....N?X...|
00000280 0b 44 66 94 78 83 a0 ee 0f 05 ec fd f7 4d 97 52 |.Df.x........M.R|
00000290 6c ca 54 28 3c e2 77 92 d5 a3 0d 67 93 cf a9 4c |l.T(<.w....g...L|
000002a0 c6 03 4a c9 cd 22 bb d5 5b 8c 85 60 72 ef f3 2a |..J.."..[..`r..*|
000002b0 ef 6e 74 77 98 6e 19 c0 f0 d4 fa bf ab 36 90 30 |.ntw.n.......6.0|
000002c0 16 63 6b af 74 e4 94 46 6d eb b0 5e fa ff e8 73 |.ck.t..Fm..^...s|
000002d0 05 3f f8 bb f3 be 74 d0 d4 4a 14 03 03 00 01 01 |.?....t..J......|
000002e0 16 03 03 00 28 00 00 00 00 00 00 00 00 02 e2 55 |....(..........U|
000002f0 ab d8 a2 bf 4f 5f 9a 66 ee 0a 94 79 7c 63 04 c0 |....O_.f...y|c..|
00000300 d6 57 c2 c1 d3 0f 0a d5 1e 7d 23 fa 25 |.W.......}#.%|
crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
>>> Flow 4 (server to client)
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
00000000 14 03 03 00 01 01 16 03 03 00 28 17 86 07 f3 42 |..........(....B|
00000010 10 db 93 d3 46 35 51 1d 7d 20 ec fa 37 c7 25 15 |....F5Q.} ..7.%.|
00000020 e1 99 46 a0 2f a1 b8 4a 36 af 1d aa d3 ba 70 a2 |..F./..J6.....p.|
00000030 4e bc 8b |N..|
crypto/tls: return correct hash function when using client certificates in handshake Commit f1d669aee994b28e1afcfe974680565932d25b70 added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040 Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
2015-03-06 13:08:55 +00:00
>>> Flow 5 (client to server)
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
00000000 17 03 03 00 1e 00 00 00 00 00 00 00 01 ba 98 6c |...............l|
00000010 77 50 2f f1 8c 09 ed 9f 74 cb bc 4a e4 57 5e b5 |wP/.....t..J.W^.|
00000020 93 16 42 15 03 03 00 1a 00 00 00 00 00 00 00 02 |..B.............|
00000030 ee 1b 6a 8a 33 31 f2 4b 64 f8 1d 0e a5 7d c4 43 |..j.31.Kd....}.C|
00000040 be 3e |.>|
Reference in New Issue Copy Permalink