syncsynchalt / illustrated-tls12 Goto Github PK

in Server Encryption Keys Calculation it says that the inputs for curve25519() are
client's public key and server's private key
then in https://tls.ulfheim.net/files/curve25519-mult.c there is:

reads the 32-byte key from a PEM file, takes advantage of the
fact that the last 32 bytes of encoded DER data are the key in
both the private and public key forms.

It says the public and private files end with 32 bytes of key data
but

RSAPublicKey ::= SEQUENCE {
          modulus           INTEGER,  -- n
          publicExponent    INTEGER   -- e
      }
RSAPrivateKey ::= SEQUENCE {
          version           Version,
          modulus           INTEGER,  -- n
          publicExponent    INTEGER,  -- e
          privateExponent   INTEGER,  -- d
          prime1            INTEGER,  -- p
          prime2            INTEGER,  -- q
          exponent1         INTEGER,  -- d mod (p-1)
          exponent2         INTEGER,  -- d mod (q-1)
          coefficient       INTEGER,  -- (inverse of q) mod p
          otherPrimeInfos   OtherPrimeInfos OPTIONAL
      }

https://tools.ietf.org/html/rfc3447#appendix-A.1.1
https://tools.ietf.org/html/rfc3447#appendix-A.1.2
so I am confuse
what attribute of server's private key does the curve25519() really uses?
also plz link to the RFC chapter that defines this

Hi,

It will be cool to have :
https://tls12.xargs.org#ServerKeyExchange => open the page with Server Key Exchange section expanded

Besides TLS 1.3 (#3) and TLS 1.2, it would be nice to have the same style writeup for TLS 1.1 and TLS 1.0.

Right at the moment, I'm looking for information on what happens when a TLS 1.3 server responds to a TLS 1.1 client. (Coincidentally, when I googled DOWNGRD, the Hacker News comment that explained its meaning was actually on the Hacker News post of this very project!)

Of course #16 would be even more awesome: if I could just upload a bunch of hex and have it "explained" on the fly. But I'm pretty sure that would be a vastly different project.

Since we are there... illustrating is great, (simple) direct parsing would be also

https://github.com/syncsynchalt/illustrated-tls/blob/fe8fbe46731428106fac948ebef33fe4062f28a8/site/index.html#L112-L116

This section states that the practice of using unix time in the hello random bytes is recommended against, but the link is an expired draft of a document. Is there any non-expired official document that backs up this recommendation because I see many libraries using the unix time anyway. This includes mbedTLS, Apple's NSURL framework, and OkHttp for Java.

Hi,

THE BEST site for SSL explanation.

The experience will be even better if you can differentiate different parts the req/resp message hex parts.

I'm overriding site styles with below:

.record-data .string {
    background-color: lightsalmon;
}
.record-data .string:nth-child(even) {
    background-color: lightseagreen;
}

After which, the Hex dump will be even clear (if required, you can add a toggle button):

Thanks.

It would be nice if we also have mutual authentication illustrated 😃

TLS v1.3 is already there (RFC 8446) - adding Illustrated TLS for the new version of the protocol might be useful for spreading the knowledge :).

https://github.com/syncsynchalt/illustrated-tls/blob/ca15ef399709e85d8b39896dc352239df01e4988/site/index.html#L261

I see four bytes that follow. Is this a bug or did I miss something?

Could you please add this demo. I could not decrypt the ssl message. Maybe I made a mistake with the secret. But I do not know where is the problem.

Since this is the server calculation, "client" should be replaced with "server" even though all the calculations are the same.

in https://tls.ulfheim.net
then Server key exchange
then Signature
it says
the computed signature for...
SHA256(client_hello_random + server_hello_random + curve_info + public_key)
wikipedia says that the output of SHA256 is 32bytes
so is your page wrong or
where did you get those 256 byes from

It would be very cool to have the corresponding openssl -vvvv lines at each step

Hi,

Thanks for this wonderful work! Made me understand so much about TLS 1.2
i'm confused about the part where you wrote CLIENT HANDSHAKE FINISHED

In the Encryption IV, The client has sent an initialization vector for decrypting this block. Because we have overridden the rand function it is a predictable sequence.
and the Encrypted Data as well.

Where does the IV come from? Also the "data" that you encrypt, can you specify exactly which one, I find all the things so clear but this part is not for me.

16 03 03 00 40 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 22 7b c9 ba 81 ef 30 f2 a8 a7 8f f1 df 50 84 4d 58 04 b7 ee b2 e2 14 c3 2b 68 92 ac a3 db 7b 78 07 7f dd 90 06 7c 51 6b ac b3 ba 90 de df 72 0f
Decryption
14 00 00 0c cf 91 96 26 f1 36 0c 53 6a aa d7 3a

Is all this part also sent to the Server? Or just the encrypted version?

Thanks so much for the clarification :)

Hi everyone. The website is really helpful for me to understand every single message of tls. Since the key exhance process on the website uses ECDHE. Is there any resource which uses rsa or dhe that I can refer to? Thanks you so much for providing this wonderful work.

Not entirely sure, but I think there might be a mismatch between the verify_data in these two places (both in Client Handshake Finished > Verify Data):

• "The verify data calculated from this hash is a0744dd49a212f152b3c060d"

• "hexdump /tmp/verify_data: 0000000 cf 91 96 26 f1 36 0c 53 6a aa d7 3a"