Results 1 to 8 of 8

Thread: Simulate TLS 1.3

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    866

    Simulate TLS 1.3

    To understand TLS 1.3, https://tls13.ulfheim.net/ is useful, but unfortunately it contains several discrepancies if you want to follow it in detail (eg. labels are not complete). For the detail, https://tools.ietf.org/html/rfc8448 is better. Unfortunately, Win 8.1 does not support x25519, so the best I could come up with was a simulation without generating the Agreed Secret.

    Like previous cryptographic protocols, TLS 1.3 uses a Session Hash. Unlike previous protocols, it uses 2 sets of keys and encrypts part of the handshake. The Session Hash uses the decrypted data, and Write keys on the Server are Read keys on the Client (and visa versa).

    The attached program attempts to duplicate the steps in the IETF trace example for the Simple 1-RTT Handshake, separating the Client steps from the Server. In the Client and Server portions, the Hash is not calculated or shown, as it is included in the Info. Clicking "Client" or "Server" takes you to the first step of calculating the "Early Secret". Using the "Enter" key advances through each step until the keys are summarized at the end.

    The Key options on the other hand don't show all the information used, the Session Hash is calculated, and calculations are made as soon as the information is available.

    The next step will be to add the actual encryption/decryption as well as the application data.

    J.A. Coutts
    Attached Images Attached Images  
    Attached Files Attached Files

  2. #2

  3. #3

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    866

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    Btw, the Illustrated TLS site source code is available on github: https://github.com/syncsynchalt/illustrated-tls13

    Which labels are missing? I can send a PR w/ the fixes.

    cheers,
    </wqw>
    label = "derived" instead of label = "tls13 derived". The "tls13 " seemed to be missing on all the labels. There were other problems, but that was the most obvious. Other than missing details, the site was very informative.

    J.A. Coutts

  4. #4
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,088

    Re: Simulate TLS 1.3

    Yes, they always prefix the label with "tls13 " in hkdf.sh on line 22. On line 18 they have let labellen=labellen+6 which adds the size of "tls13 " prefix.

    Btw, in my effort I never needed pure Expand so from HKDF primitives the module finished with implemented Extract method (which is a glorified HMAC) and ExpandLabel combo as they did in hkdf.sh. That would be like to combine CreateInfo and Expand methods on your clsHKDF in a single ExpandLabel method with more parameters.

    cheers,
    </wqw>

  5. #5

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    866

    Re: Simulate TLS 1.3

    This version adds the actual packet formulation and transmission to the simulation plus a sample encrypted data packet. To accomplish this, separate Client and Server programs are utilized. Because Win 8.1 does not support x25519, the Client Hello and Server Hello had to be imported. Normally, errors 0 to 12 are returned instead of the Agreed Secret to indicate where the error occurred, but this error is not currently being intercepted. Instead, the Agreed Secret used by RFC 8448 is imported.

    I vaguely remember something about the Session Hash being reset after the Handshake is established, but I could not find any information to verify that. If anyone can point me towards such information, it would be greatly appreciated.

    J.A. Coutts
    Attached Images Attached Images   
    Attached Files Attached Files

  6. #6
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,088

    Re: Simulate TLS 1.3

    > I vaguely remember something about the Session Hash being reset after the Handshake is established, but I could not find any information to verify that. If anyone can point me towards such information, it would be greatly appreciated.

    Take a look at Section 4.4.1. The Transcript Hash of RFC 8446 where they talk about "synthetic handshake message".

    Resetting the handshake messages hash and starting w/ a simple 32-byte Hash(ClientHello1) in the current buffer for handshake messages (i.e. storing only a hash of the handshake messages before reset) is done no matter if the server uses cookie extension on HRR or not i.e. doesn't matter if the server is implementing HRR in stateless fashion or keeps state in some connection bound object as is the case with cTlsSocket class -- its instances don't use cookies for HRR as the TLS connection's previous state (before reset) is available in the instance itself so no need to implement HRR in a stateless fashion.

    cheers,
    </wqw>

  7. #7

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    866

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    Take a look at Section 4.4.1. The Transcript Hash of RFC 8446 where they talk about "synthetic handshake message".

    Resetting the handshake messages hash and starting w/ a simple 32-byte Hash(ClientHello1) in the current buffer for handshake messages (i.e. storing only a hash of the handshake messages before reset) is done no matter if the server uses cookie extension on HRR or not i.e. doesn't matter if the server is implementing HRR in stateless fashion or keeps state in some connection bound object as is the case with cTlsSocket class -- its instances don't use cookies for HRR as the TLS connection's previous state (before reset) is available in the instance itself so no need to implement HRR in a stateless fashion.

    cheers,
    </wqw>
    I have always found that RFC's are extremely difficult to follow, but I think what it is saying is that the Session Hash (Transcript Hash) is only used during the Handshake. So maintaining the Session Hash post Handshake is rather pointless in TLS 1.3.

    One other thing I noticed is that only the Client and Server Hello record headers are classified as RT_HANDSHAKE (&H16). The rest of the handshake records are classified as RT_APPLICATION_DATA (&H17). That seems a little odd to me.

    J.A. Coutts

  8. #8
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,088

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    The rest of the handshake records are classified as RT_APPLICATION_DATA (&H17). That seems a little odd to me.
    The only type of records that can be protected (encrypted) are RT_APPLICATION_DATA so encrypted handshake, alerts and actual data can pass through hardware middle-boxes designed for TLS 1.2 without traffic being expected. These firewalls cannot decrypt data traffic even in TLS 1.2 but in TLS 1.2 the handshake was not encrypted and h/w inspected it as it passed in plain-text (so called Stateful Packet Inspection).

    It is the last byte of the decrypted data (just before the zero padding) that we discussed above that holds the actual record type. If the wrapper record type is *not* RT_APPLICATION_DATA on encrypted records then this should raise unexpected_message (10) alert in both server and client.

    There is tlsfuzzer project that is very useful for testing TLS server implementation adherence. I'm currently running those tests on my TLS 1.3 server and a lot of flaws, deviations from the expected behavior and pure crashes are uncovered. This same fuzzer is used by GnuTLS and openssl (probably) too.

    So yes, alert records can be unencrypted if happening before bulk traffic secrets are established and tunneled encrypted through app data records past this point.

    cheers,
    </wqw>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width