W3Mfc v2.13

Just to let everyone know that v2.13 of W3Mfc has been released. Updates for this version include:

• Provided a new CW3MFCClient::PreHandle which allows handling of any HTTP verbs.

AppSettings v1.21

Just to let everyone know that v1.21 of AppSettings has been released. Updates for this version include:

• Removed the String CAppSettingsException::GetErrorMessage method. This avoids compile problems when the code is compiled in a project which is not using C++ 17.
• Fixed up other compile problems in the module when the code is compiled in a project which is not using C++ 17.

Advertisement

TLS v1.3 support finally on Windows!

As some of you may know I developed and maintain a set of C++ classes called SSLWrappers to encapsulate the TLS / SSL functionality exposed by Windows through it’s Schannel SSPI component. This provides the built-in TLS functionality in Windows and is roughly equivalent to the OpenSSL library in the Open-Source world. I have used Schannel and my support classes in a number of work and personal projects, and because it is built in to Windows is one less third party library you need to pull into your projects when you require low level TLS functionality. I actively use the SSLWrappers classes in my W3MFC, CPJNPOP3Connection and CPJNSMTPConnection Open-Source libraries. Chromium on Windows, Edge (as well as the newer “Edge on Chromium”), Internet Explorer and IIS all use SChannel internally for their TLS functionality. Also many of the higher level components in Windows such as WinHTTP and Windows Update internally also use Schannel for their HTTPS functionality.

The latest revision of TLS namely v1.3 was ratified as RFC 8446 back in August 2018. I have been monitoring new versions of Windows 10 client and Windows Server since mid 2018 to see when they would support TLS v1.3. The most recent references I can find from Microsoft about modernizing TLS in Windows is https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/ from October 2018 but this only makes oblique references to if / when TLS v1.3 will be available on Windows.

What I have just discovered and can now reveal today probably for the first time by anyone outside of Microsoft is that TLS v1.3 is now included inbox in Windows 10 v1903 and Windows Server 1903. By default support for TLS v1.3 is disabled in these versions of Windows but if you enable it using the expected registry values for TLS v1.3 Schannel you can get it to work.

To enable TLS v1.3 in either of these versions of Windows you should import the following registry file into your registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001

This will enable the client side of TLS v1.3 in Windows and a reboot is not required for these changes to take effect, which is nice. If you want you can substitute the “Client” value above for “Server” and then import it also. The latter import will enable the server side of TLS v1.3 on Windows. Note that importing this .reg file on earlier versions of Windows such as Windows 10 1809 or Window Server 1809 seems to have no effect, meaning that TLS v1.3 is not supported on these earlier versions of Windows.

To test out TLS v1.3 support, you should then take the SSLWrappers sample app of mine and modify the code to include the additional line in red below at about line number 1079 and recompile:

//Create the credentials
SSLWrappers::CCachedCredentials credentials;
memset(&credentials.m_sslCredentials, 0, sizeof(credentials.m_sslCredentials));
credentials.m_sslCredentials.dwVersion = SCHANNEL_CRED_VERSION;
credentials.m_sslCredentials.grbitEnabledProtocols = SP_PROT_TLS1_3;
if (g_bManualServerCertificateValidation) //If we want to do manual server certificate validation, then ask SChannel not to do it automatically for us
  credentials.m_sslCredentials.dwFlags = SCH_CRED_MANUAL_CRED_VALIDATION;
status = credentials.Acquire(SECPKG_CRED_OUTBOUND, &credentials.m_sslCredentials);

Adding this line will force the demo app to only negotiate using TLS v1.3 and not to fall back to TLS v1.2 or lower. Then if you use the command line:

SSLWrappersDemo.exe 0 www.google.com 443

the demo app will try to make a TLS v1.3 connection to www.google.com. What you should see on Windows 10 1903 and Server 1903 is the following:

Connecting to http://www.google.com:443
Performing SSL client handshake
–SECPKG_ATTR_CONNECTION_INFO_EX_V1 details–
Version: 0x1
Protocol: TLS v1.3
Cipher: AES
Cipher Strength: 0x100
Hash:
Hash Strength: 0x0
Exchange:
Exchange Strength: 0x0
–SECPKG_ATTR_CONNECTION_INFO details–
Protocol: TLS v1.3
Cipher: AES
Cipher strength: 256
Hash: SHA-384
Hash strength: 0
Key exchange algorithm identifier: 0x0, Class:0, Type:0, SID:0
Key exchange strength: 0
–SECPKG_ATTR_CIPHER_INFO details–
Version: 0x1
Protocol: 0x304
Cipher Suite: 0x1302
Base Cipher Suite: 0x1302
Cipher Suite: TLS_AES_256_GCM_SHA384
Cipher: AES
Cipher Length: 256
Cipher Block Length: 16
Hash:
Hash Length: 0x0
Exchange:
Exchange Min Length: 0
Exchange Max Length: 0
Certificate:
Key Type: 0x1d
–SECPKG_ATTR_APP_DATA details–
Session app data: Length:0,

…

 

This shows the sample app negotiating a TLS v1.3 connection to google.com using the TLS_AES-256-GCM_SHA384 cipher. FYI, TLS v1.3 has a much reduced set of supported ciphers. I have tried other TLS v1.3 servers on the Internet as documented at https://github.com/tlswg/tls13-spec/wiki/Implementations#test-servers but the only one I could get to work was www.google.com. If you try running the same modified version of the SSLWrappers demo app on earlier versions of Windows you will see it consistently failing while attempting the client TLS handshake with any TLS v1.3 server. Most of the other servers I tried failed when trying to negotiate the client TLS handshake. I also could get the client run of the demo app to connect to the server implementation of TLS v1.3 using the command line:

SSLWrappersDemo.exe 0 localhost 443

to run the server and then using the following command line to connect to that server as a client:

SSLWrappersDemo.exe 1 localhost 443

Please see the documentation for SSLWrappers on how to setup and test the code and certificates for this loopback test.

This investigation proves that Microsoft is shipping a functional TLS v1.3 implementation in their most current version of Windows client and server, but it remains to be seen when Microsoft will officially announce this support. It could even be the case that it will not be officially supported by MS until the next release of Windows 10 and Windows Server in Q3 2019. Come on Microsoft, tell us when we can start officially using TLS v1.3 on Windows.

 

Happy Coding!

CSelectCertificateDlg v1.08

Just to let everyone know that v1.08 of CSelectCertificateDlg has been released. Updates for this version include:

• Updated copyright details.
• Updated the code to clean compile on VC 2019

DtWinVer v2.32

Just to let everyone know that v2.32 of DtWinVer has been released. Updates for this version include:

• Added support for the following product types: PRODUCT_XBOX_SYSTEMOS, PRODUCT_XBOX_NATIVEOS, PRODUCT_XBOX_GAMEOS, PRODUCT_XBOX_ERAOS & PRODUCT_XBOX_HOSTOS

CPdh v1.20

Just to let everyone know that v1.20 of CPdh has been released. Updates for this version include:

• Updated copyright details.
• Updated the code to clean compile on VC 2019

DDXFolder & CChooseDirDlg v1.44

Just to let everyone know that v1.44 of DDXFolder & CChooseDirDlg has been released. Updates for this version include:

• Updated copyright details.
• Updated the code to clean compile on VC 2019

DDXFile v1.30

Just to let everyone know that v1.30 of DDXFile has been released. Updates for this version include:

• Updated copyright details.
• Updated the code to clean compile on VC 2019

GPSCom2 v1.08 / IConnectionPointImplMT v1.09

Just to let everyone know that v1.08 of GPSCom2 and v1.09 of IConnectionPointImplMT has been released. Updates for this version include:

• Updated copyright details.
• Updated the code to clean compile on VC 2019
• Reworked the IConnectionPointImplMT::m_Clients array to store the store the cookie instead of the GIT pointers since you can always get the GIT pointers from them. This also allowed easier lookups so a simpler implementation of Unadvise can be made. Thanks to Michael Ford for this nice addition.

CFTPTransferDlg & CFTPTransferer v1.19

Just to let everyone know that v1.19 of CFTPTransferDlg & CFTPTransferer has been released. Updates for this version include:

• Updated copyright details.
• Updated the code to clean compile on VC 2019