Closed lordfiSh closed 3 years ago
I like it. HardeningKitty has no specific scope, I'm up for anything that improves the security of Windows. I'll take a look at your list and add it to the repo
I changed the categories and names, added some .NET findings. Here is the new list: https://github.com/0x6d69636b/windows_hardening/blob/master/lists/finding_list_microsoft_windows_tls.csv. What do you think?
Depending on the minimum version of Windows it will run on, you could possibly add rules for TLS 1.3 support (W10 1903+)
Do you have any idea which TLSv1.3 cipher suites are supported in W10 1903+? As far as I know TLSv1.3 is only supported for testing purposes (source https://devblogs.microsoft.com/premier-developer/microsoft-tls-1-3-support-reference/). But I can add this checks and rate them as Low
I found some information for cipher support in Windows Server 2022: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-server-2022
Like it's mentioned in you second link, the 3 standardized ciphers for TLS 1.3 are supported on W10 1903+ (AES256/AES128/ChaCha20).
ChaCha20 is disabled by default, but it should be possible to re-enable it by modifying the SSL cipher suite order with the related GPO/registry key : https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.CypherStrength::SSLCipherSuiteOrder
I've added TLSv1.3 to the list and added another cipher suite check with the new TLSv1.3 ciphers
Maybe there should be a Config for newer Windows Version (TLS1.3 + ChaCha20/Poly1305). For example the BSI (German Federal Office for Information Security) doesn't mention them in the Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths
@0x6d69636b thanks for the clean-up of the config 👍
Hm, you might be right. I've created another list called Future Use with TLSv1.3 to avoid confusion when scanning "older" versions of Windows
Maybe there should be a Config for newer Windows Version (TLS1.3 + ChaCha20/Poly1305). For example the BSI (German Federal Office for Information Security) doesn't mention them in the Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths
@0x6d69636b thanks for the clean-up of the config 👍
ChaCha20 (and it's combination with Poly1305 for authenticated encryption) is recommended in the latest cryptographic recommendations by ANSSI (equiv. BSI in France, recommendations updated in March 2021): https://www.ssi.gouv.fr/uploads/2021/03/anssi-guide-selection_crypto-1.0.pdf
A specific guide regarding TLS connections was also updated in March 2020 to add recommendations related to TLS 1.3: https://www.ssi.gouv.fr/uploads/2017/07/anssi-guide-recommandations_de_securite_relatives_a_tls-v1.2.pdf
Also related to TLS configuration, should the CSV also mention the ECC curve order ? On W10 systems, by default the order of priority is Curve25519, NIST P-256 and NIST P-384. Latest DISA STIGs for W10 systems recommend to swap P-256 and P-384 to prioritize higher bits count curves, and most TLS hardening guides apply the same logic.
The related registry key is the following: https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.CypherStrength::SSLCurveOrder
I've added ECC Curve Order to the TLS lists and changed the categorie/name for ECC Curve Order and Cipher Suite, because both those options can be configured over an official windows policy (Commit https://github.com/0x6d69636b/windows_hardening/commit/e7f679ed694895e9c1e9250f5c35d242a3e83d43)
Sounds good !
Just for my own culture, what is the rationale you applied for the cipher suite order, at https://github.com/0x6d69636b/windows_hardening/blob/master/lists/finding_list_microsoft_windows_tls_future.csv#L46 ? Why ChaCha20, then AES128, then AES256 ?
I chose ChaCha20 frist because of the recommendation from the OpenSSH config (see https://cipherlist.dev/ -> OpenSSH) and AES 128 before AES 256 beause of the recommendation in the SSL and TLS Deployment Best Practicies (see https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#31-avoid-too-much-security). However, I see that it would be consistent to prefer AES 256 before AES 128, as this is also done in TLSv1.2. I'll switch those
Don't know if this is out of your Scope but I created a Idea of a Config to Audit the TLS Settings for Windows (Based on https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12)