Page 3 of 3 FirstFirst 123
Results 81 to 107 of 107

Thread: Simulate TLS 1.3

  1. #81
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    I just tested latest Firefox against my server-side implementation and there are no Certificate via DNS failures here (not sure if this is applicable for localhost URLs at all).

    You can try testing your server with Secure project in test directory of my repo -- it has an address bar for URL and sends an http GET request over TLS.

    Just put a breakpoint in mdTlsThunks.pvTlsSetLastError routine to capture any alerts the TLS client tries to raise about the handshake. This can pinpoint at what stage the TLS session goes incompatible by peeking at the call-stack.

    cheers,
    </wqw>

  2. #82

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Using OpenSSL, I was finally able to identify the problem. OpenSSL would receive the HTTP Response Header and then report:
    "54:0A:00:00:error:SSL routines::unexpected message:ssl\statem\statem_clnt.c:396:"
    While trying to figure out what that meant, I noticed &H16 at the end of the decrypted header. Then it dawned on me that was the inner message type, which should have been &H17. The problem was caused by poor version control on my part. The correct message type was there, I just wasn't using it in the server program. The Message Type is not part of the actual message and is normally removed, except in the OpenSSL decrypt Hex display.

    There are a couple of other problems to work out with Firefox, but at least I can get the HTML data.

    J.A. Coutts

  3. #83

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    More problems with Firefox on large files. Firefox advertises a Maximum Record Size of 16,385, but the RFCs call for a maximum of 2^14 or 16,384 for plain text length. Either one produces:
    Error Code: SSL_ERROR_RX_RECORD_TOO_LONG
    I have to adjust the record size down to 16,362, so that when the encryption overhead is added, it comes to 16,384. My own client will handle fragment lengths up to 65,514 bytes. Many sites recommend starting at 2^12 and ramping up to 2^14. All in all, it is somewhat confusing.

    How does OpenSSL handle it?

    J.A. Coutts

  4. #84
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    Firefox advertises a Maximum Record Size of 16,385, but the RFCs call for a maximum of 2^14 or 16,384 for plain text length.
    Is this advertized through record_size_limit extension?

    I have not tested extensively my server-side impl with large binary files besides tests that come with tls_fuzzer.

    I'm using these consts for record layer sanity checks
    Code:
    Private Const TLS_MAX_PLAINTEXT_RECORD_SIZE             As Long = 16384
    Private Const TLS_MAX_ENCRYPTED_RECORD_SIZE             As Long = (TLS_MAX_PLAINTEXT_RECORD_SIZE + 1 + 255) '-- 1 byte content type + 255 bytes AEAD padding
    . . . so encrypted size *can* be larger than 2^14 by 1 byte + record padding.

    cheers,
    </wqw>

  5. #85

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    Is this advertized through record_size_limit extension?

    I have not tested extensively my server-side impl with large binary files besides tests that come with tls_fuzzer.

    I'm using these consts for record layer sanity checks
    Code:
    Private Const TLS_MAX_PLAINTEXT_RECORD_SIZE             As Long = 16384
    Private Const TLS_MAX_ENCRYPTED_RECORD_SIZE             As Long = (TLS_MAX_PLAINTEXT_RECORD_SIZE + 1 + 255) '-- 1 byte content type + 255 bytes AEAD padding
    . . . so encrypted size *can* be larger than 2^14 by 1 byte + record padding.

    cheers,
    </wqw>
    It is advertised in the extension section of the Client Hello.
    Code:
    00 1c - record size limit
       00 02 (len=2)
          40 01 - 16,385
    It is my understanding that Firefox does not use OpenSSL (uses NSS?), so you may want to adjust those settings. Some people suggest that shorter record lengths are more efficient, at least at the start of the transfer, but that may not be the case with VB6 powered code. I have not timed it myself.

    J.A. Coutts

  6. #86
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    It is advertised in the extension section of the Client Hello.
    Code:
    00 1c - record size limit
       00 02 (len=2)
          40 01 - 16,385
    It is my understanding that Firefox does not use OpenSSL (uses NSS?), so you may want to adjust those settings. Some people suggest that shorter record lengths are more efficient, at least at the start of the transfer, but that may not be the case with VB6 powered code. I have not timed it myself.

    J.A. Coutts
    Yes, this is exactly record_size_limit extension and there is an RFC about it -- https://tools.ietf.org/html/rfc8449

    It says "TLS 1.3 uses a limit of 2^14+1 octets" so what you are observing from Firefox seems normal while openssl does not send it at all when the record size is not limited on anything below 2^14 i.e. when default limit is used.

    So this looks like 2^14 for plaintext and 1 byte for content type. Remember that TLS 1.3 uses TLS_CONTENT_TYPE_APPDATA (23) to tunnel all kind of records with the actual content type appended at the end plus optional padding w/ zeroes.

    cheers,
    </wqw>

  7. #87

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    Yes, this is exactly record_size_limit extension and there is an RFC about it -- https://tools.ietf.org/html/rfc8449

    It says "TLS 1.3 uses a limit of 2^14+1 octets" so what you are observing from Firefox seems normal while openssl does not send it at all when the record size is not limited on anything below 2^14 i.e. when default limit is used.

    So this looks like 2^14 for plaintext and 1 byte for content type. Remember that TLS 1.3 uses TLS_CONTENT_TYPE_APPDATA (23) to tunnel all kind of records with the actual content type appended at the end plus optional padding w/ zeroes.

    cheers,
    </wqw>
    That particular RFC defines the record length for TLS 1.2 and prior as "the data that ultimately produces TLSCiphertext.fragment", but for TLS !.3 it is "the complete length of TLSInnerPlaintext". It appears that Firefox implements the TLS 1.2 definition for all versions.

    J.A. Coutts

  8. #88

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    While testing my Client program, I discovered that "https://www.google.com" does not accept P-384 or P-521, and returns a Client Retry Request for P-256. The first problem I ran into was that Google sent two RT_CHANGE_CIPHER_SPEC dummy records, one with the first Server Hello (Client Retry Request), and one embedded in with the second Server Hello, EncryptedExtensions, server Certificate, server CertificateVerify, and server Finished. After fixing up the code to deal with that problem, I then encountered what appeared to be random data. It turned out to be encrypted data that was supposed to be unencrypted. That turned out to be a decryption error that was not being properly identified as an "Authentication Error". That was caused by an adjustment I had previously made to the code to fix a different problem. But after fixing that, Google still gives an "Authentication Error" on P-384 or P-521. As per RFC 8446, at this point the Session Hash (Transcript Hash) consists of: Hash(Hash(ClientHello1) + HelloRetryRequest + ClientHello2 + ServerHello). My own Client/Server have no problem dealing with a Client Hello Request under these conditions.

    What am I missing?

    J.A. Coutts

  9. #89
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Here is a handshake dump with P-384 in ClientHello, the server responds with HelloRetryRequest for P-256 and restarts the process with second ClientHello until final ClientHandshakeFinished is encrypted with the handshake keys.

    Code:
    Dump more than 25000 symbols. See link below
    https://pastebin.com/5xn9CHib

    cheers,
    </wqw>

  10. #90
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    As per RFC 8446, at this point the Session Hash (Transcript Hash) consists of: Hash(Hash(ClientHello1) + HelloRetryRequest + ClientHello2 + ServerHello).
    The RFC 8442 is somewhat more explicit:

    Code:
          Hash(message_hash ||        /* Handshake type */
               00 00 Hash.length  ||  /* Handshake message length (bytes) */
               Hash(ClientHello1) ||  /* Hash of ClientHello1 */
               HelloRetryRequest  || ... || Mn)
    Note that there is message_hash = 254 and 3-bytes for Hash.length encoded in network order for a total of 4 bytes prefix before the Hash(ClientHello1).

    My code looks like this:

    Code:
    Private Const TLS_HANDSHAKE_MESSAGE_HASH                As Long = 254
    ...
    
        If .HelloRetryRequest Then
            '--- on HelloRetryRequest replace HandshakeMessages w/ 'synthetic handshake message'
            pvTlsGetHandshakeHash uCtx, baHandshakeHash
            .HandshakeMessages.Size = 0
            pvBufferWriteLong .HandshakeMessages, TLS_HANDSHAKE_MESSAGE_HASH
            pvBufferWriteLong .HandshakeMessages, .DigestSize, Size:=3
            pvBufferWriteArray .HandshakeMessages, baHandshakeHash
        Else
            .State = ucsTlsStateExpectEncryptedExtensions
        End If
    . . . where baHandshakeHash is a byte-array and pvTlsGetHandshakeHash call populates it with the hash of the currently transmitted handshake messages as stored in UcsTlsContext.HandshakeMessages buffer. Then this buffer gets truncated and initially filled with TLS_HANDSHAKE_MESSAGE_HASH, then 3-bytes with .DigestSize and finally the baHandshakeHash byte-array. This is the initial 'synthetic handshake message' the RFC mentions.

    If you don't want to store currently transmitted handshake messages in a buffer but want to calculate hash on the fly as messages are received/sent keep in mind that you might have to calculate *several* different hash functions over these because agreed hash function might change depending on server choice of ciphersuite. Just keeping all currently transmitted handshake messages is way simpler as these do not grow to excessive length.

    cheers,
    </wqw>

  11. #91

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Thanks again wqweto;

    That did it. I could not find anything in RFC 8442, but I did find the info in section 4.4.1 of RFC 8446. I did run across this in my many searches, but it was written in a different code and I didn't really understand it. It appears that a Transcript Hash (Session Hash) is normally defined with a header, and when they want just the hash itself, they use "truncate(hash)". It also showed it ending with &HFF, but obviously that is not necessary.

    This is probably the first time I have run into a real world Hello Retry Request. Previous testing was at a local level only. Testing against OpenSSL produced Fatal Alert 47 (illegal parameter), but this test was simply accomplished by changing the type code. The curve data supplied did not correspond to the type code, and OpenSSL may check that first.

    J.A. Coutts

  12. #92
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,297

    Re: Simulate TLS 1.3

    Windows 10 21H1 is supposed to get native TLS 1.3 support. For mainstream users that is only a few months away, perhaps May 2021.

  13. #93
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by dilettante View Post
    Windows 10 21H1 is supposed to get native TLS 1.3 support. For mainstream users that is only a few months away, perhaps May 2021.
    Implementing TLS from scatch gives you much breadth and confidence in your own crypto understanding.

    This is similar to completing the cryptopals crypto challenges but coming up with something practical which is about 5 times more challenging as well.

    cheers,
    </wqw>

  14. #94

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by dilettante View Post
    Windows 10 21H1 is supposed to get native TLS 1.3 support. For mainstream users that is only a few months away, perhaps May 2021.
    I am confused. Doesn't Win 10 already support TLS 1.3, or are they talking about browser support?

    J.A. Coutts

  15. #95

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    AESClient and AESServer have been updated on post #12. They no longer simulate RFC 8448 data, but still act as a working pair, as well as functional independents capable of interfacing with the outside world.

    J.A. Coutts

  16. #96
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    AESClient and AESServer have been updated on post #12. They no longer simulate RFC 8448 data, but still act as a working pair, as well as functional independents capable of interfacing with the outside world.

    J.A. Coutts
    Does that mean that prjAESServer can be accessed by common browsers?

    I tried using my TLS 1.3 client, openssl based curl, Chrome and FireFox with varying success. TLS handshake is executed ok all clients but the connection timeouts on data receive while the server says "OK Finished SENDING".

    cheers,
    </wqw>

  17. #97

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    Does that mean that prjAESServer can be accessed by common browsers?

    I tried using my TLS 1.3 client, openssl based curl, Chrome and FireFox with varying success. TLS handshake is executed ok all clients but the connection timeouts on data receive while the server says "OK Finished SENDING".

    cheers,
    </wqw>
    The only thing I have to test with is Firefox v86 running on Win 10. My own Web browser does not support TLS 1.3. I downloaded simple Web pages, numerous jpegs, and several pngs. The only problem I ran into was with complex Web pages, where the page would load, but Firefox kept looking for something else. I have not isolated that problem yet.

    J.A. Coutts

    Edit: Digging into it a little further, it appears that the Web page is not complete. The simplest of the complex pages I tried consisted of the body, a style sheet, and 6 png files. Only the first png went through and then the browser made 5 reconnection attempts. It looks like I have some kind of timing issue.

    P.S. The "OK Finished SENDING" is displayed by SimpleServer on every individual record sent.
    Last edited by couttsj; Mar 25th, 2021 at 02:09 PM.

  18. #98

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Unbeknownst to me, the browser uses a different port for each element that it requests within a single page, which results in a new connection for each element. Then it closes the last connection, and the others will time out approximately 2 minutes later. I assume this is done for speed, and I only configured the Server for 5 simultaneous connections, so even in the non-secure version I was not loading all the elements. In the secure version however, there is an additional problem. Each connection re-calculates the keys, and eventually it will get an Authentication error. I will have to re-use the keys calculated in the first connection and close each connection after receipt.

    Please stand by while I correct this situation.

    J.A. Coutts

  19. #99
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    I will have to re-use the keys calculated in the first connection and close each connection after receipt.s
    That would be a mighty hack -- no one does this, sounds appalling from security stand point of view. The way to handle multiple connections is to create new instances of a handler class from the listener. Each client connection handler will accept the incoming socket and perform the TLS handshake separately. The listener might initialize the tls handler with common server settings like the server certificate or supported ciphersuites, etc.

    It's very inconvenient to have any of the TLS logic implemented in a form IMO. I always try to decouple classes in layers -- UI forms -> http server -> tls handler -> winsock. Each layer on the left "knows" about the layer on the right but the "dependency" layer does not call or interact with the "parent" layer i.e. the winsock class/user-control does not call methods on Form1, the same for the class handling TLS logic and the class handling http traffic -- these do not reference objects from the layers above like apps main/settings form or even the http handler from tls handler is not allowed/needed.

    "Separation of concern" as underpinning programming principle is how a healthy codebase is born and everything else leads to a bowl of spaghetti that no one can understand or develop further or maintain in the long turn.

    cheers,
    </wqw>

  20. #100

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    That would be a mighty hack -- no one does this, sounds appalling from security stand point of view. The way to handle multiple connections is to create new instances of a handler class from the listener. Each client connection handler will accept the incoming socket and perform the TLS handshake separately. The listener might initialize the tls handler with common server settings like the server certificate or supported ciphersuites, etc.

    It's very inconvenient to have any of the TLS logic implemented in a form IMO. I always try to decouple classes in layers -- UI forms -> http server -> tls handler -> winsock. Each layer on the left "knows" about the layer on the right but the "dependency" layer does not call or interact with the "parent" layer i.e. the winsock class/user-control does not call methods on Form1, the same for the class handling TLS logic and the class handling http traffic -- these do not reference objects from the layers above like apps main/settings form or even the http handler from tls handler is not allowed/needed.

    "Separation of concern" as underpinning programming principle is how a healthy codebase is born and everything else leads to a bowl of spaghetti that no one can understand or develop further or maintain in the long turn.

    cheers,
    </wqw>
    Correct me if I am wrong, but multiple connections sounds exactly like what 0-RTT was designed to handle. Even OpenSSL passes 2 New Session Tickets. Having different keys for each element of a Web page does not offer any more protection than using a single set of keys, and is without a doubt less efficient. Some Web pages have a dozen or more elements, and performing a complete handshake for every element places an unnecessary burden on the both the server and the client.

    In principle I would agree with you that targeted functionality should be placed in portable units such as Classes or User Controls where possible. But a server should be formless anyway, and that is how I intend to make it in the end.

    J.A. Coutts

  21. #101
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    Correct me if I am wrong, but multiple connections sounds exactly like what 0-RTT was designed to handle. Even OpenSSL passes 2 New Session Tickets. Having different keys for each element of a Web page does not offer any more protection than using a single set of keys, and is without a doubt less efficient. Some Web pages have a dozen or more elements, and performing a complete handshake for every element places an unnecessary burden on the both the server and the client.
    Yes, this is exactly what 0-RTT is designed for. Not implementing it is not a show-stopper though as the browsers limit the number of connections per domain to something like two, so you don't have to worry about being spammed with TLS handshakes for each and every image on that home page for instance.

    In my server-side effort I don't have any support for resumption for 0-RTT. It has a lot of internal bookkeeping that has to be taken care and a lot of RFC paragraphs to implement only to be in service to them browsers.

    Quote Originally Posted by couttsj View Post
    In principle I would agree with you that targeted functionality should be placed in portable units such as Classes or User Controls where possible. But a server should be formless anyway, and that is how I intend to make it in the end.
    +1

    cheers,
    </wqw>

  22. #102

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    Yes, this is exactly what 0-RTT is designed for. Not implementing it is not a show-stopper though as the browsers limit the number of connections per domain to something like two, so you don't have to worry about being spammed with TLS handshakes for each and every image on that home page for instance.

    cheers,
    </wqw>
    Unfortunately, Firefox does not limit the connections, and my research indicates that both Firefox and Chrome were early adopters of 0-RTT. The page that I tested needed 6 connections because Firefox used a different port for each page element. After the main page loaded, the other 5 requests were fired off in rapid succession.
    Code:
    Connect 1 30967.79 - Body (.htm)
    Connect 2 30968.49 - Style Sheet (.css) + 700 ms
    Connect 3 30968.51 - Image1 (.png) + 20 ms
    Connect 4 30968.51 - Lmage2 (.png) +  0 ms
    Connect 5 30968.51 - Lmage3 (.png) +  0 ms
    Connect 6 30968.53 - Lmage4 (.png) + 20 ms
    J.A. Coutts

  23. #103
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    https://docs.pushtechnology.com/clou...mitations.html

    "Browsers limit the number of HTTP connections with the same domain name. This restriction is defined in the HTTP specification (RFC2616). Most modern browsers allow six connections per domain. Most older browsers allow only two connections per domain."

    cheers,
    </wqw>

  24. #104

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    wqweto; FYI

    Based on your latest info, I loaded a more complex page:
    Code:
    Connect: 1 on port: 56094 79219.48
    22:00:19 127.0.0.1 /pages/clouds.htm
    22:00:19 127.0.0.1 /pages/clouds.css
    22:00:19 127.0.0.1 /pages/cloudsBG.png
    Connect: 2 on port: 56095 79219.55
    22:00:19 127.0.0.1 /pages/picture.jpg
    22:00:19 127.0.0.1 /pages/leftcol_top.png
    Connect: 3 on port: 56096 79219.56
    22:00:19 127.0.0.1 /pages/maincol_bottom.png
    Connect: 4 on port: 56097 79219.58
    22:00:19 127.0.0.1 /pages/leftcol_bottom.png
    Connect: 5 on port: 56098 79219.58
    22:00:19 127.0.0.1 /pages/maincol_top.png
    Connect: 6 on port: 56099 79219.59
    22:00:19 127.0.0.1 /pages/rightcol_top.png
    22:00:19 127.0.0.1 /pages/rightcol_bottom.png
    22:00:19 127.0.0.1 /favicon.ico
    Connect: 7 on port: 56100 79220.23
    Close: 7 79225.52
    Interestingly, the browser collects elements together under a single connection to limit the total number of connections. How it determines that is beyond me. I don't know what #7 is for, and I used a non-secure server because it is much simpler.

    J.A. Coutts

  25. #105

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    wqweto;

    How did you handle maximum record size (2^14)? I think this may be part of my problem.

    J.A. Coutts

  26. #106
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,020

    Re: Simulate TLS 1.3

    Quote Originally Posted by couttsj View Post
    How did you handle maximum record size (2^14)? I think this may be part of my problem.
    For sending or while receiving data?

    RFC 8446: "The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result."

    So the protocols on the higher layer (handshake, alert, application data) deal with unlimited message sizes which get chunked (w/ chunks subsequently getting encrypted) by the record layer underneath. This supposes that large handshake messages (e.g. ones with large and a serveral server certificates) can easily get spanned on multiple record frames so this has to be expected (buffered) on receive and appropriately chunked on send.

    This is how I buffer handshake protocol currently received message (in .MessBuffer) if it spans multiple (encrypted) record frames. This implementation allows record layer to chunk handshake messages at random boundaries, not necessary coinciding the beginning of the handshake message with the beginning of the record layer frame although in practice never seen a TLS server (neither openssl nor firefox) chunk so randomly/aggresively.

    Application data buffering on receive is handled by each application protocol impl (e.g. http protocol buffers headers until double vbCrLf is received) so this is not handled by my TLS implementation.

    cheers,
    </wqw>

  27. #107

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,035

    Re: Simulate TLS 1.3

    Quote Originally Posted by wqweto View Post
    For sending or while receiving data?

    RFC 8446: "The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result."

    So the protocols on the higher layer (handshake, alert, application data) deal with unlimited message sizes which get chunked (w/ chunks subsequently getting encrypted) by the record layer underneath. This supposes that large handshake messages (e.g. ones with large and a serveral server certificates) can easily get spanned on multiple record frames so this has to be expected (buffered) on receive and appropriately chunked on send.

    This is how I buffer handshake protocol currently received message (in .MessBuffer) if it spans multiple (encrypted) record frames. This implementation allows record layer to chunk handshake messages at random boundaries, not necessary coinciding the beginning of the handshake message with the beginning of the record layer frame although in practice never seen a TLS server (neither openssl nor firefox) chunk so randomly/aggresively.

    Application data buffering on receive is handled by each application protocol impl (e.g. http protocol buffers headers until double vbCrLf is received) so this is not handled by my TLS implementation.

    cheers,
    </wqw>
    Sorry for the question, but it looks like I already handled it in the server program. The client program is capable of handling any record size up to 65,536 bytes, but the server only dishes out records up to 16,362 bytes. What threw me off was the non-secure part of the client program receiving records of 1,460 bytes, which is the packet size.

    J.A. Coutts

Page 3 of 3 FirstFirst 123

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