Page 2 of 2 FirstFirst 12
Results 41 to 59 of 59

Thread: Simulate TLS 1.3

  1. #41
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    Any idea what that problem might be?
    The problem is that most clients request X25519 exchange group in ClientHello and you are directly replying with secp256r1 together with its public key and this is an unexpected behavior. The proper way to decline the requested exchange group is to send a HelloRetryRequest in your first ServerHello with the exchange group the server prefers.

    This is what HRR for secp256r1 (sent as first ServerHello) looks in my impl:

    Code:
    0000 - 16 03 03                                            Record TLS_CONTENT_TYPE_HANDSHAKE
                    00  58                                     Record Size = 0x58
                           02 00                               Handshake TLS_HANDSHAKE_TYPE_SERVER_HELLO
                                 00  54                        Message Size = 0x54
                                        03 03                  TLS_LOCAL_LEGACY_VERSION
                                              CF  21 AD 74 E5  
    0010 - 9A 61 11 BE  1D 8C 02 1E  65 B8 91 C2  A2 11 16 7A  
    0020 - BB 8C 5E 07  9E 09 E2 C8  A8 33 9C                  HelloRetryRandom
                                              20               Session Size = 0x20
                                                  EE 3F A6 18  
    0030 - 91 E4 B4 31  7A E2 B4 5B  DC 41 F4 65  2A A3 C9 B0  
    0040 - 6A 97 F8 E8  43 1C 62 27  F0 04 B6 55               RemoteSessionID
                                                  13 01        CipherSuite = TLS_CS_AES_128_GCM_SHA256
                                                        00     Legacy Compression Method
                                                           00  
    0050 - 0C                                                  Extensions Size = 0x0C
              00 33                                            Extension - Key Share
                    00  02                                     Extension Size = 0x02
                           00 17                               ExchGroup = TLS_GROUP_SECP256R1
                                 00  2B                        Extension - Supported Versions
                                        00 02                  Extension Size = 0x02
                                              03  04           TLS_PROTOCOL_VERSION_TLS13
    Note that there are two caveats. First the random is special, the so called HelloRetryRandom. You can read the specifics in the RFC but I'm using something like this

    Code:
    Private Sub pvTlsArrayHelloRetryRandom(baRetVal() As Byte)
        pvArrayByte baRetVal, &HCF, &H21, &HAD, &H74, &HE5, &H9A, &H61, &H11, &HBE, &H1D, &H8C, &H2, &H1E, &H65, &HB8, &H91, &HC2, &HA2, &H11, &H16, &H7A, &HBB, &H8C, &H5E, &H7, &H9E, &H9, &HE2, &HC8, &HA8, &H33, &H9C
    End Sub
    Second one is in the Key Share when returning the exchange group (TLS_GROUP_SECP256R1 in this case) the public key is missing yet.

    Otherwise your ServerHello is verbatim my second ServerHello (when the client agrees the usage of secp256r1 exchange group in its ClientHello) like this

    Code:
    0000 - 16 03 03                                            Record TLS_CONTENT_TYPE_HANDSHAKE
                    00  9B                                     Record Size = 0x9B
                           02 00                               Handshake TLS_HANDSHAKE_TYPE_SERVER_HELLO
                                 00  97                        Message Size = 0x97
                                        03 03                  TLS_LOCAL_LEGACY_VERSION
                                              37  B4 83 A7 9A  
    0010 - D3 6A 7B 57  48 E1 31 A4  A2 69 09 09  BB D6 98 5B  
    0020 - B7 46 85 DB  96 00 56 C5  C9 20 ED                  LocalExchRandom
                                              20               Session Size = 0x20
                                                  98 31 99 3C  
    0030 - 74 FA 16 C2  26 D5 33 16  91 EA B5 B4  D9 4C 69 B8  
    0040 - 6F 40 08 5E  32 6D E7 7A  ED CE 9F 25               RemoteSessionID
                                                  13 01        CipherSuite = TLS_CS_AES_128_GCM_SHA256
                                                        00     Legacy Compression Method
                                                           00  
    0050 - 4F                                                  Extensions Size = 0x4F
              00 33                                            Extension - Key Share
                    00  45                                     Extension Size = 0x45
                           00 17                               ExchGroup = TLS_GROUP_SECP256R1
                                 00  41                        Public Key Size = 0x41
                                        04 FB 5C  4E 59 DD FC  
    0060 - 48 34 42 BE  48 FD F8 53  62 BC 7C C7  3E 26 6A 3F  
    0070 - E9 21 08 06  B6 AF 4E E5  16 96 AA 7F  E3 33 C4 80  
    0080 - 1D 0F BF 71  A7 07 C0 DF  33 27 12 56  D2 58 6A 1F  
    0090 - BF F9 8B 80  3E 5C B6 A2  41 58                     LocalExchPublic
                                           00 2B               Extension - Supported Versions
                                                  00 02        Extension Size = 0x02
                                                        03 04  TLS_PROTOCOL_VERSION_TLS13
    cheers,
    </wqw>

  2. #42

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    The problem is that most clients request X25519 exchange group in ClientHello and you are directly replying with secp256r1 together with its public key and this is an unexpected behavior. The proper way to decline the requested exchange group is to send a HelloRetryRequest in your first ServerHello with the exchange group the server prefers.
    </wqw>
    FireFox sent both x25519 and secp256r1 public keys. From that I assumed (rightly or wrongly) that it was prepared to accept either. The RFC is not clear on that. Why would it send both if it was not prepared to accept both? That makes no sense at all.

    J.A. Coutts

  3. #43
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Of course you are right. I was testing with chrome, curl and openssl s_client and these are openssl based and send only X25519. Of course when the client sends both groups the server can choose one and respond with local public key etc. so your ServerHello looks ok.

    I suppose it's the next handshake messages that are required/missing for the handshake to complete successfully. Here is a dump of Firefox 82.0.2 handshake (and a bit of traffic) against my server impl

    https://gist.github.com/wqweto/35e7b...2ebc681a99b2a2

    Both groups are present in the ClientHello and just configured the server to choose secp256r1 for this particular traffic dump so there is no HRR here and the ServerHello accepts a cipher and an exchange group from the advertised in CH and sends back the local random and ephemeral public key.

    Note that TlsHandshake.Output starts with unencrypted ServerHello and then switches to encrypted traffic for EncryptedExtensions, ServerCertificate, etc. messages. The plaintext content of EncryptedExtensions, ServerCertificate, ServerCertificateVerify and Finished is hexdumped just before it in pvWriteEndOfRecord.Output (unencrypted) section.

    Following is the code that produces these handshake messages:

    Code:
            '--- Record Header
            lPos = pvWriteBeginOfRecord(baOutput, lPos, TLS_CONTENT_TYPE_APPDATA, uCtx)
                '--- Server Encrypted Extensions
                lHandshakePos = lPos
                lPos = pvWriteLong(baOutput, lPos, TLS_HANDSHAKE_TYPE_ENCRYPTED_EXTENSIONS)
                lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=3)
                    lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=2)
                        If LenB(.AlpnNegotiated) <> 0 Then
                            lPos = pvWriteLong(baOutput, lPos, TLS_EXTENSION_TYPE_ALPN, Size:=2)
                            lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=2)
                                lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=2)
                                    lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack)
                                        lPos = pvWriteString(baOutput, lPos, .AlpnNegotiated)
                                    lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                                lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                            lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                        End If
                    lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                '--- Server Certificate
                lPos = pvWriteLong(baOutput, lPos, TLS_HANDSHAKE_TYPE_CERTIFICATE)
                lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=3)
                    '--- certificate request context
                    lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack)
                        lPos = lPos '--- empty
                    lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                    lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=3)
                        For lIdx = 1 To pvCollectionCount(.LocalCertificates)
                            lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=3)
                                baCert = .LocalCertificates.Item(lIdx)
                                lPos = pvWriteArray(baOutput, lPos, baCert)
                            lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                            '--- certificate extensions
                            lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=2)
                                lPos = lPos '--- empty
                            lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                        Next
                    lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                pvWriteBuffer .HandshakeMessages, pvArraySize(.HandshakeMessages), VarPtr(baOutput(lHandshakePos)), lPos - lHandshakePos
                '--- Server Certificate Verify
                lHandshakePos = lPos
                lPos = pvWriteLong(baOutput, lPos, TLS_HANDSHAKE_TYPE_CERTIFICATE_VERIFY)
                lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=3)
                    lPos = pvWriteLong(baOutput, lPos, .LocalSignatureType, Size:=2)
                    lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=2)
                        pvTlsArrayHash baHandshakeHash, .DigestAlgo, .HandshakeMessages, 0
                        lVerifyPos = pvWriteString(baVerifyData, 0, Space$(64) & "TLS 1.3, server CertificateVerify" & Chr$(0))
                        lVerifyPos = pvWriteArray(baVerifyData, lVerifyPos, baHandshakeHash)
                        pvTlsSignatureSign .LocalPrivateKey, .LocalSignatureType, baVerifyData, baSignature
                        lPos = pvWriteArray(baOutput, lPos, baSignature)
                    lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                pvWriteBuffer .HandshakeMessages, pvArraySize(.HandshakeMessages), VarPtr(baOutput(lHandshakePos)), lPos - lHandshakePos
                '--- Server Handshake Finished
                lHandshakePos = lPos
                lPos = pvWriteLong(baOutput, lPos, TLS_HANDSHAKE_TYPE_FINISHED)
                lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=3)
                    pvTlsArrayHash baHandshakeHash, .DigestAlgo, .HandshakeMessages, 0
                    pvTlsHkdfExpandLabel baTemp, .DigestAlgo, .LocalTrafficSecret, "finished", baEmpty, .DigestSize
                    pvTlsHkdfExtract baVerifyData, .DigestAlgo, baTemp, baHandshakeHash
                    lPos = pvWriteArray(baOutput, lPos, baVerifyData)
                lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack)
                pvWriteBuffer .HandshakeMessages, pvArraySize(.HandshakeMessages), VarPtr(baOutput(lHandshakePos)), lPos - lHandshakePos
                '--- Record Type
                lPos = pvWriteLong(baOutput, lPos, TLS_CONTENT_TYPE_HANDSHAKE)
            lPos = pvWriteEndOfRecord(baOutput, lPos, uCtx)
    cheers,
    </wqw>

  4. #44

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Prompted by the packet traces that you pointed to, I decided to run my own packet traces. After receiving the Client Hello from FireFox, the Server sends it's own Server hello:
    Code:
     
    6    F8:BC:12:5E:A0:20: IP-192.168.0.4                                                  
    ---> E8:9E:B4:36:98:F5: IP-192.168.0.6                        443      50304   
        0 E8:9E:B4:36:98:F5:F8:BC:   12:5E:A0:20:08:00:45:00:  ...6.... .^. ..E.
       16 00:C8:14:81:40:00:80:06:   64:54:C0:A8:00:04:C0:A8:  ....@... dT......
       32 00:06:01:BB:C4:80:49:CF:   A7:79:D6:E2:B0:EA:50:18:  ......I. .y....P.
       48 01:00:E8:0A:00:00:
                            16:03:   03:00:9B:02:00:00:97:03:  ........ ........
       64 03:7D:96:A0:33:B2:43:04:   C9:8E:5D:6E:84:93:05:AA:  .}..3.C. ..]n....
       80 42:64:41:24:FA:DB:CC:1B:   5C:5E:0D:2F:73:57:DB:FD:  BdA$.... \^./sW..
       96 CD:20:CE:DF:1E:30:F2:91:   DB:FB:25:DC:13:F7:F5:E2:  . ...0.. ..%.....
      112 1B:FF:C5:5E:02:AA:5B:D3:   BA:07:EF:4B:45:59:C0:FA:  ...^..[. ...KEY..
      128 34:DB:13:01:00:00:4E:00:   33:00:45:00:17:00:41:04:  4.....N. 3.E...A.
      144 6C:64:75:CE:6E:C2:96:C0:   05:4C:AF:8C:21:E2:12:4F:  ldu.n... .L..!..O
      160 97:F8:92:FF:5D:EF:03:53:   0C:FE:83:42:04:89:7C:A1:  ....]..S ...B..|.
      176 67:0D:89:0F:DD:29:38:37:   CF:03:78:75:D6:CD:EB:FA:  g....)87 ..xu....
      192 A6:AD:70:49:CF:DD:A0:17:   F3:E7:27:C6:4E:24:75:0B:  ..pI.... ..'.N$u.
      208 00:2B:00:02:03:04:                                  .+....           
       
     7    E8:9E:B4:36:98:F5: IP-192.168.0.6                                                  
    ---> F8:BC:12:5E:A0:20: IP-192.168.0.4                          50304    443     
        0 F8:BC:12:5E:A0:20:E8:9E:   B4:36:98:F5:08:00:45:00:  ...^. .. .6....E.
       16 00:2F:5D:F0:40:00:80:06:   1B:7E:C0:A8:00:06:C0:A8:  ./].@... .~......
       32 00:04:C4:80:01:BB:D6:E2:   B0:EA:49:CF:A8:19:50:18:  ........ ..I...P.
       48 02:00:A2:73:00:00:
                            15:03:   01:00:02:02:32:           ...s.... ....2   
    
    Fatal Alert 50 = decode_error
    to which FireFox responds with a Fatal Alert 50 (decode_error). It does not like something about the Server Hello, and I am at a loss to figure out what that is.

    J.A. Coutts

  5. #45
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    What is this part in the hexdump?

    Code:
        0 E8:9E:B4:36:98:F5:F8:BC:   12:5E:A0:20:08:00:45:00:  ...6.... .^. ..E.
       16 00:C8:14:81:40:00:80:06:   64:54:C0:A8:00:04:C0:A8:  ....@... dT......
       32 00:06:01:BB:C4:80:49:CF:   A7:79:D6:E2:B0:EA:50:18:  ......I. .y....P.
       48 01:00:E8:0A:00:00:
    This part is verbatim my ServerHello

    Code:
                            16:03:   03:00:9B:02:00:00:97:03:  ........ ........
       64 03:7D:96:A0:33:B2:43:04:   C9:8E:5D:6E:84:93:05:AA:  .}..3.C. ..]n....
       80 42:64:41:24:FA:DB:CC:1B:   5C:5E:0D:2F:73:57:DB:FD:  BdA$.... \^./sW..
       96 CD:20:CE:DF:1E:30:F2:91:   DB:FB:25:DC:13:F7:F5:E2:  . ...0.. ..%.....
      112 1B:FF:C5:5E:02:AA:5B:D3:   BA:07:EF:4B:45:59:C0:FA:  ...^..[. ...KEY..
      128 34:DB:13:01:00:00:4E:00:   33:00:45:00:17:00:41:04:  4.....N. 3.E...A.
      144 6C:64:75:CE:6E:C2:96:C0:   05:4C:AF:8C:21:E2:12:4F:  ldu.n... .L..!..O
      160 97:F8:92:FF:5D:EF:03:53:   0C:FE:83:42:04:89:7C:A1:  ....]..S ...B..|.
      176 67:0D:89:0F:DD:29:38:37:   CF:03:78:75:D6:CD:EB:FA:  g....)87 ..xu....
      192 A6:AD:70:49:CF:DD:A0:17:   F3:E7:27:C6:4E:24:75:0B:  ..pI.... ..'.N$u.
      208 00:2B:00:02:03:04:                                  .+....
    but there should not be anything before "16 03 03" sent.

    cheers,
    </wqw>

  6. #46

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    What is this part in the hexdump?

    Code:
        0 E8:9E:B4:36:98:F5:F8:BC:   12:5E:A0:20:08:00:45:00:  ...6.... .^. ..E.
       16 00:C8:14:81:40:00:80:06:   64:54:C0:A8:00:04:C0:A8:  ....@... dT......
       32 00:06:01:BB:C4:80:49:CF:   A7:79:D6:E2:B0:EA:50:18:  ......I. .y....P.
       48 01:00:E8:0A:00:00:
    cheers,
    </wqw>
    That is the standard packet header containing such things as the source and destination MAC, IP, & port, and various packet control information. For TCP packets, the data will generally start at byte 54, and I added an extra CrLf to separate the two. On my packet trace program, I simply highlight the data.

    J.A. Coutts

  7. #47
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    That is the standard packet header containing such things as the source and destination MAC, IP, & port, and various packet control information. For TCP packets, the data will generally start at byte 54, and I added an extra CrLf to separate the two. On my packet trace program, I simply highlight the data.

    J.A. Coutts
    LOL :-)) How did you capture that!

    I did the traffic logging from inside my VB6 class, not with external sniffer. . . but good, whatever floats your boat :-))

    cheers,
    </wqw>

  8. #48

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    LOL :-)) How did you capture that!

    cheers,
    </wqw>
    I developed my own packet trace program:
    https://www.vbforums.com/showthread....cket-Ananlyzer
    It uses the Windows Packet Filter Kit 3.2.3 from NT Kernel Resources. I originally developed it to deal with IPv6, but it has come in handy for dealing with any network traffic, not just TCP & UDP. It does not have any packet analysis capabilities, but I usually do that in a separate program designed for a specific purpose. It was instrumental in putting together the TLS 1.2 packet trace page (non ECC) shown here:
    http://www.yellowhead.com/TLS_Handshake5.htm

    J.A. Coutts

  9. #49

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Yet another dumb mistake. When I reworked the Server Hello, I set the extension length to 00:4E instead of 00:4F.

    Now all I have to do is figure out how to get FireFox to accept self signed Certificates. It was easy in previous versions of FireFox.

    J.A. Coutts

  10. #50
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    . . . I set the extension length to 00:4E instead of 00:4F.
    Ouch!

    I was thinking of using text compare on yours vs mine hexdump, unfortunately Session ID and Server Random differ by design and the output formats we both use do not align very well.

    I'm preventing errors like this by using a simple nesting stack (a glorified VBA.Collection) to automatically measure nested block size.

    Something like lPos = pvWriteBeginOfBlock(baOutput, lPos, .BlocksStack, Size:=2) starts a block at lPos position, leaves 2 bytes to encode block size (number of bytes to leave for encoding block size specified by Size param) and advances lPos these 2 bytes. (The parameter .BlocksStack is a simple VBA.Collection.)

    The actual block size gets written later upon lPos = pvWriteEndOfBlock(baOutput, lPos, .BlocksStack) which pops the position of the last pvWriteBeginOfBlock from stack and substracts it from current lPos to come up with actual block size. This function does *not* advance lPos but is implemented like this for compatibility with the rest of the byte-array buffer management functions which have common footprint.

    Quote Originally Posted by couttsj View Post
    Now all I have to do is figure out how to get FireFox to accept self signed Certificates. It was easy in previous versions of FireFox.
    In current version it's very easy to allow a one-time ignore of certificate errors for a site and it *does* persist across browser restart, contrary to chrome which needs confirming ignore on each new session.

    Just on "Warning: Potential Security Risk Ahead" page press [Advanced...] button and ignore further MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT error codes with [Accept the Risk and Continue] button.

    cheers,
    </wqw>

  11. #51

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    In current version it's very easy to allow a one-time ignore of certificate errors for a site and it *does* persist across browser restart, contrary to chrome which needs confirming ignore on each new session.

    Just on "Warning: Potential Security Risk Ahead" page press [Advanced...] button and ignore further MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT error codes with [Accept the Risk and Continue] button.

    cheers,
    </wqw>
    The problem was that when I clicked on the "Advanced" button, there was no scroll bar presented. So I could not scroll down to accept the self signed certificate. I had to use the middle mouse scroll key to see it.

    J.A. Coutts

  12. #52

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    I have overcome the last obstacle in the Client program, and this was a tough one. When I attempted to send an HTML request to OpenSSL, it would return an "unexpected message" error. Not knowing what that meant, or even if this version accepted HTML requests, caused a lot of trial and error solutions and a great deal of research. I ran across one article that called the extra byte added after the data to be encrypted and before the AEAD Authentication Tag as "inner content type". A check with RFC 8446 revealed several references to the "inner content type byte", but no mention of what it was supposed to be or whether or not it was supposed to be checked. A check with RFC 8448 packet traces did not show the extra byte at all. A check with tls13.ulfheim.net showed 0x16 as the Record Type for the New Session Ticket, which was sent using the Application Key/IV. A lot of contradictory or misleading information.

    So I started searching for code examples, and I found one that clearly showed Application data being sent using RT_APPLICATION_DATA (0x17). Armed with this information, I changed the inner content type to reflect the real Record type, and it worked. I had been using &H16 for all records.

    Why this byte is being checked is beyond me. It is not required by the RFC. Because it is being used as a flag to separate padding from the actual data, it could be any value except zero. It serves no other practical purpose. If you are using the wrong keys to decrypt it, you won't be able to tell what it is anyway. And why New Session Tickets use RT_HANDSHAKE (0x16) when they are sent as Application Data is beyond me. Just another idiosyncrasy caused by this middle-box dilemma.

    I still have a remaining problem with FireFox returning an error when receiving the Encrypted Extensions, Cerfificate, Certificate Verify, and Server Finished. I can't even tell what the error is because I can't decrypt it, but fireFox itself says that it is an Authentication error. Once I solve this problem, I will update the download.

    J.A. Coutts

  13. #53

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    On the off chance that FireFox would not accept the second key that they offered in the Client Hello (secp256r1), I decided to try a Hello Retry. I had to yet implement it in the Server software, so it had to be done anyway. This is what I sent:
    Code:
    16 03 03 00 58 
    02 00 00 54 
    03 03 
    CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 
    C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C 
    20 
    88 F3 B8 06 DE 88 A6 B8 A7 CE 45 CD 40 79 DC 45 
    E2 B3 0B 8D 46 A6 1C F7 66 4C 25 15 D4 5B 0D 30 
    13 01 
    00 
    00 0C 
    00 33 
       00 02 
          00 17 
    00 2B 
       00 02 
          03 04
    for which I received a Fatal Alert 47. FireFox says that it is a malformed Hello Retry Request. Use the key that they provided and I get an authentication error. Send a Hello Retry Request, and I get a Malformed Hello Retry Request error. This is getting very frustrating.

    J.A. Coutts

  14. #54
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    This HRR looks verbatim to the one I posted above so something else must be the problem.

    You can grab one of my TLS backends (e.g. mdTlsThunks) and use its TlsHandshake function in parallel to your implementation. These backend modules are standalone (so called sans-IO) implementation of the protocol so they don't do network I/O but expect someone to feed them input byte-arrays and send resultant output byte-arrays on their behalf.

    You can compare this TlsHandshake output to yours and monitor/modify its TLS internal state stored in the UcsTlsContext user-defined type so that both TLS randoms and session IDs match. The idea is to derive identical handshake keys/IVs so that encrypted hadshake traffic must match in both parallel impl.

    You can turn off X25519 support (in pvCryptoIsSupported function) for the module to fallback to secp256r1 group for the ECDHE to match bcrypt primitives you are using. I can send you a sample project with this tweak based on traffic with standard Winsock control if you think this would be useful.

    cheers,
    </wqw>

  15. #55

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    926

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    SNI is obsolete and replaced by ALPN. I'm supporting the latter only as SNI is viable only up to TLS 1.2

    cheers,
    </wqw>
    In the process of testing connectivity to Gmail, I removed various elements of the Client Hello one at a time in order to produce a minimum. The one element that I wanted to eliminate was the SNI, but Gmail produced an alert when I removed it. Gmail obviously doesn't consider it obsolete.

    J.A. Coutts

  16. #56
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Cannot even remember what was I thinking but this is plain wrong. SNI and ALPN deliver orthogonal data -- it's like machine vs service or IP vs port.

    There is some experimental effort to replace SNI with Encrypted SNI which failed mostly (only Firefox implemented it) and now there is Encrypted Client Hello draft being discussed that will protect ALPN as well.

    cheers,
    </wqw>

  17. #57
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    I can send you a sample project with this tweak based on traffic with standard Winsock control if you think this would be useful.
    Btw, just comitted BareboneTls sample which uses the TLS backends with traffic over standard MS Winsock Control.

    The sample includes an https client in Form1 (~200 LOC) and a minimal https server in Form2 (~120 LOC) and both of these work with the ASM thunks based backend and the native SSPI/Schannel based one depending on if Project1.vbp or Project2.vbp is loaded in IDE. (The minimal server in Form2 generates a 1024-bit RSA self-signed certificate on startup too.)

    The idea is to be able to easily put breakpoints on Winsock's SendData method and DataArrival event to dump/inspect encrypted traffic.

    cheers,
    </wqw>

  18. #58
    PowerPoster
    Join Date
    Jun 2013
    Posts
    5,022

    Re: Simulate TLS 1.3

    First of all, thanks to you two for your ongoing efforts on this topic...

    Quote Originally Posted by wqweto View Post
    Btw, just comitted BareboneTls sample which uses the TLS backends with traffic over standard MS Winsock Control.
    Interesting (and my first real contact with vbAsyncSocket and this TLS-implementation).

    I have a few questions...:

    1) I take it, that the MS-Winsock control was used "to keep the two Test-Projects simple"
    ... (and that your vbAsyncSocket could've been used in a stable manner as well)?

    2) And that with "native" (Project2) you mean the "direct use of the MS-Crypto-APIs"...?

    3)... and that Project1 works "MS-dependency-free" via thunks (derived from libSodium)...?

    4) If 3) is a "Yes"... is there any sub-dependencies behind libSodium, which I'm not aware of (OpenSSL and stuff) -
    ... (or does libSodium support a compile-switch, which makes it work with via the Crypto-API of the given OS internally)?

    BackGround:
    I plan to make the cTCP(Client/Server) classes IP-v6 capable in the next weeks (for a newer RC6-release)...

    And at this occasion (in case you say, your TLS-implementation is already "mature enough for TLS 1.3 - and the versions below it") -
    I'd like to implement also a WinHttp51 compatible http(s) Class... which (under the covers) works "as platform-independent as possible"
    (libSodium then statically linked into my accompanying flat-dll - accessed without thunking).

    So I'm basically asking for your "do or don't" (or "wait a few weeks/months").

    Olaf

  19. #59
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    2,441

    Re: Simulate TLS 1.3

    Quote Originally Posted by Schmidt View Post
    1) I take it, that the MS-Winsock control was used "to keep the two Test-Projects simple"
    ... (and that your vbAsyncSocket could've been used in a stable manner as well)?
    Yes. The TLS "backends" are written in Sans-IO manner so that the actual networking can be done with whatever socket library anyone would like to use.

    Quote Originally Posted by Schmidt View Post
    2) And that with "native" (Project2) you mean the "direct use of the MS-Crypto-APIs"...?
    Yes. Newer CNG calls are kept to a minimum so this works on Win2000 and NT 4.0 too.

    Quote Originally Posted by Schmidt View Post
    3)... and that Project1 works "MS-dependency-free" via thunks (derived from libSodium)...?
    Yes, but the libsodium dependency is optional (and not very useful) so this is 100% dependency free.

    Quote Originally Posted by Schmidt View Post
    4) If 3) is a "Yes"... is there any sub-dependencies behind libSodium, which I'm not aware of (OpenSSL and stuff) -
    ... (or does libSodium support a compile-switch, which makes it work with via the Crypto-API of the given OS internally)?
    No, the thunks are *not* based on libsodum but mostly on cifra and putty (for AES-NI accelerated symmetric ciphers) because these are more succinct sources targeting embedded projects and are easier to convert to position independent code (aka "to thunk":-)). The thunks are overall 33477 bytes of code total with 1952 bytes static tables.

    The original project started with stdcall compiled libsodium and "native" crypto API calls but it soon turned out libsodium is missing a lot of primitives for TLS. The idea of libsodium is to be very opinionated and to include only crypto primitives that its author considers strong enough and which he can implement in production manner -- fast and with optimized support for x86_64 and ARM w/ intrinsics and so on.

    That is why there is no AES-128 included (just use AES-256) and no CBC mode (just use GCM) in libsodium. Also there is no ECC (ellipic curves) in libsodium at all, so ECDHE is no go with it.

    Quote Originally Posted by Schmidt View Post
    BackGround:
    I plan to make the cTCP(Client/Server) classes IP-v6 capable in the next weeks (for a newer RC6-release)...

    And at this occasion (in case you say, your TLS-implementation is already "mature enough for TLS 1.3 - and the versions below it") -
    I'd like to implement also a WinHttp51 compatible http(s) Class... which (under the covers) works "as platform-independent as possible"
    (libSodium then statically linked into my accompanying flat-dll - accessed without thunking).
    This cannot be done with libsodium only. For complete TLS support you will need *various* libs/sources for the crypto primitives. I have them thunked so my C/C++ sources are not good for what you plan to do, although they are complete (meaning they include enough primitives for a TLS backend).

    Frankly, I cannot give you good advice here. Thunks raise false positives with AV software so could be a real PITA, better not to include any in RC6.

    You cannot grab the TLS module as is but you'll need to convert the thunks to a DLL and tweak the TLS backend to use crypto primitives from this DLL which is not a lot of work if DLL is compiled from my C/C++ sources and match function prototypes, I guess. . .

    cheers,
    </wqw>

Page 2 of 2 FirstFirst 12

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