SSL 2.0 with mdTlsNative as server, web browser as client gets no response back

[KalleAnka]

Hi,

Tried to test SSL 2.0 with TlsSocket(compiled with mdTlsNative).
Don't think I'll find SSL 2.0 on anything used today but fun testing it if it works :).

Server: Windows XP SP2 x86.
Client: Windows 2003 SP2 x64 Internet Explorer 6 with TLS 1.0 and SSL 3.0 disabled(=only SSL 2.0 enabled).

Wireshark on Server shows that the Server gets a SSL 2.0 Client Hello but does not respond(only TCP ACK is sent back).

Testing the same as above but with SSL 3.0 enabled on Client works.
Also with TLS 1.0 enabled on Client Works.

Also tested Internet Explorer 6 on the Server to try to access TlsSocket on 127.0.0.1 but no response and I'm unable see anything local with WireShark.

Any hints on were to start to try to find the problem?

[wqweto]

Or is it built for TLS 1.0 - TLS 1.3(if the OS supports them)?

I just realized this question of yours in another thread is actually quite relevant i.e. by default native backend uses ucsTlsSupportAll for local features but this actually limits grbitEnabledProtocols bitmask to TLS 1.0, 1.1, 1.2 and 1.3

After commit 7d20880 in the default case of ucsTlsSupportAll no explicit bits in grbitEnabledProtocols (and newer grbitDisabledProtocols) are set in order for Schannel to use registry defaults for supported protocols which should have been the case in first place.

[wqweto]

Another caveat w/ ucsTlsSupportAll setting (i.e. using default protocols) on POSReady version of XP is that by default TLS 1.1 and TLS 1.2 are excluded in registry from the default protocols set but you can still explicitly request ucsTlsSupportTls12 (or ucsTlsSupportTls11) as these protocols are available outside the default protocols set when not explicitly disabled in registry.

For the native backend to support TLS 1.1 and TLS 1.2 when using default ucsTlsSupportAll setting these protocols have to be included in the default set of protocols in registry like this

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000

After switching off DisabledByDefault in registry you can expect native backend on POSReady to implement SSL2, SSL3, TLS 1.0, TLS 1.1 and TLS 1.2 server-side protocols when using certificate in Personal certificate system store as reported by SSL Labs testing a VM here.

Unfortunately TLS 1.2 is still missing w/ self-signed certificates.

[wqweto]

Yet another caveat w/ ucsTlsSupportAll on Win10+ is that TLS 1.3 support uses brand new Schannel implementation through brand new Schannel API (after build 20348 of the OS) which by design does not support SSL3 and below.

But native backend still uses old Schannel API when no TLS 1.3 is requested (or OS does not support new Schannel API) so on Win10+ requesting ucsTlsSupportTls10 Or ucsTlsSupportTls11 Or ucsTlsSupportTls12 effectively uses old Schannel implementation with default set of protocols from registry.

Using this exact combined setting for LocalFeatures parameter allows native backend to support SSL3 and SSL2 on Win10+ when corresponding registry settings are tweaked (needless to say these insecure protocol are disabled by default) with someting like this

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[KalleAnka]

Thanks for commit 7d20880
Server SSL 2.0 native now works :).

Now

SSL 2.0
SSL 3.0
TLS 1.0
TLS 1.1(with POSReady)
TLS 1.2(with POSReady and import of certificate)

work as server native on Windows XP x86 SP3.

And if TLS 1.3 server is need on Windows XP, mdTlsThunks makes it work.