kris/th5
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
2bcf6466b4
th5/testdata/Client-TLSv12-RenegotiateTwice

273 lines
20 KiB
Plaintext
Raw Normal View History

crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 1 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 01 00 95 01 00 00 91 03 03 00 00 00 00 00 |................|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
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
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 2c cc a8 |.............,..|
00000030 cc a9 c0 2f c0 2b c0 30 c0 2c c0 27 c0 13 c0 23 |.../.+.0.,.'...#|
00000040 c0 09 c0 14 c0 0a 00 9c 00 9d 00 3c 00 2f 00 35 |...........<./.5|
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000050 c0 12 00 0a 00 05 c0 11 c0 07 01 00 00 3c 00 05 |.............<..|
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
00000060 00 05 01 00 00 00 00 00 0a 00 0a 00 08 00 1d 00 |................|
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000070 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 12 00 |................|
00000080 10 04 01 04 03 05 01 05 03 06 01 06 03 02 01 02 |................|
00000090 03 ff 01 00 01 00 00 12 00 00 |..........|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 2 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 59 02 00 00 55 03 03 72 05 00 95 36 |....Y...U..r...6|
00000010 6c a5 d1 0f 06 bd 25 80 25 19 16 0d 70 56 8f c4 |l.....%.%...pV..|
00000020 b4 e9 17 be d2 06 09 b4 05 bc 2e 20 bc b9 5a 92 |........... ..Z.|
00000030 44 a5 91 7c 82 7e b6 c3 50 da cd f2 98 e1 26 14 |D..|.~..P.....&.|
00000040 d3 eb e2 98 c7 f6 6c 96 71 d3 7e b4 cc a8 00 00 |......l.q.~.....|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01: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: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
000002c0 ac 0c 00 00 a8 03 00 1d 20 f0 1b 05 7a 25 88 37 |........ ...z%.7|
000002d0 65 0d 93 e7 44 ff b4 bd 8d 9a eb ca 4f 31 c6 42 |e...D.......O1.B|
000002e0 f8 83 aa 1e 33 6c c8 3f 2a 04 01 00 80 0c 5b 0c |....3l.?*.....[.|
000002f0 92 86 55 5a 05 c9 f0 df 0a 1f 57 46 24 53 a6 77 |..UZ......WF$S.w|
00000300 f9 6b b0 a0 2e a3 64 f0 21 f1 93 10 de 9c 6f fb |.k....d.!.....o.|
00000310 68 8c f0 d4 f6 b4 81 f6 60 8a 64 ee af f6 ee 3c |h.......`.d....<|
00000320 d8 45 fc 3a 70 1d 89 c2 11 94 4e 9a 5c ee 67 64 |.E.:p.....N.\.gd|
00000330 24 91 2c 97 09 ba 1f 76 2d ca e4 a1 52 e9 d6 8a |$.,....v-...R...|
00000340 e5 21 42 66 80 95 72 61 6e d7 09 eb db 30 fc b7 |.!Bf..ran....0..|
00000350 8e d6 3a 91 97 14 09 33 15 9a 5d 45 a9 53 0b 3d |..:....3..]E.S.=|
00000360 49 3b ba 95 8c ae 96 06 e1 e9 4c 2f 72 16 03 03 |I;........L/r...|
crypto/tls: enable X25519 by default. Since this changes the offered curves in the ClientHello, all the test data needs to be updated too. Change-Id: I227934711104349c0f0eab11d854e5a2adcbc363 Reviewed-on: https://go-review.googlesource.com/30825 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-11 23:08:35 +01:00
00000370 00 04 0e 00 00 00 |......|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 3 (client to server)
crypto/tls: enable X25519 by default. Since this changes the offered curves in the ClientHello, all the test data needs to be updated too. Change-Id: I227934711104349c0f0eab11d854e5a2adcbc363 Reviewed-on: https://go-review.googlesource.com/30825 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-11 23:08:35 +01:00
00000000 16 03 03 00 25 10 00 00 21 20 2f e5 7d a3 47 cd |....%...! /.}.G.|
00000010 62 43 15 28 da ac 5f bb 29 07 30 ff f6 84 af c4 |bC.(.._.).0.....|
00000020 cf c2 ed 90 99 5f 58 cb 3b 74 14 03 03 00 01 01 |....._X.;t......|
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000030 16 03 03 00 20 f7 8a a0 59 29 4a b5 a1 1a d2 9c |.... ...Y)J.....|
00000040 d7 4f f7 eb 76 ed 9f d5 93 cb 30 dc dd a1 28 0a |.O..v.....0...(.|
00000050 82 3e fb 3b d0 |.>.;.|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 4 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 14 03 03 00 01 01 16 03 03 00 20 01 ce 8d 74 22 |.......... ...t"|
00000010 4a 7e 22 fe ab b4 ed 5e 05 27 3f e9 35 97 f4 ef |J~"....^.'?.5...|
00000020 c5 df 0c 7f d7 6a 10 94 a0 72 dc |.....j...r.|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 5 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 17 03 03 00 16 cc f5 66 f6 5e d6 b5 53 e6 d6 29 |.......f.^..S..)|
00000010 90 c6 dc b3 ad b5 43 ea 16 80 88 |......C....|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 6 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 14 0e 28 a6 a0 4a 78 90 fa d5 ed 0a |......(..Jx.....|
00000010 45 b8 21 75 18 de 93 16 12 |E.!u.....|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 7 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 b1 60 7a a2 91 30 f4 5b a4 5f 4c 38 |.....`z..0.[._L8|
00000010 5e 44 34 09 02 13 c3 1b 02 d3 64 e4 f3 c2 35 87 |^D4.......d...5.|
00000020 b2 4b 39 fd 89 10 12 42 97 b9 97 e5 67 82 0a 5c |.K9....B....g..\|
00000030 24 28 5a 0c be db d2 0b f7 ac b7 f4 9d c1 0f 0a |$(Z.............|
00000040 76 e4 6f 41 e2 31 e3 35 0b 39 71 a9 31 56 b0 41 |v.oA.1.5.9q.1V.A|
00000050 13 d6 0f 2c 10 e9 e7 bb 37 2a e9 b2 4d 8a f3 8a |...,....7*..M...|
00000060 5a ab 12 02 99 ba e4 45 b9 2d c6 be 45 35 37 6a |Z......E.-..E57j|
00000070 e5 24 be db 79 39 df 5e c8 a8 58 42 2d 40 00 96 |.$..y9.^..XB-@..|
00000080 89 8a 2e 45 32 61 3e 65 18 c1 8f bf 90 da 60 bd |...E2a>e......`.|
00000090 03 34 ad 93 ac aa 33 55 31 8c 41 fa d0 85 42 a8 |.4....3U1.A...B.|
000000a0 dd 69 2f fb e5 21 c6 64 39 42 8c af b6 1d 21 e2 |.i/..!.d9B....!.|
000000b0 47 ec 11 ed 4d 6d |G...Mm|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 8 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 81 1b 98 a8 9a 8f 4f c6 d0 1f b0 21 |..........O....!|
00000010 74 47 2a af 9f 6d a0 fb 4e 99 ed ad 05 99 5a 34 |tG*..m..N.....Z4|
00000020 ab 9c 4d c0 24 72 15 f4 6f ba 8f d2 43 33 d5 8b |..M.$r..o...C3..|
00000030 3a f6 10 cd d3 50 3e 8c b7 d6 03 b7 1c 28 d7 fb |:....P>......(..|
00000040 47 1c b9 a7 14 a4 6e 8e 06 65 d3 b8 8a 8c 73 ee |G.....n..e....s.|
00000050 36 63 24 bf 5a c8 0a 27 1f 93 a4 fc 50 c9 48 d0 |6c$.Z..'....P.H.|
00000060 43 27 63 6d c3 d9 ca bf 2c 03 c8 d1 e3 d1 94 43 |C'cm....,......C|
00000070 e0 12 87 b1 96 14 b4 7f ac 8a 85 50 5d f7 64 0e |...........P].d.|
00000080 05 cd 47 43 59 5e 16 03 03 02 69 90 f1 fe ba 32 |..GCY^....i....2|
00000090 b5 0d 2f 98 95 2f c1 95 9a 09 32 ab 9f a8 a8 bc |../../....2.....|
000000a0 2d f0 cf 7e 7f d0 f8 b9 0c e0 11 84 03 8e d3 27 |-..~...........'|
000000b0 c5 15 07 81 02 fa 64 7b eb 21 63 59 15 ba 9e 4e |......d{.!cY...N|
000000c0 6d 03 81 f4 d8 8b 4d f4 82 fd 62 1f 9f 28 64 80 |m.....M...b..(d.|
000000d0 5b af d3 fc fc 2e dd 6c b0 5c 28 5e 58 e7 01 07 |[......l.\(^X...|
000000e0 86 d1 40 35 f2 9c 2c 45 c0 2a 86 67 30 d4 d4 51 |..@5..,E.*.g0..Q|
000000f0 6c 18 31 bd 22 2e d0 6c ea d8 f4 9b 87 30 ea 09 |l.1."..l.....0..|
00000100 66 11 36 a3 ae f5 a7 91 a0 76 8e 77 c1 3d f7 3a |f.6......v.w.=.:|
00000110 88 29 b2 c4 2f 4e cd c6 d9 93 80 7f 9b 29 3a a4 |.)../N.......):.|
00000120 f5 63 77 7d 54 07 62 8c bc 23 c8 36 ea a8 e5 c4 |.cw}T.b..#.6....|
00000130 46 4b 59 dc 02 58 9d 21 00 47 39 29 60 9a 14 d8 |FKY..X.!.G9)`...|
00000140 ae 55 5c 03 fd 05 b7 66 30 de 81 87 9c 45 9f 52 |.U\....f0....E.R|
00000150 1e c5 2d d8 6a 7d d0 64 7b 0c 3a 47 b9 ff dd dd |..-.j}.d{.:G....|
00000160 60 a6 fa 69 f9 a0 43 a5 97 27 e8 fe 2d 99 94 01 |`..i..C..'..-...|
00000170 d7 52 c2 b2 ec 77 10 af ed 5e f6 82 d4 15 60 aa |.R...w...^....`.|
00000180 d3 cd 39 e5 a6 92 c9 f8 9e 63 e1 83 71 33 f2 dc |..9......c..q3..|
00000190 dd 7a eb de ac 91 46 06 ef 23 b2 6f 39 33 69 75 |.z....F..#.o93iu|
000001a0 43 d7 e5 e1 b0 5c 2f 0f 2d 39 d6 14 11 cd 6b a2 |C....\/.-9....k.|
000001b0 37 d2 32 0b b6 45 ad 2c b8 26 ef 43 3e 63 b0 1f |7.2..E.,.&.C>c..|
000001c0 a1 79 d2 c7 84 f9 7a 5f b2 c2 fd 4e 22 89 23 1d |.y....z_...N".#.|
000001d0 b7 4c 6c b5 b1 c1 19 a9 7c f7 23 bf 91 0e aa 8c |.Ll.....|.#.....|
000001e0 da 67 68 57 84 b9 68 5f 69 16 ad c7 32 86 98 81 |.ghW..h_i...2...|
000001f0 06 01 91 66 fd 5e e3 f5 63 4b e3 05 6d 41 f0 4e |...f.^..cK..mA.N|
00000200 f2 b1 70 26 de ed e5 83 87 d3 cf 5d 5c 7b d5 14 |..p&.......]\{..|
00000210 08 e9 e3 88 9a d0 9a e4 d6 40 44 1b 61 57 8f a3 |.........@D.aW..|
00000220 8a 52 5e 83 75 07 3d c2 16 00 3c a3 e9 61 cb 41 |.R^.u.=...<..a.A|
00000230 66 e7 54 7c e1 e5 7b 85 cb 0d f6 50 93 7d 85 c1 |f.T|..{....P.}..|
00000240 de 98 a8 8d 5a 0d 12 80 25 78 25 15 a3 0c 7a 7f |....Z...%x%...z.|
00000250 43 45 2e 0f e0 47 05 9f b2 2a 0d 9f 23 e3 0b 62 |CE...G...*..#..b|
00000260 33 91 d9 d8 7f f5 ac ed ef fd ea a5 f5 df 04 e8 |3...............|
00000270 6f 4a bd a2 bf aa fe 56 49 13 7a d3 58 2b ef ab |oJ.....VI.z.X+..|
00000280 ed f8 4b 6f 77 18 1e 37 59 2c 98 85 c4 59 f5 08 |..Kow..7Y,...Y..|
00000290 a6 03 f3 9b b0 79 24 cc 61 55 e3 b7 a7 f5 96 58 |.....y$.aU.....X|
000002a0 39 57 ec 40 33 a8 94 a2 c8 7f d4 5a f6 5e b0 be |9W.@3......Z.^..|
000002b0 89 b8 4d 45 73 ef 9f e9 cc d1 31 f8 46 97 82 be |..MEs.....1.F...|
000002c0 fa 44 de 62 36 47 6f 7b 5e 50 af b6 1b d2 0b 02 |.D.b6Go{^P......|
000002d0 17 df 6b c4 b5 ca 60 39 49 2e 86 d7 84 60 37 34 |..k...`9I....`74|
000002e0 65 43 0d f7 04 88 38 e4 5f 65 19 d0 62 8c 29 b6 |eC....8._e..b.).|
000002f0 2d d2 52 0f 16 03 03 00 bc 30 b3 f2 e1 bd 5e ec |-.R......0....^.|
00000300 c3 68 8a cc b4 4d e1 f1 76 e7 c1 47 0a c2 54 c1 |.h...M..v..G..T.|
00000310 9d d9 2d 72 1b 44 2d 3e 3d 22 5b 7d a1 c0 17 27 |..-r.D->="[}...'|
00000320 97 dd fe 9e a1 c5 5b ce 5f eb 9d 72 0e 14 ca b1 |......[._..r....|
00000330 61 f6 03 6e 84 d5 c4 53 91 ed 22 41 6e c9 84 91 |a..n...S.."An...|
00000340 59 a2 30 38 2a 29 b3 b8 9e 45 3a 1f 98 30 ce a4 |Y.08*)...E:..0..|
00000350 41 8a d9 ea e8 8d ee 43 cc 29 94 8c e5 86 cc 7b |A......C.).....{|
00000360 04 a7 31 1e 87 2b aa da 6c d0 4a a7 08 6e 31 2f |..1..+..l.J..n1/|
00000370 c3 95 06 3e 6d 9c 1b bb db 74 f5 a2 7e 6a 17 5f |...>m....t..~j._|
00000380 4c 2f f5 56 69 89 04 f7 17 41 85 ea 35 2f 59 db |L/.Vi....A..5/Y.|
00000390 d3 b9 f9 7a 6c 08 f8 f2 2d ba 04 ef 57 b5 d0 2f |...zl...-...W../|
000003a0 f3 3d 31 e6 c1 f8 26 9d 06 be 38 94 ba 8e ca 3f |.=1...&...8....?|
000003b0 4c 5b 70 c6 09 16 03 03 00 14 1e 86 bf c9 1e 7c |L[p............||
000003c0 08 0c 5a fb e4 92 8c f9 78 85 34 e3 56 86 |..Z.....x.4.V.|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 9 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 35 a7 bb 37 bb b1 b0 8e 12 72 8b a8 |....5..7.....r..|
00000010 c5 d4 cc 44 1c 4b 87 1f bc cb 39 35 60 fb 06 de |...D.K....95`...|
00000020 44 ac 0a c5 13 cb 15 1b ce 6b d8 45 28 d6 80 1b |D........k.E(...|
00000030 06 1f 32 4c 26 81 77 08 9c 23 14 03 03 00 11 c0 |..2L&.w..#......|
00000040 1b 3b 4d e8 9d ba d9 2c 50 10 03 b9 0c 57 83 60 |.;M....,P....W.`|
00000050 16 03 03 00 20 e0 d7 07 fe 04 89 25 3c b6 c0 8a |.... ......%<...|
00000060 33 14 6c 3e f4 48 5c 17 33 f8 f0 11 3a cb d8 17 |3.l>.H\.3...:...|
00000070 cd 42 be 22 68 |.B."h|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 10 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 14 03 03 00 11 05 69 30 af cd 8e 28 8b 04 3c de |......i0...(..<.|
00000010 39 2c cc 79 60 dc 16 03 03 00 20 64 e4 49 e1 a5 |9,.y`..... d.I..|
00000020 59 be ed d9 04 59 24 01 16 65 aa b9 22 7d 91 5f |Y....Y$..e.."}._|
00000030 e5 e4 db a7 67 a0 10 51 7e 3b 77 17 03 03 00 19 |....g..Q~;w.....|
00000040 70 cc 7d 13 21 aa ac d3 fb a7 ee cc f6 db 51 4b |p.}.!.........QK|
00000050 2d 2a e2 66 f4 ba 29 aa e1 16 03 03 00 14 e2 ba |-*.f..).........|
00000060 56 31 77 97 4a 4a a5 f0 05 28 d5 9f b7 3e 38 50 |V1w.JJ...(...>8P|
00000070 1f 1b |..|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 11 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 b1 86 78 3d 4f eb 03 b0 00 ca a5 94 |......x=O.......|
00000010 9d 70 04 ff 30 82 59 9c ea 95 44 02 f0 14 fa 3c |.p..0.Y...D....<|
00000020 aa af fa e8 17 3c ac 69 91 3d b6 23 85 85 7a be |.....<.i.=.#..z.|
00000030 11 9e 17 4e 32 79 de 3e 04 54 71 d0 ae 94 03 97 |...N2y.>.Tq.....|
00000040 d1 90 50 1f d5 8d d3 ff aa ce 0a fb 81 bd e9 11 |..P.............|
00000050 3f c2 c5 68 f9 e6 71 00 4f d9 ef cb c9 fd 0e 0d |?..h..q.O.......|
00000060 23 ce 04 f3 19 86 cb 4c a0 71 52 8e c2 90 a1 5b |#......L.qR....[|
00000070 e2 1e f4 e7 24 4c 9a b0 0c fc eb 70 d0 94 44 4e |....$L.....p..DN|
00000080 fc 5d 2e 16 2d 0f ff 61 20 3a 4d 19 cd 1c 22 d7 |.]..-..a :M...".|
00000090 d0 23 ff a9 a1 bf 79 7c 91 ba d8 15 47 9a a3 88 |.#....y|....G...|
000000a0 cb 06 f9 5d bd 8b c1 cb f6 16 ee 5d af 9c 7a 54 |...].......]..zT|
000000b0 0c af 31 ee 4a d0 |..1.J.|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 12 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 81 d3 34 51 a2 7a 93 5e f9 ef 8f f7 |......4Q.z.^....|
00000010 a3 be aa 40 2c 53 e4 5d 62 2e 19 4a bf f3 dc ce |...@,S.]b..J....|
00000020 da e8 49 8e 4d 0c 68 72 3f 79 74 59 e2 8d 0c 78 |..I.M.hr?ytY...x|
00000030 b7 13 05 0f 4f df 4f 01 71 40 38 f3 79 b2 33 51 |....O.O.q@8.y.3Q|
00000040 f5 25 73 11 9a 30 b9 3c 5f d2 8b 32 71 6f 0d ef |.%s..0.<_..2qo..|
00000050 6a 42 da f6 c5 1d a4 90 ad e4 08 60 39 55 19 97 |jB.........`9U..|
00000060 a6 2c 5e 2c e3 96 ba 0c 54 50 bc b9 0f 3c 53 bd |.,^,....TP...<S.|
00000070 e7 63 5f 13 e8 ce 35 34 c4 d0 1b da 1a fd 5a 52 |.c_...54......ZR|
00000080 6e 5f 43 e8 d0 22 16 03 03 02 69 42 85 86 7e 3e |n_C.."....iB..~>|
00000090 92 4c 49 8e 40 86 28 53 c2 aa 43 2f 49 00 fa ee |.LI.@.(S..C/I...|
000000a0 48 0d 01 ec 94 e0 37 1a 05 97 6e ec a4 71 1e aa |H.....7...n..q..|
000000b0 50 5a 49 e9 cc 21 b0 d6 ab 38 4a 30 a7 84 ec 7d |PZI..!...8J0...}|
000000c0 38 34 91 63 3f 1a 59 eb 22 91 9b 23 23 b1 3f 7d |84.c?.Y."..##.?}|
000000d0 0c 70 23 71 0d 50 09 80 21 56 fe f2 c8 14 3d 19 |.p#q.P..!V....=.|
000000e0 91 04 a8 10 b8 2b b0 cb ff b7 6f 53 62 86 61 22 |.....+....oSb.a"|
000000f0 4e 6d 67 12 d3 18 ac 90 ab 62 42 0f cb 08 47 73 |Nmg......bB...Gs|
00000100 42 97 01 37 67 13 99 49 d6 f1 7f 0d 8a 83 6b 01 |B..7g..I......k.|
00000110 00 76 d9 3a bd 0c 7a 64 c7 49 9e 06 d6 6c 04 48 |.v.:..zd.I...l.H|
00000120 07 cc 96 03 f1 fe 38 76 b2 c3 97 ae 37 57 25 5e |......8v....7W%^|
00000130 54 18 07 b5 e2 6a ca fe 07 01 d7 9c a6 5c 95 df |T....j.......\..|
00000140 02 66 88 53 51 23 ba f2 0f b2 66 b2 df 14 61 28 |.f.SQ#....f...a(|
00000150 50 cd 7a 56 47 79 33 6e 75 0d b6 0d 66 69 eb c6 |P.zVGy3nu...fi..|
00000160 07 31 97 10 46 ec a7 59 b6 02 0b ab 40 d3 ce 88 |.1..F..Y....@...|
00000170 62 aa ab ce 1b 73 9a 62 d7 8c 7c ca 40 a0 bb 1d |b....s.b..|.@...|
00000180 ff f4 85 54 fe ae 83 61 10 ec 38 64 ab 60 36 e1 |...T...a..8d.`6.|
00000190 88 92 ba 74 e0 68 30 0b 61 7b da eb 3b d3 6b ed |...t.h0.a{..;.k.|
000001a0 fc eb 3f 98 dd 30 f1 28 bd e0 07 6b 77 53 29 02 |..?..0.(...kwS).|
000001b0 d7 18 69 2b ac 0b 4c 38 3b 35 e0 15 91 c4 34 42 |..i+..L8;5....4B|
000001c0 74 67 c0 2a 2b df 2f 70 13 7c 99 ba f6 cc e4 f4 |tg.*+./p.|......|
000001d0 bd 3c 7f cd 08 b4 3c 05 da bf c7 01 61 93 21 d6 |.<....<.....a.!.|
000001e0 1b ca b0 35 d1 89 f3 08 67 85 93 c9 da 6f cf a4 |...5....g....o..|
000001f0 ad 1e a8 70 71 4a ac 56 73 25 8f 9c 25 13 5f 2c |...pqJ.Vs%..%._,|
00000200 20 bc f2 56 af a0 03 38 43 9c 83 79 33 ea 81 8c | ..V...8C..y3...|
00000210 d8 5d c0 50 d4 44 cd df 55 e7 4e fc f6 67 55 92 |.].P.D..U.N..gU.|
00000220 39 a2 ec 25 3e 1f 7e 14 28 3b d8 84 f5 83 66 c4 |9..%>.~.(;....f.|
00000230 e1 d7 c3 63 51 d7 4e e4 72 1a da 76 ce 91 6b 56 |...cQ.N.r..v..kV|
00000240 0a 68 42 63 7e 57 31 98 cc d0 e0 3c 7c 7e 81 be |.hBc~W1....<|~..|
00000250 be 37 8d cd e7 da df 91 55 8c 71 e3 67 ec bf 6e |.7......U.q.g..n|
00000260 4c 5a a6 b6 2b 2c 31 0b da 19 66 26 f1 92 c2 7e |LZ..+,1...f&...~|
00000270 fd 12 50 6f 04 ee 83 85 bb d0 f1 77 12 10 c9 e7 |..Po.......w....|
00000280 4a 2f 17 96 55 0f 7e 1e fd 6d 18 13 74 a8 54 38 |J/..U.~..m..t.T8|
00000290 a5 ef bb 70 c9 71 07 09 c5 a3 26 f9 73 1f d0 e8 |...p.q....&.s...|
000002a0 a2 23 a1 46 46 1b f6 b1 e7 ac 22 22 ee df b9 5b |.#.FF.....""...[|
000002b0 38 02 c6 59 33 e5 12 0b 9f 49 e2 d7 de 77 30 ac |8..Y3....I...w0.|
000002c0 1e a0 ee 20 9f 1b 1d e0 8c fd d4 02 09 7b 1b d6 |... .........{..|
000002d0 c7 41 de 67 90 71 5f 06 ea ac 18 e7 5f 11 67 c3 |.A.g.q_....._.g.|
000002e0 d6 5d c1 37 0a 67 5b f7 93 93 eb 29 70 e3 cb 7f |.].7.g[....)p...|
000002f0 2c c9 bb 6b 16 03 03 00 bc ab 60 8e 1d 2e e1 42 |,..k......`....B|
00000300 81 91 89 69 78 5d 99 9c e7 1b d1 ac 36 39 c5 32 |...ix]......69.2|
00000310 58 4e 4c 48 b9 15 eb 21 b6 24 df 8e b2 16 f0 95 |XNLH...!.$......|
00000320 cd 57 8e 14 3b 5b a2 f9 7a 10 0d fa 57 52 70 f9 |.W..;[..z...WRp.|
00000330 b8 a9 b0 fd 22 0a 51 ef dd ba 3c fb 68 00 05 45 |....".Q...<.h..E|
00000340 d6 c3 1f 56 91 b4 06 80 a4 28 84 a5 bb 11 72 af |...V.....(....r.|
00000350 b7 f6 14 58 76 b7 76 ad 1b e6 65 57 af f7 46 a2 |...Xv.v...eW..F.|
00000360 bc 60 12 6d 30 d3 cf 26 62 9d 9f 19 b0 28 96 d2 |.`.m0..&b....(..|
00000370 e2 43 de 64 90 49 1d 29 2c bb 59 4c c7 d1 9b be |.C.d.I.),.YL....|
00000380 c3 e9 ae 8e 74 36 1b 03 00 43 65 56 30 3b e6 8b |....t6...CeV0;..|
00000390 4c d9 98 a2 f7 2b 06 77 4b 9c 53 c4 7f 24 88 75 |L....+.wK.S..$.u|
000003a0 30 91 66 fa ba 9c 7f 84 ab c1 51 21 1c d3 2e 93 |0.f.......Q!....|
000003b0 f9 4d db 6e 08 16 03 03 00 14 ed f9 cc ef c4 2b |.M.n...........+|
000003c0 fd 97 fe 35 ad 33 01 46 9b 52 d7 e9 49 c2 |...5.3.F.R..I.|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 13 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 16 03 03 00 35 77 aa f6 e5 92 a0 83 9f b7 0e e3 |....5w..........|
00000010 d2 ae 3e 72 3d 67 59 0a 67 04 10 3c 44 9c 6f 8e |..>r=gY.g..<D.o.|
00000020 ea 0c 79 ed da e5 b8 51 79 45 b2 9a 23 fd b5 5a |..y....QyE..#..Z|
00000030 40 3d 84 90 b1 72 45 36 98 80 14 03 03 00 11 69 |@=...rE6.......i|
00000040 3d 4e 7a a6 d0 a3 08 5f 5c 11 12 a6 78 7f ec c3 |=Nz...._\...x...|
00000050 16 03 03 00 20 6f 61 99 d2 0f 9b 70 f4 13 0a 15 |.... oa....p....|
00000060 66 d9 05 22 40 db 66 cb 75 16 de c3 91 d7 71 21 |f.."@.f.u.....q!|
00000070 5d 9c 4c 5a 87 |].LZ.|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 14 (server to client)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 14 03 03 00 11 d8 e7 6c 77 f7 f2 11 7c 9b 9b 4e |.......lw...|..N|
00000010 3a a6 e5 d6 2b 47 16 03 03 00 20 b6 28 ee e6 7b |:...+G.... .(..{|
00000020 27 b1 3d c7 b4 d0 ba aa 65 b8 44 f1 8b 1e c2 1a |'.=.....e.D.....|
00000030 1c 63 4d d6 d8 f6 08 e2 9b bb 34 17 03 03 00 19 |.cM.......4.....|
00000040 ed 7c 4e b7 db f6 88 4f 68 85 e9 ff a3 48 96 39 |.|N....Oh....H.9|
00000050 5d 39 69 5b 92 8f 43 c5 ba |]9i[..C..|
crypto/tls: allow renegotiation to be handled by a client. This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-04-26 18:45:35 +01:00
>>> Flow 15 (client to server)
crypto/tls: advertise support for SHA-512 signatures in 1.2 This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2017-10-31 23:43:05 +00:00
00000000 15 03 03 00 12 45 0b 80 2d f1 c6 08 39 3c 70 07 |.....E..-...9<p.|
00000010 1d d1 b6 33 01 79 ef |...3.y.|
Reference in New Issue Copy Permalink