Possible using mdTlsThunks for a TLS 1.0 server?

[KalleAnka]

Hi everybody,

I'm trying to interface with a embedded hardware which seems to only use TLS 1.0(looking at the traffic with WireShark) for it's encrypted traffic.

The hardware presents 24 suites of ciphers according to WireShark.

I've used the sample TlsSocketTest with #Const ImplExotictCiphers = True.
Running debug on mdTlsThunks shows the following error:

Invalid protocol version (&H301).

VB6 on Windows XP x86 SP3.

Compiling the TlsSocketTest instead with native module and running binary on Windows 10 works.

What am I doing wrong?

Thanks.

[wqweto]

No, TLSv1 is not supported by mdTlsThunks because TLSv1 is a completely different protocol with different internals basically everything.

Initially mdTlsThunks was a TLS 1.3 only implementation which got 1.2 version bolted at the price of obfuscating the code immensely. Another transplant would be devastating and besides TLSv1 is obsolete for some years now so the incentive to self-inflict this is very low.

mdTlsNative uses OS provided Schannel library so it supports everything the version of Windows brings, incl. TLSv1 if enabled in registry.

[KalleAnka]

Got it.
Thanks for the quick reply!

Follow-up question:
I'm getting the following error message when using mdTlsNative on Windows XP x86 SP3:

mdTlsNative.TlsHandshake AcquireCredentialsHandle The credentials supplied to the package were not recognized

It is with the same embedded hardware as in the thread starter. TLS 1.0 is requested but in this case, TlsSocket.exe does not even respond back to the hardware.

Is Windows XP SP3 not TLS 1.0 aware?

[wqweto]

Is Windows XP SP3 not TLS 1.0 aware?

Stock XP SP3 by default supports server-side TLS 1.0 but the list of supported ciphersuites is limited so your embedded client might fail to negotiate a matching one.

Here is what SSL Labs Server Test reports:

# TLS 1.0 (suites in server-preferred order)
TLS_RSA_WITH_RC4_128_MD5 (0x4)                  INSECURE    128
TLS_RSA_WITH_RC4_128_SHA (0x5)                  INSECURE    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)             WEAK        112
TLS_RSA_WITH_DES_CBC_SHA (0x9)                  INSECURE    56
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64)       INSECURE    56
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62)      INSECURE    56
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)            INSECURE    40
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)        INSECURE    40

# SSL 3 (suites in server-preferred order)
TLS_RSA_WITH_RC4_128_MD5 (0x4)                  INSECURE    128
TLS_RSA_WITH_RC4_128_SHA (0x5)                  INSECURE    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)             WEAK        112
TLS_RSA_WITH_DES_CBC_SHA (0x9)                  INSECURE    56
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64)       INSECURE    56
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62)      INSECURE    56
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)            INSECURE    40
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)        INSECURE    40

# SSL 2 (client selects suite)
SSL_CK_RC4_128_WITH_MD5 (0x10080)               INSECURE    128
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (0x700c0)      INSECURE    112
SSL_CK_RC2_128_CBC_WITH_MD5 (0x30080)           INSECURE    128
SSL_CK_DES_64_CBC_WITH_MD5 (0x60040)            INSECURE    56
SSL_CK_RC4_128_EXPORT40_WITH_MD5 (0x20080)      INSECURE    40
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 (0x40080)  INSECURE    40

There is a POSReady version of XP which added support for TLS up to version 1.2 and here is the list of supported ciphersuites (still no AES-GCM so everything is weak and insecure)

# TLS 1.2 (suites in server-preferred order)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)          WEAK        256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)          WEAK        128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)             WEAK        256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)             WEAK        128
TLS_RSA_WITH_RC4_128_MD5 (0x4)                  INSECURE    128
TLS_RSA_WITH_RC4_128_SHA (0x5)                  INSECURE    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)             WEAK        112

# TLS 1.1 (suites in server-preferred order)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)             WEAK        256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)             WEAK        128
TLS_RSA_WITH_RC4_128_MD5 (0x4)                  INSECURE    128
TLS_RSA_WITH_RC4_128_SHA (0x5)                  INSECURE    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)             WEAK        112

# TLS 1.0 (suites in server-preferred order)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)             WEAK        256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)             WEAK        128
TLS_RSA_WITH_RC4_128_MD5 (0x4)                  INSECURE    128
TLS_RSA_WITH_RC4_128_SHA (0x5)                  INSECURE    128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)             WEAK        112
TLS_RSA_WITH_DES_CBC_SHA (0x9)                  INSECURE    56
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64)       INSECURE    56
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62)      INSECURE    56
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)            INSECURE    40
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)        INSECURE    40

mdTlsNative.TlsHandshake AcquireCredentialsHandle The credentials supplied to the package were not recognized

Note that due to a bug mdTlsNative failed initializing server-side Schannel on XP when using non-system certificates (incl. any generated self-signed certificate) which is fixed in 77b2412 in master but there is no release of compiled DLLs yet.

[KalleAnka]

Thanks for the fix in 77b2412!
Server: TlsSocket(native) Windows XP x86 SP3 with POSReady: TLS 1.0 and TLS 1.1 are working.
Server: TlsSocket(native) Windows XP x86 SP2: TLS 1.0 is working.
Client: SecureNative Windows XP x86 SP3 with POSReady: TLS 1.0, TLS 1.1 and TLS 1.2 are working.
:)

One interesting thing is that TLS 1.2 is not working with Server: TlsSocket(native) Windows XP x86 SP3 with POSReady. In this case I am using a web-browser for the test that is able to negotiate TLS 1.2. But using Thunks instead of native works with TLS 1.2.

[wqweto]

Yes, for some reason TLS 1.2 is not working with non-system (incl. self-signed) certificates.

If you import the server certificate into Personal certificate store (using certmgr.msc) and use a valid CertSubject parameter on InitServerTls method then TLS 1.2 works too.

I just revisted this part of the native backend but couldn't figure out what is wrong with it so I'll assume a bug in POSReady's implementation.

[KalleAnka]

Thanks :).
Server TLS 1.2 native works after importing certificate into store.

[gaouservbf]

Hi everybody,

I'm trying to interface with a embedded hardware which seems to only use TLS 1.0(looking at the traffic with WireShark) for it's encrypted traffic.

The hardware presents 24 suites of ciphers according to WireShark.

I've used the sample TlsSocketTest with #Const ImplExotictCiphers = True. Running debug on mdTlsThunks shows the following error:

Invalid protocol version (&H301).

VB6 on Windows XP x86 SP3.

Compiling the TlsSocketTest instead with native module and running binary on Windows 10 works.

What am I doing wrong?

Thanks.

Windows' built-in cr*ppy TLS could do it as I remember. But you are on WinXP, POSReady 2009 certificates expired a short time ago(around beginning of the year). Not even SSL 3.0 will work, I'm not sure if wqweto is even wants to implement TLS 1.0. In the time your post was written, WinHTTP wouldve worked fine. Not now tho

[gaouservbf]

If the hardware is a well known chip/contains one, and the source code is available. I may try assisting to migrate the MCU's code instead, I got atleast some experience with Arduino and ESP.