dcsimg
Results 1 to 5 of 5

Thread: Vb6 - tls 1.3 demo

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    612

    Vb6 - tls 1.3 demo

    This application is an extension of the AES Demo that I posted previously. That demo was put together to demonstrate the use of AES in TLS 1.2, and to test my own encryption algorithm against an established algorithm. I believe my own algorithm is as safe as any established algorithm, but a good algorithm should also be fast. My own algorithm turned out to be about 3 times slower than AES on long encrypts. So I set out to update my TLS program, and that is when I discovered TLS 1.3.

    The final draft of TLS 1.3 was released on Mar 20, 2018, and implementation is in it's infancy. Mozilla Firefox has TLS 1.3 enabled by default starting at Version 60, and Versions 52-60 can be enabled by adjusting the SSL Version to 4. But that does not mean that all versions will work with all TLS 1.3 Web sites. It all depends on which draft each is compiled to work with. Why did I choose to use such a new protocol? Because TLS 1.3 is faster, simpler, and more secure. It only uses ECC (Elliptical Curve Cryptography) to transfer the Pre-Master key, one complete round trip has been eliminated, and several functions have been relegated to being ignored. A good overview can be found here:

    https://blog.cloudflare.com/tls-1-3-...w-and-q-and-a/

    And why did I choose AES as the encryption protocol? The recommended cipher suites to use with TLS 1.3 are:

    0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    0x00,0x9F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    0x00,0xAA TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
    0x00,0xAB TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
    0x13,0x01 TLS_AES_128_GCM_SHA256
    0x13,0x02 TLS_AES_256_GCM_SHA384
    0x13,0x03 TLS_CHACHA20_POLY1305_SHA256
    0x13,0x04 TLS_AES_128_CCM_SHA256
    0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    0xC0,0x2C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    0xC0,0x9E TLS_DHE_RSA_WITH_AES_128_CCM
    0xC0,0x9F TLS_DHE_RSA_WITH_AES_256_CCM
    0xC0,0xA6 TLS_DHE_PSK_WITH_AES_128_CCM
    0xC0,0xA7 TLS_DHE_PSK_WITH_AES_256_CCM
    0xCC,0xA8 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    0xCC,0xA9 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    0xCC,0xAA TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    0xCC,0xAC TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
    0xCC,0xAD TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
    0xD0,0x01 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
    0xD0,0x02 TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384
    0xD0,0x05 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256

    Notice that most of them use AES. For this demo, we use none of the above. Instead we use a default Anonymous suite. Anonymous suites are not recommended for any TLS version because the server cannot be authenticated using Certificates. This particular demo will not yet be completely TLS 1.3; it will be more like a combination of TLS 1.2 & 1.3. That is because I am still trying to extract the implementation details. For example, the Server Finish would normally be transferred encrypted with the Certificate data, but for personal use the expense of Certificates just isn't warranted. So I transferred the Finished record unencrypted with the Server Hello. On the Client side, the Finished record is transferred by itself unencrypted, after receiving the Server Finished record.

    To say that this demo is complicated would be an understatement, and it is by no means complete. I contemplated not using HMAC records, but HMAC was engrained in the code I was upgrading. The IETF provided Example Handshake Traces for TLS 1.3 here:

    https://tools.ietf.org/html/draft-ie...s13-vectors-03

    but as usual RFC documents are not the easiest thing to follow. As well, the examples all used curve x25519, which is only supported on Windows 10. The difficulty with Windows 10 is that I have still not found a way to recover the raw Agreed Secret, which is required if you are going to connect with a real world server using TLS 1.3.

    To test these 2 programs, set up 2 VB6 IDEs and run the Client program in one and the Server program in the other. All the modules are common to each program. The Server program will listen on port 443. In the Client program, click the dropdown arrow, and choose the "localhost" option. This will attempt to connect with the Server using the loopback address 127.0.0.1. If successful, the Client will send the Client Hello, which includes the Client Random and the Public Key for the "ECDH_P256" curve under the name "key share". A full breakdown of the Client Hello is included in the code.

    The server receives the Client Hello and has enough information to create the AgreedSecret and Master Key. Using the Master Key and Random values, the Server then creates the various keys used in the encryption process (Read MAC Key, Write MAC Key, Read Key, Write Key, Read IV, & Write IV). Now it can send its own Server Hello along with the Server Finished record back to the Client. Once again, a full breakdown of the Server Hello is included in the code.

    The Client receives the Server Hello and creates it's own AgreedSecret and Master Key, which should be the same as those created by the Server. It then creates all the keys that it needs and sends a Client Finished record back to the Server.

    Both programs should now be ready to send and receive encrypted messages. Click on the "Send Sample" button to send a sample message to the Server. Likewise, click on the "Send Response" button to send a response back to the Client.

    It is my hope that you find these programs educational.

    J.A. Coutts
    Attached Images Attached Images  
    Attached Files Attached Files
    Last edited by couttsj; Aug 8th, 2018 at 10:06 AM.

  2. #2
    Fanatic Member wqweto's Avatar
    Join Date
    May 2011
    Posts
    818

    Re: Vb6 - tls 1.3 demo

    Let me share what comes to my mind when looking at this submission. To produce something useful in crypto you'll need to provide plethora of solid *primitives* -- hashes, keys, exchanges, encryption, sockets, error handling, VB6 convenience wrappers, etc.

    For this to happen you'll need to accumulate some solid *understanding* on the topic -- when to use CNG, when to re-write algos from scratch, crypto's best practices, how to act paranoid if desired, etc.

    For this to happen you'll need to *read* lot's of high quality code (not write, not VB6) -- try TLS in nginx, haproxy, even curl is very interesting, then if the interest is not dwindled try openssl, libressl (only for the bravest), etc.

    At present you are building on shaky foundations and I only glimpsed at winsock helper for instance.

    Just my $.02 worth of unasked advice and please ignore all of this if it does not ring true with you.

    cheers,
    </wqw>

  3. #3

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    612

    Re: Vb6 - tls 1.3 demo

    If someone could/would provide a library file that could do all the things I want to do, I would jump on it in a heartbeat. But that is simply not the case. Amongst it's many shortcomings, MSWINSCK does not support IPv6. I could have supplied SimpleSock as a DLL, but that would have hidden the ability to make subtle changes. The same with AES. It would be nice to roll it all into a convenient library file, but considering how fast the standards change, it would be on ongoing battle. And for someone who is providing all this ground breaking code for free, there is no incentive to do that. VB6 still provides the ability to get around code limitations. Support files like .NET are slow to respond to changes in the environment, and that means that you have to code to a lower level to remain current.

    J.A. Coutts

  4. #4
    Fanatic Member wqweto's Avatar
    Join Date
    May 2011
    Posts
    818

    Re: Vb6 - tls 1.3 demo

    Quote Originally Posted by couttsj View Post
    And for someone who is providing all this ground breaking code for free, there is no incentive to do that.
    Looking for monetary incentive? For this ground breaking code?

    You have to be trolling me very badly :-))

    cheers,
    </wqw>

  5. #5

    Thread Starter
    Fanatic Member
    Join Date
    Dec 2012
    Posts
    612

    Re: Vb6 - tls 1.3 demo

    In theory, this version contains all of the TLS 1.3 Simple connection code. I have to say in theory because it is difficult to verify. The sample traces provided in the link in the first post use the x25519 ECC curve which my Win 8.1 computer does not support, and Microsoft does not provide a way to recover the required Raw Agreed Secret.

    This demo has been challenging to say the least, as there is not a great deal of technical detail available on TLS 1.3, and what little there is has had a tendency to change. But overall, I can say that I am fairly impressed with the job that the IETF has done on this one.

    There are lots of comparisons between TLS 1.2 & TLS 1.3 available on the Net, but they operate at a cursory level rather than with the technical detail that comes with trace examples. So I will attempt to point out some of the major differences at the code level.

    The most obvious difference is the use of HKDF instead of PRF as I have outlined in the HKDF post.

    The next thing that stands out is use of two different sets of keys. One set is used during the Handshake process, while the other is used for Application data. After connecting, the Client sends the Client Hello unencrypted. The Server then responds with the Server Hello unencrypted. Each Hello contains the Public ECC key, which is combined with the Private ECC key to calculate the same Agreed Secret. The Server actually calculates the Agreed Secret and Handshake keys before it sends the Server Hello. That allows the Server to use the Handshake keys to encrypt the Certificate data as well as the Server Finished record and send them to the Client. This demo does not support Certificate data.

    The Client receives the Server Hello, creates the Agreed Secret from the Servers Public ECC key and it's own Private ECC key, calculates the Handshake keys, decrypts the Server Finished message, calculates the Application keys, and returns it's own Finished message. In theory, the Server should wait for the Client Finished message to calculate the Application keys, but it has already done so before it is actually received.

    The next notable thing that stands out is the lack of a general use IV (Initialization Vector) and MAC key. The IV was previously used to protect the encryption key from being hacked when using a block algorithm, and the MAC key was used to calculate the 12 byte MAC value added to each record to protect the record from being modified during transit (MAC then Encrypt). Instead, each set of keys has it's own IV, which is used to provide AEAD (Authenticated Encryption with Associated Data). The demo uses AES-128-GCM, which is an AEAD algorithm. The advantage of using AEAD is that the encryption is done at the same time as the MAC, and the encrypted length is the same as the data length. This is accomplished using a Nonce, which combines the Sequence Number with the IV.

    Using these techniques allows TLS 1.3 to eliminate one complete round trip that was previously required to exchange keys. The use of ECDHE keys provides Forward Secrecy, which vastly improves security.

    The downside of all this is more complexity in the creation and handling of keys. As well, you used to be able to add records to the Session Hash as they were sent or received, but that is no longer possible. Because some Handshake records are combined with other records, and some are encrypted and some are not, it creates a very convoluted and difficult process to follow. The fact that the keys cannot be calculated all at one time (I use 3 phases), adds to the maze.

    To use this demo, open 2 IDE project environments and load the Client software in one, and the Server software in the other. Start each one and display both forms in different parts of the screen. The Server will listen on port 443. On the Client form, click the dropdown icon and click the localhost URL. As long as localhost is properly defined in the "Host" file, it should connect to the Server using IP address 127.0.0.1. From there, the two programs should negotiate a secure connection with the relative key information displayed in the text boxes. Click the "Send Sample" button on the Client to send an encrypted message to the Server. Likewise, click the "Send Response" button on the Server to send an encrypted response to the client.

    The purpose in developing this demo was to gain familiarity with the process so that I could develop a secure one-to-one communication system. From here, I will remove much of the code that provides facility specific to TLS 1.3 and backwards compatibility with TLS 1.2, and post it separately. For example, the Server/Client Randoms are no longer used, but are retained for backwards compatibility.

    J.A. Coutts
    Attached Images Attached Images  
    Attached Files Attached Files
    Last edited by couttsj; Sep 21st, 2018 at 04:00 PM.

Posting Permissions

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



Featured


Click Here to Expand Forum to Full Width