2015-03-06 13:08:55 +00:00
|
|
|
>>> Flow 1 (client to server)
|
2015-04-16 19:59:22 +01:00
|
|
|
00000000 16 03 01 00 7d 01 00 00 79 03 03 00 00 00 00 00 |....}...y.......|
|
2015-03-06 13:08:55 +00:00
|
|
|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
|
|
|
|
|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 1e c0 2f |.............../|
|
|
|
|
|
00000030 c0 2b c0 30 c0 2c c0 11 c0 07 c0 13 c0 09 c0 14 |.+.0.,..........|
|
2015-04-16 19:59:22 +01:00
|
|
|
00000040 c0 0a 00 05 00 2f 00 35 c0 12 00 0a 01 00 00 32 |...../.5.......2|
|
2015-03-06 13:08:55 +00:00
|
|
|
00000050 00 05 00 05 01 00 00 00 00 00 0a 00 08 00 06 00 |................|
|
|
|
|
|
00000060 17 00 18 00 19 00 0b 00 02 01 00 00 0d 00 0a 00 |................|
|
2015-04-16 19:59:22 +01:00
|
|
|
00000070 08 04 01 04 03 02 01 02 03 ff 01 00 01 00 00 12 |................|
|
|
|
|
|
00000080 00 00 |..|
|
2015-03-06 13:08:55 +00:00
|
|
|
>>> Flow 2 (server to client)
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
00000000 16 03 03 00 59 02 00 00 55 03 03 c1 99 f4 77 ba |....Y...U.....w.|
|
|
|
|
|
00000010 f5 46 ef 26 6d 0d e2 57 6f 04 28 01 4e 69 d8 e0 |.F.&m..Wo.(.Ni..|
|
|
|
|
|
00000020 2f 70 03 fe 77 b9 d1 7b fc 49 ed 20 e2 0f 35 19 |/p..w..{.I. ..5.|
|
|
|
|
|
00000030 ae 5a 66 04 be cc 60 d3 4f 6d ce b2 25 7f 25 24 |.Zf...`.Om..%.%$|
|
|
|
|
|
00000040 31 23 d8 40 bf 78 77 4d fa 11 22 3d c0 30 00 00 |1#.@.xwM.."=.0..|
|
2015-03-06 13:08:55 +00:00
|
|
|
00000050 0d ff 01 00 01 00 00 0b 00 04 03 00 01 02 16 03 |................|
|
|
|
|
|
00000060 03 02 be 0b 00 02 ba 00 02 b7 00 02 b4 30 82 02 |.............0..|
|
|
|
|
|
00000070 b0 30 82 02 19 a0 03 02 01 02 02 09 00 85 b0 bb |.0..............|
|
|
|
|
|
00000080 a4 8a 7f b8 ca 30 0d 06 09 2a 86 48 86 f7 0d 01 |.....0...*.H....|
|
|
|
|
|
00000090 01 05 05 00 30 45 31 0b 30 09 06 03 55 04 06 13 |....0E1.0...U...|
|
|
|
|
|
000000a0 02 41 55 31 13 30 11 06 03 55 04 08 13 0a 53 6f |.AU1.0...U....So|
|
|
|
|
|
000000b0 6d 65 2d 53 74 61 74 65 31 21 30 1f 06 03 55 04 |me-State1!0...U.|
|
|
|
|
|
000000c0 0a 13 18 49 6e 74 65 72 6e 65 74 20 57 69 64 67 |...Internet Widg|
|
|
|
|
|
000000d0 69 74 73 20 50 74 79 20 4c 74 64 30 1e 17 0d 31 |its Pty Ltd0...1|
|
|
|
|
|
000000e0 30 30 34 32 34 30 39 30 39 33 38 5a 17 0d 31 31 |00424090938Z..11|
|
|
|
|
|
000000f0 30 34 32 34 30 39 30 39 33 38 5a 30 45 31 0b 30 |0424090938Z0E1.0|
|
|
|
|
|
00000100 09 06 03 55 04 06 13 02 41 55 31 13 30 11 06 03 |...U....AU1.0...|
|
|
|
|
|
00000110 55 04 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 31 |U....Some-State1|
|
|
|
|
|
00000120 21 30 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 6e |!0...U....Intern|
|
|
|
|
|
00000130 65 74 20 57 69 64 67 69 74 73 20 50 74 79 20 4c |et Widgits Pty L|
|
|
|
|
|
00000140 74 64 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 |td0..0...*.H....|
|
|
|
|
|
00000150 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 bb |........0.......|
|
|
|
|
|
00000160 79 d6 f5 17 b5 e5 bf 46 10 d0 dc 69 be e6 2b 07 |y......F...i..+.|
|
|
|
|
|
00000170 43 5a d0 03 2d 8a 7a 43 85 b7 14 52 e7 a5 65 4c |CZ..-.zC...R..eL|
|
|
|
|
|
00000180 2c 78 b8 23 8c b5 b4 82 e5 de 1f 95 3b 7e 62 a5 |,x.#........;~b.|
|
|
|
|
|
00000190 2c a5 33 d6 fe 12 5c 7a 56 fc f5 06 bf fa 58 7b |,.3...\zV.....X{|
|
|
|
|
|
000001a0 26 3f b5 cd 04 d3 d0 c9 21 96 4a c7 f4 54 9f 5a |&?......!.J..T.Z|
|
|
|
|
|
000001b0 bf ef 42 71 00 fe 18 99 07 7f 7e 88 7d 7d f1 04 |..Bq......~.}}..|
|
|
|
|
|
000001c0 39 c4 a2 2e db 51 c9 7c e3 c0 4c 3b 32 66 01 cf |9....Q.|..L;2f..|
|
|
|
|
|
000001d0 af b1 1d b8 71 9a 1d db db 89 6b ae da 2d 79 02 |....q.....k..-y.|
|
|
|
|
|
000001e0 03 01 00 01 a3 81 a7 30 81 a4 30 1d 06 03 55 1d |.......0..0...U.|
|
|
|
|
|
000001f0 0e 04 16 04 14 b1 ad e2 85 5a cf cb 28 db 69 ce |.........Z..(.i.|
|
|
|
|
|
00000200 23 69 de d3 26 8e 18 88 39 30 75 06 03 55 1d 23 |#i..&...90u..U.#|
|
|
|
|
|
00000210 04 6e 30 6c 80 14 b1 ad e2 85 5a cf cb 28 db 69 |.n0l......Z..(.i|
|
|
|
|
|
00000220 ce 23 69 de d3 26 8e 18 88 39 a1 49 a4 47 30 45 |.#i..&...9.I.G0E|
|
|
|
|
|
00000230 31 0b 30 09 06 03 55 04 06 13 02 41 55 31 13 30 |1.0...U....AU1.0|
|
|
|
|
|
00000240 11 06 03 55 04 08 13 0a 53 6f 6d 65 2d 53 74 61 |...U....Some-Sta|
|
|
|
|
|
00000250 74 65 31 21 30 1f 06 03 55 04 0a 13 18 49 6e 74 |te1!0...U....Int|
|
|
|
|
|
00000260 65 72 6e 65 74 20 57 69 64 67 69 74 73 20 50 74 |ernet Widgits Pt|
|
|
|
|
|
00000270 79 20 4c 74 64 82 09 00 85 b0 bb a4 8a 7f b8 ca |y Ltd...........|
|
|
|
|
|
00000280 30 0c 06 03 55 1d 13 04 05 30 03 01 01 ff 30 0d |0...U....0....0.|
|
|
|
|
|
00000290 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 81 81 |..*.H...........|
|
|
|
|
|
000002a0 00 08 6c 45 24 c7 6b b1 59 ab 0c 52 cc f2 b0 14 |..lE$.k.Y..R....|
|
|
|
|
|
000002b0 d7 87 9d 7a 64 75 b5 5a 95 66 e4 c5 2b 8e ae 12 |...zdu.Z.f..+...|
|
|
|
|
|
000002c0 66 1f eb 4f 38 b3 6e 60 d3 92 fd f7 41 08 b5 25 |f..O8.n`....A..%|
|
|
|
|
|
000002d0 13 b1 18 7a 24 fb 30 1d ba ed 98 b9 17 ec e7 d7 |...z$.0.........|
|
|
|
|
|
000002e0 31 59 db 95 d3 1d 78 ea 50 56 5c d5 82 5a 2d 5a |1Y....x.PV\..Z-Z|
|
|
|
|
|
000002f0 5f 33 c4 b6 d8 c9 75 90 96 8c 0f 52 98 b5 cd 98 |_3....u....R....|
|
|
|
|
|
00000300 1f 89 20 5f f2 a0 1c a3 1b 96 94 dd a9 fd 57 e9 |.. _..........W.|
|
|
|
|
|
00000310 70 e8 26 6d 71 99 9b 26 6e 38 50 29 6c 90 a7 bd |p.&mq..&n8P)l...|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
00000320 d9 16 03 03 00 cd 0c 00 00 c9 03 00 17 41 04 2b |.............A.+|
|
|
|
|
|
00000330 31 48 64 07 93 c0 be 1d 68 24 fc 3a e9 ab fa 89 |1Hd.....h$.:....|
|
|
|
|
|
00000340 5f 30 31 4f 39 bf c5 a4 90 40 2f c1 f3 83 a6 2a |_01O9....@/....*|
|
|
|
|
|
00000350 00 aa d5 d3 4e 8b ac 3f 4f d6 a2 e5 e6 3b a7 75 |....N..?O....;.u|
|
|
|
|
|
00000360 75 6d 9a de fa 86 ba b8 e5 c0 64 a0 a6 24 8e 04 |um........d..$..|
|
|
|
|
|
00000370 01 00 80 0b 10 7f 53 50 56 f1 0d 66 42 b3 6a ab |......SPV..fB.j.|
|
|
|
|
|
00000380 8b 47 e5 c2 95 01 3b 1d e6 00 43 3e 5e 1e 15 27 |.G....;...C>^..'|
|
|
|
|
|
00000390 9c cb eb 71 8a 57 50 29 5d 46 5d a6 b1 66 13 a6 |...q.WP)]F]..f..|
|
|
|
|
|
000003a0 59 0a 0d 8b a1 6f 8b 56 fd 6e 42 df 11 16 00 3c |Y....o.V.nB....<|
|
|
|
|
|
000003b0 e7 d4 10 6d 03 63 47 25 f5 fa 5d ae b9 67 fd 06 |...m.cG%..]..g..|
|
|
|
|
|
000003c0 e0 c3 8d c3 62 d4 72 18 0b eb 8a c2 3e 40 35 fc |....b.r.....>@5.|
|
|
|
|
|
000003d0 ec 6f e1 52 95 4f b8 52 4c 8e 97 67 bc 63 9a 37 |.o.R.O.RL..g.c.7|
|
|
|
|
|
000003e0 df 89 2b ae 42 88 b6 f7 5b 31 84 47 44 e2 d8 c2 |..+.B...[1.GD...|
|
|
|
|
|
000003f0 79 a8 b0 16 03 03 00 2e 0d 00 00 26 03 01 02 40 |y..........&...@|
|
2015-03-06 13:08:55 +00:00
|
|
|
00000400 00 1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 |................|
|
|
|
|
|
00000410 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 |................|
|
|
|
|
|
00000420 00 00 0e 00 00 00 |......|
|
|
|
|
|
>>> Flow 3 (client to server)
|
|
|
|
|
00000000 16 03 03 01 fb 0b 00 01 f7 00 01 f4 00 01 f1 30 |...............0|
|
|
|
|
|
00000010 82 01 ed 30 82 01 58 a0 03 02 01 02 02 01 00 30 |...0..X........0|
|
|
|
|
|
00000020 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 26 31 10 |...*.H......0&1.|
|
|
|
|
|
00000030 30 0e 06 03 55 04 0a 13 07 41 63 6d 65 20 43 6f |0...U....Acme Co|
|
|
|
|
|
00000040 31 12 30 10 06 03 55 04 03 13 09 31 32 37 2e 30 |1.0...U....127.0|
|
|
|
|
|
00000050 2e 30 2e 31 30 1e 17 0d 31 31 31 32 30 38 30 37 |.0.10...11120807|
|
|
|
|
|
00000060 35 35 31 32 5a 17 0d 31 32 31 32 30 37 30 38 30 |5512Z..121207080|
|
|
|
|
|
00000070 30 31 32 5a 30 26 31 10 30 0e 06 03 55 04 0a 13 |012Z0&1.0...U...|
|
|
|
|
|
00000080 07 41 63 6d 65 20 43 6f 31 12 30 10 06 03 55 04 |.Acme Co1.0...U.|
|
|
|
|
|
00000090 03 13 09 31 32 37 2e 30 2e 30 2e 31 30 81 9c 30 |...127.0.0.10..0|
|
|
|
|
|
000000a0 0b 06 09 2a 86 48 86 f7 0d 01 01 01 03 81 8c 00 |...*.H..........|
|
|
|
|
|
000000b0 30 81 88 02 81 80 4e d0 7b 31 e3 82 64 d9 59 c0 |0.....N.{1..d.Y.|
|
|
|
|
|
000000c0 c2 87 a4 5e 1e 8b 73 33 c7 63 53 df 66 92 06 84 |...^..s3.cS.f...|
|
|
|
|
|
000000d0 f6 64 d5 8f e4 36 a7 1d 2b e8 b3 20 36 45 23 b5 |.d...6..+.. 6E#.|
|
|
|
|
|
000000e0 e3 95 ae ed e0 f5 20 9c 8d 95 df 7f 5a 12 ef 87 |...... .....Z...|
|
|
|
|
|
000000f0 e4 5b 68 e4 e9 0e 74 ec 04 8a 7f de 93 27 c4 01 |.[h...t......'..|
|
|
|
|
|
00000100 19 7a bd f2 dc 3d 14 ab d0 54 ca 21 0c d0 4d 6e |.z...=...T.!..Mn|
|
|
|
|
|
00000110 87 2e 5c c5 d2 bb 4d 4b 4f ce b6 2c f7 7e 88 ec |..\...MKO..,.~..|
|
|
|
|
|
00000120 7c d7 02 91 74 a6 1e 0c 1a da e3 4a 5a 2e de 13 ||...t......JZ...|
|
|
|
|
|
00000130 9c 4c 40 88 59 93 02 03 01 00 01 a3 32 30 30 30 |.L@.Y.......2000|
|
|
|
|
|
00000140 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 00 a0 30 |...U...........0|
|
|
|
|
|
00000150 0d 06 03 55 1d 0e 04 06 04 04 01 02 03 04 30 0f |...U..........0.|
|
|
|
|
|
00000160 06 03 55 1d 23 04 08 30 06 80 04 01 02 03 04 30 |..U.#..0.......0|
|
|
|
|
|
00000170 0b 06 09 2a 86 48 86 f7 0d 01 01 05 03 81 81 00 |...*.H..........|
|
|
|
|
|
00000180 36 1f b3 7a 0c 75 c9 6e 37 46 61 2b d5 bd c0 a7 |6..z.u.n7Fa+....|
|
|
|
|
|
00000190 4b cc 46 9a 81 58 7c 85 79 29 c8 c8 c6 67 dd 32 |K.F..X|.y)...g.2|
|
|
|
|
|
000001a0 56 45 2b 75 b6 e9 24 a9 50 9a be 1f 5a fa 1a 15 |VE+u..$.P...Z...|
|
|
|
|
|
000001b0 d9 cc 55 95 72 16 83 b9 c2 b6 8f fd 88 8c 38 84 |..U.r.........8.|
|
|
|
|
|
000001c0 1d ab 5d 92 31 13 4f fd 83 3b c6 9d f1 11 62 b6 |..].1.O..;....b.|
|
|
|
|
|
000001d0 8b ec ab 67 be c8 64 b0 11 50 46 58 17 6b 99 1c |...g..d..PFX.k..|
|
|
|
|
|
000001e0 d3 1d fc 06 f1 0e e5 96 a8 0c f9 78 20 b7 44 18 |...........x .D.|
|
|
|
|
|
000001f0 51 8d 10 7e 4f 94 67 df a3 4e 70 73 8e 90 91 85 |Q..~O.g..Nps....|
|
|
|
|
|
00000200 16 03 03 00 46 10 00 00 42 41 04 1e 18 37 ef 0d |....F...BA...7..|
|
|
|
|
|
00000210 19 51 88 35 75 71 b5 e5 54 5b 12 2e 8f 09 67 fd |.Q.5uq..T[....g.|
|
|
|
|
|
00000220 a7 24 20 3e b2 56 1c ce 97 28 5e f8 2b 2d 4f 9e |.$ >.V...(^.+-O.|
|
|
|
|
|
00000230 f1 07 9f 6c 4b 5b 83 56 e2 32 42 e9 58 b6 d7 49 |...lK[.V.2B.X..I|
|
|
|
|
|
00000240 a6 b5 68 1a 41 03 56 6b dc 5a 89 16 03 03 00 88 |..h.A.Vk.Z......|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
00000250 0f 00 00 84 04 01 00 80 0a 86 16 61 b0 61 19 af |...........a.a..|
|
|
|
|
|
00000260 0e 42 fc ec 44 c2 2b dd 27 cc 9a ee d1 a8 64 7c |.B..D.+.'.....d||
|
|
|
|
|
00000270 ac 69 55 22 3b b2 ba 56 c0 22 53 af 11 be cf f0 |.iU";..V."S.....|
|
|
|
|
|
00000280 90 d1 0e 72 51 d0 f2 4e cd e0 d2 d6 a0 2f 91 46 |...rQ..N...../.F|
|
|
|
|
|
00000290 fa bd 97 b5 a6 ef 66 2e 5e 15 e2 89 df b0 ea 0e |......f.^.......|
|
|
|
|
|
000002a0 67 c4 8c 7e a1 4f 9a 00 dc 32 f9 d1 cd 72 ea 1f |g..~.O...2...r..|
|
|
|
|
|
000002b0 c6 6a 20 54 a2 0f e8 32 50 4e f6 b6 79 70 4c bb |.j T...2PN..ypL.|
|
|
|
|
|
000002c0 68 8f a8 5a 46 49 a6 54 b6 83 53 df 5f 2b 00 cb |h..ZFI.T..S._+..|
|
|
|
|
|
000002d0 09 36 86 f1 21 6b bb 98 14 03 03 00 01 01 16 03 |.6..!k..........|
|
|
|
|
|
000002e0 03 00 28 00 00 00 00 00 00 00 00 af 07 a0 f1 0b |..(.............|
|
|
|
|
|
000002f0 cb 36 97 2c 38 96 e4 02 7c 4d 66 db d0 72 2c 00 |.6.,8...|Mf..r,.|
|
|
|
|
|
00000300 2d ea 21 0a 55 7e 98 9d 65 9a 18 |-.!.U~..e..|
|
2015-03-06 13:08:55 +00:00
|
|
|
>>> Flow 4 (server to client)
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
00000000 14 03 03 00 01 01 16 03 03 00 28 27 8b bb 41 ea |..........('..A.|
|
|
|
|
|
00000010 84 0b 2b d3 d8 1b 13 7c 7c 9d fd 8d 2d 8e ed 2b |..+....||...-..+|
|
|
|
|
|
00000020 1f 32 d5 8d 61 e1 bd 7a 74 59 51 a9 b9 85 6f ae |.2..a..ztYQ...o.|
|
|
|
|
|
00000030 34 1f b1 |4..|
|
2015-03-06 13:08:55 +00:00
|
|
|
>>> Flow 5 (client to server)
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
00000000 17 03 03 00 1e 00 00 00 00 00 00 00 01 0c f2 76 |...............v|
|
|
|
|
|
00000010 e3 1c 31 7e bd 51 b4 4a a8 82 d1 b6 64 51 5f 17 |..1~.Q.J....dQ_.|
|
|
|
|
|
00000020 fc 28 5d 15 03 03 00 1a 00 00 00 00 00 00 00 02 |.(].............|
|
|
|
|
|
00000030 14 1c ec a4 e3 2f 16 d9 22 94 ad be 2a 82 0a 68 |...../.."...*..h|
|
|
|
|
|
00000040 31 d4 |1.|
|
