Troubleshooting a TLS 1.3 connection is not easy. Because I was having difficulty getting "curve25519" to work properly in Win 10/11, I decided to implement a simulation program that I could step through.
Even though "ECDH_P256" and "curve25519" are both theoretically ECDH algorithms, there are slight differences. This is a result of the way that MS handles X22519 in relation to the other ECDH algorithms. ECDH_P256, ECDH_P384, and ECDH_P512 fit well into the MS nomenclature, but X25519 does not. There was originally a distrust in CISA as to the provision of back doors in the protocols, so X25519 was adopted as an alternative. X25519 is not supported in Windows versions prior to part way through Win 10. In theory, X25519 is faster than the others, but I cannot substantiate that, at least not from a client perspective using VB6.
In the attached program, I have retained the networking class and module for a couple of reasons. There are a few routines in them that are still used, and it shows the similarity between the network code and the command buttons that I have used in the simulation. The network code is found in the sub TCP.
The ECDH_P256 routine simulates an actual connection to the Gmail SMTP server. The network traffic was recorded using PacketVB, while DebugPrintByte statements recorded the various calculation results in the Client.
The X25519 routine parallels the Simple 1-RTT Handshake routine in RFC 8448. To simplify the comparison, I have included a text file (RTT_HS.txt), that restructures the text to better coincide with our program.
In naming the variables for the simulation, "X" is used for X25519 related items, "P" is used for ECDH_P256, "C" is used for Client, and "S" is used to represent Server related items. It is hopeful that this simulation will help VB6 programmers better understand TLS 1.3.
J.A. Coutts
Updated: 06/18/2025 - See post #2 for details
Updated: 09/04/2025 - See post #20 for details
Last edited by couttsj; Sep 4th, 2025 at 04:14 PM.
Reply With Quote