kris/th5
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
cde0e97e4c
th5/testdata/Client-TLSv12-RenegotiateOnce

247 lines
18 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)
00000000 16 03 01 00 85 01 00 00 81 03 03 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 22 c0 2f |............."./|
00000030 c0 2b c0 30 c0 2c c0 11 c0 07 c0 13 c0 09 c0 14 |.+.0.,..........|
00000040 c0 0a 00 9c 00 9d 00 05 00 2f 00 35 c0 12 00 0a |........./.5....|
00000050 01 00 00 36 00 05 00 05 01 00 00 00 00 00 0a 00 |...6............|
00000060 08 00 06 00 17 00 18 00 19 00 0b 00 02 01 00 00 |................|
00000070 0d 00 0e 00 0c 04 01 04 03 05 01 05 03 02 01 02 |................|
00000080 03 ff 01 00 01 00 00 12 00 00 |..........|
>>> Flow 2 (server to client)
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 00 59 02 00 00 55 03 03 b1 2d bf 39 08 |....Y...U...-.9.|
00000010 8f b0 b4 b1 11 41 7d 31 11 94 b1 11 39 8a b0 65 |.....A}1....9..e|
00000020 8c 7f 15 5d 55 4f 17 09 72 73 3b 20 90 89 57 a3 |...]UO..rs; ..W.|
00000030 ee 59 22 41 14 89 62 ff 9c 58 0a 28 ec f8 03 c6 |.Y"A..b..X.(....|
00000040 ce 82 da 2f fb 09 e1 1a 85 86 3f b6 c0 2f 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
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 |.=.`.\!.;.......|
000002c0 cd 0c 00 00 c9 03 00 17 41 04 4d ee 13 e9 3f 0c |........A.M...?.|
000002d0 e8 d2 d7 73 ee 01 96 4b 18 b0 22 8b f3 ec a2 40 |...s...K.."....@|
000002e0 6c 01 d1 64 a9 94 80 13 89 f8 12 54 63 ac 51 e2 |l..d.......Tc.Q.|
000002f0 93 3a 1a 72 a0 17 1c c3 df a6 d0 ee 86 c9 b4 02 |.:.r............|
00000300 ee f4 cc 8e f0 ca 6a 18 26 b2 04 01 00 80 3c 77 |......j.&.....<w|
00000310 7f 22 0a 17 16 ad fa 41 ee af 44 be 2b b2 f5 c1 |.".....A..D.+...|
00000320 2c 55 08 c4 48 30 e9 a2 c9 b7 39 a3 6f 91 6d bf |,U..H0....9.o.m.|
00000330 7e ff 1b be 6a 16 97 b5 57 12 cd 7f 6f c7 64 18 |~...j...W...o.d.|
00000340 07 f9 66 81 d5 21 46 04 7b 0e 23 6c d8 48 25 da |..f..!F.{.#l.H%.|
00000350 64 e8 7b 4d db 75 41 97 b6 ae 6d d8 8c ad 43 38 |d.{M.uA...m...C8|
00000360 6d fd df 09 7e 3a 91 67 e8 20 f0 fb cc 55 05 47 |m...~:.g. ...U.G|
00000370 76 e9 ad 35 bd 1e a6 ac 8f 76 24 17 07 4a b3 46 |v..5.....v$..J.F|
00000380 b9 06 51 ba c2 e1 19 f7 60 e8 a2 37 7f 38 16 03 |..Q.....`..7.8..|
00000390 03 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)
00000000 16 03 03 00 46 10 00 00 42 41 04 1e 18 37 ef 0d |....F...BA...7..|
00000010 19 51 88 35 75 71 b5 e5 54 5b 12 2e 8f 09 67 fd |.Q.5uq..T[....g.|
00000020 a7 24 20 3e b2 56 1c ce 97 28 5e f8 2b 2d 4f 9e |.$ >.V...(^.+-O.|
00000030 f1 07 9f 6c 4b 5b 83 56 e2 32 42 e9 58 b6 d7 49 |...lK[.V.2B.X..I|
00000040 a6 b5 68 1a 41 03 56 6b dc 5a 89 14 03 03 00 01 |..h.A.Vk.Z......|
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
00000050 01 16 03 03 00 28 00 00 00 00 00 00 00 00 5d 8e |.....(........].|
00000060 8b 30 57 0c 31 ba 2e 8c 64 08 cb c8 71 1f 54 5e |.0W.1...d...q.T^|
00000070 76 2c 2f 47 b7 c7 59 c3 6b 38 54 57 f5 94 |v,/G..Y.k8TW..|
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/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 14 03 03 00 01 01 16 03 03 00 28 9d 6f 70 fb 5a |..........(.op.Z|
00000010 30 03 85 32 65 6a 5c f6 31 ec ec b7 55 c3 ce ca |0..2ej\.1...U...|
00000020 5f de e8 88 41 8b b7 fe 70 5f a6 26 9c c8 05 3b |_...A...p_.&...;|
00000030 12 1c c9 |...|
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/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 17 03 03 00 1e 00 00 00 00 00 00 00 01 9f f3 ae |................|
00000010 52 28 f7 2d 97 66 99 5a 88 28 57 38 e8 cb fa 8a |R(.-.f.Z.(W8....|
00000020 10 a1 1d |...|
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/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 00 1c 9d 6f 70 fb 5a 30 03 86 91 c2 89 |......op.Z0.....|
00000010 e1 83 c8 97 d1 78 3a 89 06 4e 84 72 19 37 6e f7 |.....x:..N.r.7n.|
00000020 3d |=|
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/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 00 a9 00 00 00 00 00 00 00 02 3b 3a be |.............;:.|
00000010 88 d7 e7 0b d7 b4 7e c2 da 07 75 b9 0f 20 97 38 |......~...u.. .8|
00000020 5d d1 d8 9a 33 25 4c 1a 10 f8 28 c4 d1 b0 bc f4 |]...3%L...(.....|
00000030 b2 c4 4d d2 0e f6 8c ea 52 20 e0 09 10 59 a4 bc |..M.....R ...Y..|
00000040 f8 db a6 eb e5 bd 40 c0 b8 fb 52 b1 20 29 b1 06 |......@...R. )..|
00000050 8f 2b 00 1f ef 29 33 c9 55 45 00 ec 24 37 d1 0e |.+...)3.UE..$7..|
00000060 da e9 32 8f b2 7a 2b 2a a5 ec 2d c9 84 2a 8e fa |..2..z+*..-..*..|
00000070 ee 3b 84 3e c0 04 f9 f5 ea 64 17 ad 14 4d 40 1a |.;.>.....d...M@.|
00000080 df cf 02 bd f8 b1 d9 91 89 14 d7 12 3c b6 29 d1 |............<.).|
00000090 9c 7a 5c 40 d0 b3 37 ab 0f ce 63 b6 c8 ef f3 51 |.z\@..7...c....Q|
000000a0 0c 9b 42 3b 78 67 1e a8 f6 c6 ba 9f 0f af |..B;xg........|
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/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 00 89 9d 6f 70 fb 5a 30 03 87 a9 75 2a |......op.Z0...u*|
00000010 3d 50 4f 91 c7 13 b7 37 80 ce 5d f7 5d e6 aa ca |=PO....7..].]...|
00000020 fc f3 81 ef 96 0e 92 dc 07 37 92 c8 13 4d 74 5d |.........7...Mt]|
00000030 54 e5 c8 53 8e 06 75 03 71 fa 95 87 67 f7 29 a5 |T..S..u.q...g.).|
00000040 58 69 b6 9f 9c b3 16 bf 89 a1 68 e9 36 e7 51 80 |Xi........h.6.Q.|
00000050 8d 48 5d cd 00 7a 84 8e ca 74 39 30 64 1b 46 41 |.H]..z...t90d.FA|
00000060 a5 ae c7 e7 dd 64 46 8f a9 4e 33 86 ea 8a 1c 88 |.....dF..N3.....|
00000070 d3 98 38 01 c3 a2 8b 29 c8 44 f3 41 6a fd ff 5a |..8....).D.Aj..Z|
00000080 41 70 21 b0 c1 92 be be e0 53 0f 82 10 20 16 03 |Ap!......S... ..|
00000090 03 02 71 9d 6f 70 fb 5a 30 03 88 78 ad b5 80 aa |..q.op.Z0..x....|
000000a0 65 5d 33 f4 2c 82 16 ce e2 12 13 b8 42 6c 9a fc |e]3.,.......Bl..|
000000b0 56 44 e7 d9 5e 15 04 7c 6b 03 a1 00 50 6b 4e e6 |VD..^..|k...PkN.|
000000c0 e7 1a 68 5b 3d cc 2e d0 fc 41 3f ee 62 5c 30 6d |..h[=....A?.b\0m|
000000d0 92 db 24 f3 28 ed fe 59 11 2a 98 58 d7 5d b8 9c |..$.(..Y.*.X.]..|
000000e0 c7 14 ac 82 17 15 22 ff 5f 5e fb dc 66 00 8e 59 |......"._^..f..Y|
000000f0 3e 40 32 f4 e2 e9 20 96 be 48 3e 5b e0 bf e0 d4 |>@2... ..H>[....|
00000100 f2 bf d8 73 65 6b 2b a5 a7 cd 30 d8 76 ab f7 f7 |...sek+...0.v...|
00000110 5d 4d 68 75 a3 db 2a 75 d2 8f 15 b1 d6 8b 63 d4 |]Mhu..*u......c.|
00000120 ed d3 43 9f 1e 72 ff cb 14 e1 84 b2 a2 e0 6b 97 |..C..r........k.|
00000130 5b 59 44 24 72 87 4f f6 3c d0 0a ca 5c 93 50 6b |[YD$r.O.<...\.Pk|
00000140 dd 30 42 c5 e6 f6 5f 23 5b 0f 56 16 c3 a5 a6 61 |.0B..._#[.V....a|
00000150 72 f4 35 21 09 85 7b 52 51 81 ad aa cf 09 2a db |r.5!..{RQ.....*.|
00000160 aa 02 eb 86 49 79 7e da 02 96 4b 82 87 4b 84 54 |....Iy~...K..K.T|
00000170 d2 6e a6 38 f3 2a e8 0e e8 86 18 48 b9 ca 0f 40 |.n.8.*.....H...@|
00000180 83 54 a4 e0 d7 63 27 21 e3 b3 f8 dc 19 18 7b 1c |.T...c'!......{.|
00000190 0a c0 76 f0 c9 fa 0f 85 e0 7e a9 81 a4 a8 72 70 |..v......~....rp|
000001a0 31 8a 8e 7b 27 36 e6 9e 9a 1a 28 9e 21 d2 28 d4 |1..{'6....(.!.(.|
000001b0 80 c2 cf ba 7d 02 e8 8b c5 ce f5 68 21 d7 7a 88 |....}......h!.z.|
000001c0 20 d3 be ea 90 82 cb c5 63 60 3d d7 75 30 48 a7 | .......c`=.u0H.|
000001d0 dc 9b c6 39 78 48 b5 13 41 6d 7c 4a 87 06 1a 95 |...9xH..Am|J....|
000001e0 3c e0 63 9c 9b 36 5c 5a c0 8e af 74 11 81 ae cf |<.c..6\Z...t....|
000001f0 e5 8a 9a 2f 51 e3 70 fb 32 e2 6c 1b 5c 0c 25 e6 |.../Q.p.2.l.\.%.|
00000200 87 50 6a 94 cc 16 53 a1 16 13 72 3d 8b ea 8d 34 |.Pj...S...r=...4|
00000210 72 17 c2 16 cd d4 78 de 6c 03 06 4c b5 88 86 00 |r.....x.l..L....|
00000220 85 f7 37 77 ff 8f 2e 11 12 87 b6 c0 86 c1 9c 7c |..7w...........||
00000230 a6 79 af a2 c7 9f e3 54 3d 62 c3 76 2b 8c 36 7a |.y.....T=b.v+.6z|
00000240 92 33 d7 ff d5 3e b0 5d 4d 75 a0 ac 73 f5 67 79 |.3...>.]Mu..s.gy|
00000250 f1 86 06 cb 82 c3 e1 46 95 62 2b 5d 7c 9e b4 17 |.......F.b+]|...|
00000260 92 7a a5 5b 49 f8 b4 26 e7 64 45 62 0c a6 a4 48 |.z.[I..&.dEb...H|
00000270 6d 67 04 44 96 bd fa 23 96 8b 25 3c e7 cf 48 d7 |mg.D...#..%<..H.|
00000280 c5 24 4e fe 3e 20 0e 72 dd a4 2c 6d 16 cb d2 47 |.$N.> .r..,m...G|
00000290 be 54 6b 68 44 7b cd d4 74 b6 bc 4d e2 10 c0 2b |.TkhD{..t..M...+|
000002a0 30 69 84 c4 25 29 eb f9 4e cd 7b d7 72 ad d9 f2 |0i..%)..N.{.r...|
000002b0 10 47 16 fe c8 0d 16 a1 08 93 d7 33 a6 24 bd cf |.G.........3.$..|
000002c0 80 cf 9f 50 68 fb c7 e9 88 8d 23 c6 b6 37 3b e7 |...Ph.....#..7;.|
000002d0 a3 c3 92 43 5d 04 6c 2e 55 3c 99 53 b1 4c 1b d8 |...C].l.U<.S.L..|
000002e0 18 ab 1f 19 b9 18 c6 59 b0 bd b7 b8 37 6d 8c 2c |.......Y....7m.,|
000002f0 0a 25 8a 32 99 84 03 ca 8c 77 a6 bb 39 28 3a c0 |.%.2.....w..9(:.|
00000300 83 a8 73 42 16 03 03 00 e5 9d 6f 70 fb 5a 30 03 |..sB......op.Z0.|
00000310 89 37 6f a7 81 31 d2 16 86 2b 48 dc 9c 21 0a 02 |.7o..1...+H..!..|
00000320 29 47 ba 57 5f 22 fd 90 86 c1 f0 70 68 1a 37 3b |)G.W_".....ph.7;|
00000330 c0 70 28 b8 10 3d 78 e8 58 6f 09 ce aa bc 2a 51 |.p(..=x.Xo....*Q|
00000340 d6 70 9b fe f4 18 4d bd 5f ed ff bd fc dd 9e 30 |.p....M._......0|
00000350 21 8a 49 bf ea 16 8e 42 1e da b1 8a a3 86 30 14 |!.I....B......0.|
00000360 14 f8 32 0e 5d dc f3 cf 25 cb 1b f1 a1 42 4b 96 |..2.]...%....BK.|
00000370 ca 8f 91 3a 0a 85 14 5f 39 f4 8d 4d 8d 15 40 04 |...:..._9..M..@.|
00000380 0a 9b 23 e3 be 40 8d 2c a8 8a 29 49 ab be 4f 38 |..#..@.,..)I..O8|
00000390 a3 8f bd bc 76 85 4e 5c 06 4c 5d 31 67 15 7d 7c |....v.N\.L]1g.}||
000003a0 66 c5 7c 90 97 90 fa a9 fe 4f fd 04 ba 10 f3 8e |f.|......O......|
000003b0 0b ff 22 fc 26 56 ac 49 79 e1 24 9a 62 59 d7 d8 |..".&V.Iy.$.bY..|
000003c0 25 d7 74 7c 84 dd 4f 35 44 19 ba 2e ba 1f c1 db |%.t|..O5D.......|
000003d0 53 f2 d3 3a f6 d4 bb a4 96 9a 67 fd d6 bc 3b 2c |S..:......g...;,|
000003e0 19 40 fe 2e 15 20 16 69 da f4 e5 c9 f3 3c 16 03 |.@... .i.....<..|
000003f0 03 00 46 9d 6f 70 fb 5a 30 03 8a 9e 8f 94 1e e4 |..F.op.Z0.......|
00000400 80 58 f2 84 8b 45 38 41 ab 31 b1 1f b1 bc 4b 3c |.X...E8A.1....K<|
00000410 ec a1 ec f7 4b 7c 3c 0d 93 80 94 92 90 3a 11 e8 |....K|<......:..|
00000420 7b e9 0f 3b c3 a4 2d c6 2e 09 71 9e 4c ea be 4b |{..;..-...q.L..K|
00000430 61 2f bd 55 58 47 f3 89 57 |a/.UXG..W|
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/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 02 71 00 00 00 00 00 00 00 03 da 01 11 |....q...........|
00000010 30 c8 d4 1d 30 60 0e cf 6d bc db cb 2b f1 c9 5c |0...0`..m...+..\|
00000020 9b 37 d3 f0 3c 50 4d d3 90 99 e1 6c 16 9f 52 07 |.7..<PM....l..R.|
00000030 ed 0f fa f4 33 cb 5f 53 4f d7 32 36 45 c0 62 db |....3._SO.26E.b.|
00000040 d4 0b 49 c4 b9 5f 19 8c 81 d2 1b ee b0 ec 17 22 |..I.._........."|
00000050 aa 96 ae 82 82 64 c1 77 5a 32 cf 93 04 ed 09 51 |.....d.wZ2.....Q|
00000060 fe e4 0c 4b 1a 6d 3f ec 67 3b ff ec 3d 67 60 03 |...K.m?.g;..=g`.|
00000070 91 81 87 f0 40 fd 6e d4 cc 28 1d a9 d8 29 fb 9d |....@.n..(...)..|
00000080 a5 f8 f4 fc 74 f4 c1 02 60 96 b6 f4 1c 7d b5 38 |....t...`....}.8|
00000090 be de 9a 95 d0 c5 94 5c 80 c4 ed 3d b1 d9 06 50 |.......\...=...P|
000000a0 d7 22 63 dd 2e dd ed 54 ca 87 23 20 83 a6 29 e0 |."c....T..# ..).|
000000b0 c0 1a a3 5f f9 99 8f 22 4b 29 7d 7b 50 96 a9 1e |..._..."K)}{P...|
000000c0 27 f7 f2 64 b2 22 6a 3e 77 a8 92 1d f7 6b 90 9c |'..d."j>w....k..|
000000d0 bd bd ac 90 c6 a7 78 e4 0a 42 36 23 45 cb 70 04 |......x..B6#E.p.|
000000e0 55 8c f7 83 cc fc 31 57 dd 46 a1 f3 08 d3 f1 6e |U.....1W.F.....n|
000000f0 e1 6a 8e 52 e4 ca ae 4c 3a 25 28 66 8b eb b6 c7 |.j.R...L:%(f....|
00000100 ce 51 f9 bc f0 40 ac 86 b6 15 35 c3 2b 14 fd a7 |.Q...@....5.+...|
00000110 94 9b 47 00 bb e1 90 63 b1 a9 84 b3 0e b8 e8 59 |..G....c.......Y|
00000120 b2 9f 84 c9 cc 48 46 b0 1c e9 37 2b cd b4 4f 9d |.....HF...7+..O.|
00000130 17 0a 96 16 53 54 1d 88 22 81 e9 bd 38 5d d1 79 |....ST.."...8].y|
00000140 a2 86 7d 95 cd 70 e4 07 d4 83 a5 5c 7d a0 fe 83 |..}..p.....\}...|
00000150 93 02 50 17 f1 81 01 e0 a4 84 76 09 49 2d 56 fb |..P.......v.I-V.|
00000160 76 08 f0 61 da 34 77 d8 d2 7e ef 2f 1b c9 8c 9b |v..a.4w..~./....|
00000170 bb df 12 d4 5b b1 2a 59 81 bc 07 dd e9 46 a8 8b |....[.*Y.....F..|
00000180 0f fb 69 3d fd 39 db 8b 59 b7 c2 47 9f 51 67 a9 |..i=.9..Y..G.Qg.|
00000190 d8 43 5c b0 5e 5b 10 12 09 09 f0 5b 50 eb 69 f5 |.C\.^[.....[P.i.|
000001a0 71 c8 34 20 d5 83 17 a5 0f f7 e0 63 c0 c1 84 47 |q.4 .......c...G|
000001b0 c1 20 4c 64 38 f4 60 aa 48 30 15 09 f4 b2 2e 94 |. Ld8.`.H0......|
000001c0 e6 d4 a1 d8 fe 79 4e a7 6f b4 3f 33 0f a1 20 ed |.....yN.o.?3.. .|
000001d0 5d 01 35 b5 1f 85 1f 55 c8 10 15 67 b8 a9 03 4a |].5....U...g...J|
000001e0 ef 98 3f e3 dd 91 ed b8 89 61 28 26 f4 63 e0 b0 |..?......a(&.c..|
000001f0 b6 ee 65 8a c9 c2 45 6e 4a 14 57 6f d5 2e 2c f9 |..e...EnJ.Wo..,.|
00000200 7b 85 f4 da e6 8f c5 09 d3 bf 1d f2 a9 93 97 b8 |{...............|
00000210 1c 65 5e 7e dc 4b 78 28 24 76 17 6a 6c fd dd 6c |.e^~.Kx($v.jl..l|
00000220 8c 36 6e 44 1f 59 cb da 68 89 2c 38 1a 2c b6 2f |.6nD.Y..h.,8.,./|
00000230 81 00 76 cf 98 20 00 b6 fa 47 ce f0 f9 1c d8 7a |..v.. ...G.....z|
00000240 62 81 79 0d db 7c 2c f6 ba 31 c9 88 b6 b7 f8 e7 |b.y..|,..1......|
00000250 55 77 63 87 56 48 6f 68 af ed fc 0b f2 11 2f c6 |Uwc.VHoh....../.|
00000260 d3 cc 6a c5 47 fc f8 c4 8c 54 db 72 93 1b 49 cd |..j.G....T.r..I.|
00000270 a5 cd 6f 10 e2 55 16 03 03 00 5e 00 00 00 00 00 |..o..U....^.....|
00000280 00 00 04 d5 b2 77 db 72 da c0 84 fc 04 7a 8e 4e |.....w.r.....z.N|
00000290 2e 25 b0 b8 31 58 e3 dc 07 a6 ea dc 46 08 f9 15 |.%..1X......F...|
000002a0 1d ab 0f fe 80 c7 3b 78 4b e5 fa 9a 16 c2 30 7c |......;xK.....0||
000002b0 74 75 54 93 96 55 e5 60 f8 bf 43 b4 3d 79 13 b1 |tuT..U.`..C.=y..|
000002c0 bf 33 07 87 3f 3d aa 1e e9 e5 3b 28 7e 15 84 20 |.3..?=....;(~.. |
000002d0 08 dc ef df 8d 7d 68 97 8b 16 03 03 00 a0 00 00 |.....}h.........|
000002e0 00 00 00 00 00 05 f7 40 01 b1 ab ef 0d 91 8d 03 |.......@........|
000002f0 cb 8e 85 f0 2e 28 bc 63 98 7c 75 b2 08 16 d3 42 |.....(.c.|u....B|
00000300 6b b4 53 90 77 45 7a e9 ad 6f cb ab 39 55 54 f6 |k.S.wEz..o..9UT.|
00000310 f0 14 3a 42 a5 30 e0 5f 7e 7a 83 b6 ec 7d 40 a7 |..:B.0._~z...}@.|
00000320 77 c2 68 de 9c 92 64 b7 03 3e 5e 74 72 cf e5 59 |w.h...d..>^tr..Y|
00000330 17 5c 6c 43 b6 e8 12 cb 8a 1c e2 09 30 43 a0 c4 |.\lC........0C..|
00000340 bf 4a 14 90 51 fb 2c c9 f7 9a 50 14 1c 61 7d 83 |.J..Q.,...P..a}.|
00000350 6d 2e 61 8e ca 4a c3 92 e3 98 c1 57 b3 77 ab ab |m.a..J.....W.w..|
00000360 36 33 a2 2a bc eb 2b 04 45 92 b4 2f ff 19 68 6a |63.*..+.E../..hj|
00000370 13 a0 79 47 3c 8e db b0 dd 63 1b 80 39 a0 14 03 |..yG<....c..9...|
00000380 03 00 19 00 00 00 00 00 00 00 06 41 5a 21 fa 4b |...........AZ!.K|
00000390 e3 b0 b8 55 3e 97 e6 70 8e 7e ea 05 16 03 03 00 |...U>..p.~......|
000003a0 28 00 00 00 00 00 00 00 00 4d 4a 88 64 f5 5e 9e |(........MJ.d.^.|
000003b0 2f 8c 5a fe 95 b2 8f 8c 3f 7d b2 03 6a b1 39 72 |/.Z.....?}..j.9r|
000003c0 f8 8f 6c 0a 07 c1 6c 47 f8 |..l...lG.|
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/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 14 03 03 00 19 9d 6f 70 fb 5a 30 03 8b 92 a9 3a |......op.Z0....:|
00000010 32 29 a8 40 23 2e 13 b3 11 24 eb 5d 9d 8b 16 03 |2).@#....$.]....|
00000020 03 00 28 30 c2 c5 18 43 17 7f a8 ab ac f3 22 a9 |..(0...C......".|
00000030 79 0d d1 b6 3d e7 c8 aa c8 73 3e 31 0a 67 2a dd |y...=....s>1.g*.|
00000040 38 5a 8d 74 ae 21 6b a0 2d 2e 33 17 03 03 00 21 |8Z.t.!k.-.3....!|
00000050 30 c2 c5 18 43 17 7f a9 03 fb e5 f0 52 1e 20 64 |0...C.......R. d|
00000060 94 a0 89 af f1 77 3a fb 1a a0 6f c2 47 ea d9 0a |.....w:...o.G...|
00000070 08 |.|
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/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 15 03 03 00 1a 00 00 00 00 00 00 00 01 ce 9e d4 |................|
00000010 2a a1 d3 bb d6 e6 59 9f 77 05 cc 3e 1f c9 91 |*.....Y.w..>...|
Reference in New Issue Copy Permalink