2013-12-20 16:37:05 +00:00
|
|
|
>>> Flow 1 (client to server)
|
2015-04-29 18:10:48 +01:00
|
|
|
00000000 16 03 01 01 53 01 00 01 4f 03 03 66 97 e7 64 f3 |....S...O..f..d.|
|
|
|
|
00000010 e7 d2 ba ba 31 f5 d6 ce 50 c7 48 2e 80 48 f1 1f |....1...P.H..H..|
|
|
|
|
00000020 6a a0 f1 da 7b 7b 45 ac ad e9 73 00 00 b6 c0 30 |j...{{E...s....0|
|
crypto/ecdsa: make Sign safe with broken entropy sources
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes #9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
2015-01-27 07:00:21 +00:00
|
|
|
00000030 c0 2c c0 28 c0 24 c0 14 c0 0a 00 a5 00 a3 00 a1 |.,.(.$..........|
|
|
|
|
00000040 00 9f 00 6b 00 6a 00 69 00 68 00 39 00 38 00 37 |...k.j.i.h.9.8.7|
|
|
|
|
00000050 00 36 00 88 00 87 00 86 00 85 c0 32 c0 2e c0 2a |.6.........2...*|
|
|
|
|
00000060 c0 26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 2f |.&.......=.5.../|
|
|
|
|
00000070 c0 2b c0 27 c0 23 c0 13 c0 09 00 a4 00 a2 00 a0 |.+.'.#..........|
|
|
|
|
00000080 00 9e 00 67 00 40 00 3f 00 3e 00 33 00 32 00 31 |...g.@.?.>.3.2.1|
|
|
|
|
00000090 00 30 00 9a 00 99 00 98 00 97 00 45 00 44 00 43 |.0.........E.D.C|
|
|
|
|
000000a0 00 42 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00 9c |.B.1.-.).%......|
|
|
|
|
000000b0 00 3c 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 0c |.<./...A........|
|
|
|
|
000000c0 c0 02 00 05 00 04 c0 12 c0 08 00 16 00 13 00 10 |................|
|
|
|
|
000000d0 00 0d c0 0d c0 03 00 0a 00 15 00 12 00 0f 00 0c |................|
|
2015-04-29 18:10:48 +01:00
|
|
|
000000e0 00 09 00 ff 02 01 00 00 6f 00 0b 00 04 03 00 01 |........o.......|
|
|
|
|
000000f0 02 00 0a 00 3a 00 38 00 0e 00 0d 00 19 00 1c 00 |....:.8.........|
|
|
|
|
00000100 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 |................|
|
|
|
|
00000110 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 |................|
|
|
|
|
00000120 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 |................|
|
|
|
|
00000130 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 |.. .............|
|
|
|
|
00000140 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 |................|
|
|
|
|
00000150 02 02 03 00 0f 00 01 01 |........|
|
2013-12-20 16:37:05 +00:00
|
|
|
>>> Flow 2 (server to client)
|
crypto/ecdsa: make Sign safe with broken entropy sources
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes #9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
2015-01-27 07:00:21 +00:00
|
|
|
00000000 16 03 03 00 31 02 00 00 2d 03 03 00 00 00 00 00 |....1...-.......|
|
2013-12-20 16:37:05 +00:00
|
|
|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
|
crypto/ecdsa: make Sign safe with broken entropy sources
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes #9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
2015-01-27 07:00:21 +00:00
|
|
|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 c0 14 00 00 |................|
|
|
|
|
00000030 05 ff 01 00 01 00 16 03 03 02 be 0b 00 02 ba 00 |................|
|
|
|
|
00000040 02 b7 00 02 b4 30 82 02 b0 30 82 02 19 a0 03 02 |.....0...0......|
|
|
|
|
00000050 01 02 02 09 00 85 b0 bb a4 8a 7f b8 ca 30 0d 06 |.............0..|
|
|
|
|
00000060 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 45 31 0b |.*.H........0E1.|
|
|
|
|
00000070 30 09 06 03 55 04 06 13 02 41 55 31 13 30 11 06 |0...U....AU1.0..|
|
|
|
|
00000080 03 55 04 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 |.U....Some-State|
|
|
|
|
00000090 31 21 30 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 |1!0...U....Inter|
|
|
|
|
000000a0 6e 65 74 20 57 69 64 67 69 74 73 20 50 74 79 20 |net Widgits Pty |
|
|
|
|
000000b0 4c 74 64 30 1e 17 0d 31 30 30 34 32 34 30 39 30 |Ltd0...100424090|
|
|
|
|
000000c0 39 33 38 5a 17 0d 31 31 30 34 32 34 30 39 30 39 |938Z..1104240909|
|
|
|
|
000000d0 33 38 5a 30 45 31 0b 30 09 06 03 55 04 06 13 02 |38Z0E1.0...U....|
|
|
|
|
000000e0 41 55 31 13 30 11 06 03 55 04 08 13 0a 53 6f 6d |AU1.0...U....Som|
|
|
|
|
000000f0 65 2d 53 74 61 74 65 31 21 30 1f 06 03 55 04 0a |e-State1!0...U..|
|
|
|
|
00000100 13 18 49 6e 74 65 72 6e 65 74 20 57 69 64 67 69 |..Internet Widgi|
|
|
|
|
00000110 74 73 20 50 74 79 20 4c 74 64 30 81 9f 30 0d 06 |ts Pty Ltd0..0..|
|
|
|
|
00000120 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81 8d 00 |.*.H............|
|
|
|
|
00000130 30 81 89 02 81 81 00 bb 79 d6 f5 17 b5 e5 bf 46 |0.......y......F|
|
|
|
|
00000140 10 d0 dc 69 be e6 2b 07 43 5a d0 03 2d 8a 7a 43 |...i..+.CZ..-.zC|
|
|
|
|
00000150 85 b7 14 52 e7 a5 65 4c 2c 78 b8 23 8c b5 b4 82 |...R..eL,x.#....|
|
|
|
|
00000160 e5 de 1f 95 3b 7e 62 a5 2c a5 33 d6 fe 12 5c 7a |....;~b.,.3...\z|
|
|
|
|
00000170 56 fc f5 06 bf fa 58 7b 26 3f b5 cd 04 d3 d0 c9 |V.....X{&?......|
|
|
|
|
00000180 21 96 4a c7 f4 54 9f 5a bf ef 42 71 00 fe 18 99 |!.J..T.Z..Bq....|
|
|
|
|
00000190 07 7f 7e 88 7d 7d f1 04 39 c4 a2 2e db 51 c9 7c |..~.}}..9....Q.||
|
|
|
|
000001a0 e3 c0 4c 3b 32 66 01 cf af b1 1d b8 71 9a 1d db |..L;2f......q...|
|
|
|
|
000001b0 db 89 6b ae da 2d 79 02 03 01 00 01 a3 81 a7 30 |..k..-y........0|
|
|
|
|
000001c0 81 a4 30 1d 06 03 55 1d 0e 04 16 04 14 b1 ad e2 |..0...U.........|
|
|
|
|
000001d0 85 5a cf cb 28 db 69 ce 23 69 de d3 26 8e 18 88 |.Z..(.i.#i..&...|
|
|
|
|
000001e0 39 30 75 06 03 55 1d 23 04 6e 30 6c 80 14 b1 ad |90u..U.#.n0l....|
|
|
|
|
000001f0 e2 85 5a cf cb 28 db 69 ce 23 69 de d3 26 8e 18 |..Z..(.i.#i..&..|
|
|
|
|
00000200 88 39 a1 49 a4 47 30 45 31 0b 30 09 06 03 55 04 |.9.I.G0E1.0...U.|
|
|
|
|
00000210 06 13 02 41 55 31 13 30 11 06 03 55 04 08 13 0a |...AU1.0...U....|
|
|
|
|
00000220 53 6f 6d 65 2d 53 74 61 74 65 31 21 30 1f 06 03 |Some-State1!0...|
|
|
|
|
00000230 55 04 0a 13 18 49 6e 74 65 72 6e 65 74 20 57 69 |U....Internet Wi|
|
|
|
|
00000240 64 67 69 74 73 20 50 74 79 20 4c 74 64 82 09 00 |dgits Pty Ltd...|
|
|
|
|
00000250 85 b0 bb a4 8a 7f b8 ca 30 0c 06 03 55 1d 13 04 |........0...U...|
|
|
|
|
00000260 05 30 03 01 01 ff 30 0d 06 09 2a 86 48 86 f7 0d |.0....0...*.H...|
|
|
|
|
00000270 01 01 05 05 00 03 81 81 00 08 6c 45 24 c7 6b b1 |..........lE$.k.|
|
|
|
|
00000280 59 ab 0c 52 cc f2 b0 14 d7 87 9d 7a 64 75 b5 5a |Y..R.......zdu.Z|
|
|
|
|
00000290 95 66 e4 c5 2b 8e ae 12 66 1f eb 4f 38 b3 6e 60 |.f..+...f..O8.n`|
|
|
|
|
000002a0 d3 92 fd f7 41 08 b5 25 13 b1 18 7a 24 fb 30 1d |....A..%...z$.0.|
|
|
|
|
000002b0 ba ed 98 b9 17 ec e7 d7 31 59 db 95 d3 1d 78 ea |........1Y....x.|
|
|
|
|
000002c0 50 56 5c d5 82 5a 2d 5a 5f 33 c4 b6 d8 c9 75 90 |PV\..Z-Z_3....u.|
|
|
|
|
000002d0 96 8c 0f 52 98 b5 cd 98 1f 89 20 5f f2 a0 1c a3 |...R...... _....|
|
|
|
|
000002e0 1b 96 94 dd a9 fd 57 e9 70 e8 26 6d 71 99 9b 26 |......W.p.&mq..&|
|
|
|
|
000002f0 6e 38 50 29 6c 90 a7 bd d9 16 03 03 00 cd 0c 00 |n8P)l...........|
|
|
|
|
00000300 00 c9 03 00 17 41 04 1e 18 37 ef 0d 19 51 88 35 |.....A...7...Q.5|
|
|
|
|
00000310 75 71 b5 e5 54 5b 12 2e 8f 09 67 fd a7 24 20 3e |uq..T[....g..$ >|
|
|
|
|
00000320 b2 56 1c ce 97 28 5e f8 2b 2d 4f 9e f1 07 9f 6c |.V...(^.+-O....l|
|
|
|
|
00000330 4b 5b 83 56 e2 32 42 e9 58 b6 d7 49 a6 b5 68 1a |K[.V.2B.X..I..h.|
|
2015-04-29 18:10:48 +01:00
|
|
|
00000340 41 03 56 6b dc 5a 89 05 01 00 80 32 97 6b fe 26 |A.Vk.Z.....2.k.&|
|
|
|
|
00000350 2f 9d b8 7d 5e cd 30 1b 24 e8 e5 d7 fd 35 7b 7b |/..}^.0.$....5{{|
|
|
|
|
00000360 43 23 64 ea 69 a8 30 7d 72 f4 bf 02 f5 6d bd 7e |C#d.i.0}r....m.~|
|
|
|
|
00000370 52 98 a2 a8 f4 43 6e 9f bc 02 2e 5f 08 21 6e b2 |R....Cn...._.!n.|
|
|
|
|
00000380 63 d7 63 4a b8 74 57 52 6c 04 a1 b1 1d 2c 1b ab |c.cJ.tWRl....,..|
|
|
|
|
00000390 ff ba e8 cf 04 eb 18 66 4d 4b 62 b8 27 e3 24 9b |.......fMKb.'.$.|
|
|
|
|
000003a0 5f 73 19 dc 5c 20 75 c5 e3 09 bc 00 34 75 c8 fe |_s..\ u.....4u..|
|
|
|
|
000003b0 b2 83 83 0f 0a b3 64 d7 52 97 d2 34 54 cf 54 88 |......d.R..4T.T.|
|
|
|
|
000003c0 fa d7 0b cf 56 91 de 96 2f 35 de 16 03 03 00 04 |....V.../5......|
|
crypto/ecdsa: make Sign safe with broken entropy sources
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes #9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
2015-01-27 07:00:21 +00:00
|
|
|
000003d0 0e 00 00 00 |....|
|
2013-12-20 16:37:05 +00:00
|
|
|
>>> Flow 3 (client to server)
|
2015-04-29 18:10:48 +01:00
|
|
|
00000000 16 03 03 00 46 10 00 00 42 41 04 f8 15 aa a4 68 |....F...BA.....h|
|
|
|
|
00000010 80 59 4e 9f b5 d5 3c e5 da 4b 89 36 bf 26 cb 69 |.YN...<..K.6.&.i|
|
|
|
|
00000020 e8 99 d8 a5 3e af 1c ac b6 bc c9 dd c5 0b 7e d8 |....>.........~.|
|
|
|
|
00000030 c6 6a 41 80 8d cd 1a 06 23 cd 5a db ec 67 77 fe |.jA.....#.Z..gw.|
|
|
|
|
00000040 e6 cc 6f bb ea b6 5d e7 03 c9 45 14 03 03 00 01 |..o...]...E.....|
|
|
|
|
00000050 01 16 03 03 00 40 7d 9d 03 ca 10 11 dc 09 60 23 |.....@}.......`#|
|
|
|
|
00000060 25 db b3 d2 98 2c 37 9e d1 de 45 01 3e d7 90 ff |%....,7...E.>...|
|
|
|
|
00000070 48 df 65 3f 75 d6 50 21 38 c4 df 0d 24 04 33 54 |H.e?u.P!8...$.3T|
|
|
|
|
00000080 4f 3b 95 80 a6 ab 63 07 83 5b a0 e8 68 60 95 03 |O;....c..[..h`..|
|
|
|
|
00000090 6d 33 6e dd 88 56 |m3n..V|
|
2013-12-20 16:37:05 +00:00
|
|
|
>>> Flow 4 (server to client)
|
|
|
|
00000000 14 03 03 00 01 01 16 03 03 00 40 00 00 00 00 00 |..........@.....|
|
2015-04-29 18:10:48 +01:00
|
|
|
00000010 00 00 00 00 00 00 00 00 00 00 00 74 52 26 02 91 |...........tR&..|
|
|
|
|
00000020 cb 32 d9 03 3f c3 cb 31 71 19 64 8f 12 96 87 22 |.2..?..1q.d...."|
|
|
|
|
00000030 ae da 10 2d 7d 37 d0 38 e3 b8 8d 21 ea 44 c4 3c |...-}7.8...!.D.<|
|
|
|
|
00000040 36 ea 0a 38 07 37 ea a2 c3 e8 02 17 03 03 00 40 |6..8.7.........@|
|
2013-12-20 16:37:05 +00:00
|
|
|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
|
2015-04-29 18:10:48 +01:00
|
|
|
00000060 24 49 ee a7 14 10 1d f9 93 9f 03 63 ab ff 54 9a |$I.........c..T.|
|
|
|
|
00000070 9d 26 3d 0d d1 3d ca 5b ff 69 c8 17 89 fb 7c d2 |.&=..=.[.i....|.|
|
|
|
|
00000080 4b a6 cd d6 91 e3 89 10 1a 6d f4 f5 ae bc 6e 96 |K........m....n.|
|
2013-12-20 16:37:05 +00:00
|
|
|
00000090 15 03 03 00 30 00 00 00 00 00 00 00 00 00 00 00 |....0...........|
|
2015-04-29 18:10:48 +01:00
|
|
|
000000a0 00 00 00 00 00 1f 11 a1 c3 1d 1b d0 63 09 77 2f |............c.w/|
|
|
|
|
000000b0 1a 6a 2c 7b cc f5 01 74 4a a4 81 36 a8 70 c6 96 |.j,{...tJ..6.p..|
|
|
|
|
000000c0 fa 12 8e dc bf |.....|
|