If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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:

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:

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.

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.

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.

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.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.