windows_hardening icon indicating copy to clipboard operation
windows_hardening copied to clipboard

TLS settings Enabled value to 1

Open pmatula opened this issue 2 years ago • 6 comments

The finding_list_microsoft_windows_tls and finding_list_microsoft_windows_tls_future checks the enabled status with the value 0xffffffff (4294967295).

That is correct regarding: https://docs.microsoft.com/en-US/troubleshoot/windows-server/windows-security/restrict-cryptographic-algorithms-protocols-schannel

But it seems wrong regarding: https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings

The situation is well summarized here: https://www.nartac.com/Products/IISCrypto/FAQ/Why-does-iis-crypto-set-the-protocols-enabled-value-to-0xffffffff.

So, it seems that the value 1 is "more correct and generates fewer errors". There are also several Github issues (like that: https://github.com/MicrosoftDocs/windowsserverdocs/issues/6203) to correct the MS documentation.

I think it would therefore be a good idea to adjust this in both lists?

pmatula avatar Jul 29 '22 09:07 pmatula

Good input, thank you very much. I will update both lists and add an additional reference to the README

0x6d69636b avatar Jul 29 '22 17:07 0x6d69636b

I did further testing. If you set everything to 1 RDP is broken. The error message in the eventlog is that: An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed. The SSPI client process is svchost[TermService] (PID: 1296).

The configuration which seems to work is to set all hashes (sha256,sha384 and sha512) and all KeyExchangeAlgorithms (Diffie-Hellman, ECDH and PKCS) with 0xffffffff

It seems like the enabled -> 1 value is fine for Ciphers and Protocols (under SCHANNEL) but not for Hashes and KeyExchangeAlgorithms.

I tested it only with my machine .. so maybe it would make sense to check it with a second device.

pmatula avatar Aug 03 '22 08:08 pmatula

Thanks for the testing. On which OS did you test that? Maybe it differs from the OS version

0x6d69636b avatar Aug 03 '22 18:08 0x6d69636b

indeed. Server 2022.

pmatula avatar Aug 03 '22 19:08 pmatula

Hm, if it does not work with 2022, then I rollback the changes as you mentioned:

The configuration which seems to work is to set all hashes (sha256,sha384 and sha512) and all KeyExchangeAlgorithms (Diffie-Hellman, ECDH and PKCS) with 0xffffffff

I do not believe it would work on older versions

0x6d69636b avatar Aug 03 '22 19:08 0x6d69636b

yep, at least it works for me :-) thanks.

pmatula avatar Aug 03 '22 19:08 pmatula