Setting the TLS 1.1 and 1.2 setting creates a "Default" registry key DWORD of 1.

[sheehand]

After using this in my lab, and then in production, we noticed after setting TLS 1.1 and 1.2 to enabled, that the "Default" registry key for Client and Server sub-sections was changed from a string to a DWORD type, and set to the value of 1. For example:

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

Any idea how/why the Default value for these keys is having it's type modified and/or being set to 1? I have looked at your XML and can't see anything that jumps out at me as to why.

Thank you for your time putting this together BTW!

[Crosse]

It's been a long time since I last administered an Windows machine, but I think I remember seeing this behavior back then. It didn't seem to affect anything (that I saw), so I ignored it. In your testing have you noticed any adverse or undesired behaviors that you think are due to this? I'll take a look this weekend and see if anything stands out to me, too!

[PedroAsani]

I found this entry in the TLS 1.1 that might be causing it:

<falseList defaultKey="SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server">

                        <item valueName=""><value><decimal value="" /></value></item>

[Crosse]

@sheehand, when you have time could you check whether the change that @PedroAsani just made fixes this?

[daooze]

I have just discovered this project (thanks a lot, saved me some hours of doing that stuff myself) and got the same issue as @sheehand.

The problem (not only for the TLS 1.1/1.2 configuration) seemed to be the valueName="" property in the fields. I've changed all occurrences of valueName="" to valueName="Enabled" and that did the trick. However, I did not do intensive testing, just verified the resulting .pol with Registry Workshop. but all seems fine.

Here is my changed schannel.admx file: schannel.txt

[OftKilted]

We saw an “out of the box” scenario where by default new Windows Server 2016 systems were listing it as type “string”. (No other servers were.)

[sheehand]

@sheehand, when you have time could you check whether the change that @PedroAsani just made fixes this?

Sorry I didn't see the response a month ago - luckily I got email alerts about the last two posts.

I updated the admx on my lab DCs with the one from the Code section of this site, edited the GPO using the settings by unchecking and checking the client and server settings under TLS 1.1 and 1.2 (and selecting Apply after each action), verified the GPO show and updated modified date, and then rebooted one of the servers with the issue noted above.

Sadly there was no change. Is the issue that I need to manually change the Default value back to a string on all servers where the GPO was changed previously (as in this GPO won't undo what was done before and just modify the string to a DWORD going forward on new boxes), or was the change supposed to revert the value and it didn't for some reason?

Perhaps what daooze posted might undo the String --> DWORD change? I'm really hoping I don't have to script up code to update hundreds of machines just to put the Default registry value back the way it was supposed to (even though it won't hurt anything people noticed and were concerned).

Thanks for your help with this!

[sheehand]

As a test I deleted the Default registry DWORD key under the TLS 1.1 Client key, which recreated it as a string (that was nice as I wasn't sure what would happen), but when I re-applied the GPO it got flipped back to a DWORD again.

Again I am not using the version daooze linked to, but rather the one I get Download button on https://github.com/Crosse/SchannelGroupPolicy.

[OftKilted]

According to the Microsoft documentation they’re supposed to be DWORDs not Strings:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-12

@Sheehand Does the Microsoft documentation assist in understanding why they should be changed from string to DWORD?

[sheehand]

The individual values under the registry keys should be DWORD values - absolutely. I am referring to the "Default" registry value created by default under every key. Using your first link, scroll down to the SSL 2.0 section and you will see the value "(Default)" is a REG_SZ with value not set. This is repeated through all the screen shots.

The template here is turning the "(Default)" value under all the keys from a string to a DWORD when it shouldn't be.

[sheehand]

So coming full circle, the latest template I downloaded yesterday still changes the "(Default)" registry value under each key from a string to a DWORD with a value of 1.

@PedroAsani - did you look at what daooze posted to see if you agree it fixes the problem? If so we should update the main download with it IMHO.

[Crosse]

Howdy all,

I apologize for the delayed reply; I've been on vacation for the past week. @sheehand, the ZIP file you get by clicking the Download link on the main page should have included the fix that @PedroAsani made. I've got a test DC and one or two Windows servers here at work that I can (mis-)appropriate to do some testing on this. I would love to get this figured out and put to bed!

I'll report back when I get a chance to test this, hopefully in the next day or two.

[sheehand]

No apologies needed - work and vacation consume us all.

Once all is said and done I do have a suggestion for another setting to add regarding WinHTTP and forcing it to use TLS, that's really for things like Windows 7 clients so I don't know if you all would be interested in messing with that.

[PedroAsani]

I'm looking at what @daooze posted. I've submitted a pull request for my protocol modifications, but not changed these default valuenames since I don't currently have a testbed (hopefully soon).

[PedroAsani]

I just found my old, old, old version of this template forked from the Naupilus version. @daooze is right, it's in there as Enabled. I'll modify my fork and resubmit for the pull.

[Crosse]

I installed the template on my test DC here at work after merging @PedroAsani's latest PR. I verified that the only keys under …\Protocols were for SSL 2.0 (this is a Windows 2016 box). I then created a new GPO and configured TLS 1.1 to be disabled. After a gpudpate /force, the TLS 1.1 keys showed up, and their "(Default)" keys have the REG_SZ type:

PS C:\> reg query 'HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' /ve

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
    (Default)    REG_SZ    (value not set)

Screenshot:

So I think that means this issue has been resolved? I would love to get a second set of eyes on it just to make sure!

[sheehand]

Is the version I can download from the "clone or download" button the updated template? If so I am happy to download it and test. I just want to confirm because honestly I get lost on GitHub with all the forking and whatnot.

[Crosse]

Yep, that's correct! Here's the direct link:

https://github.com/Crosse/SchannelGroupPolicy/archive/master.zip

[sheehand]

Under Admin Template --> Network --> SSL Configuration Settings --> Protocols, I now see two entries called DTLS 1.0 and DTLS 1.2 that are marked as not configured and only one additional TLS 1.2 settintg hat is enabled. So the old TLS 1.0 and TLS 1.1 appear to be gone from this section.

I do see TLS 1.0 and TLS 1.1 under "Weak Protocols", when I don't remember seeing them there before, and only TLS 1.1 is showing as enabled. I.E. I thought this section stopped at SSL 3.0 but I could be remembering wrong.

So it looks like there were lots of changes, things moved around, and the older settings lost?

[sheehand]

Confirmed - I reverted to the previous template and TLS1.0 is under Weak Protocols but not TLS 1.1, and TLS 1.1 and TLS 1.2 are showing up under Protocols as enabled. So it looks like things got moved around and potentially duplicated above and beyond stopping the string from being changed to a DWORD.

[Crosse]

I haven't thought about this repo in a long time—it's been two years since I posted the "Maintainers Wanted" notice to the README, and have not had any contributions since then. I think this project has fossilized at this point and I doubt any progress will happen on this front. I'm going to close this issue now. If there is something still that needs to happen here, feel free to open a new issue.

Thank you to all who have contributed!

[Harvester57]

For what it's worth, I don't think there has been much innovation related to Schannel recently, except for TLS 1.3. We could probably cleanup or complete some descriptions, but for now these templates are doing their job really well as is !

I recently added a policy to help configure TLS cipher suites with a notion of "profiles", inspired by the Mozilla TLS recommendantions, let me know if you think this could be a useful addition to your templates: https://github.com/Harvester57/Security-ADMX/commit/d34c8bd7377a42686bfc436d9169201468c37cd2

[PedroAsani]

I concur. SChannel changes tend to rubberband, either nothing for a long time, or a glut all at once.

---

From: Florian Stosse @.> Sent: Wednesday, November 23, 2022 10:40:11 AM To: Crosse/SchannelGroupPolicy @.> Cc: Peter Jones @.>; Mention @.> Subject: Re: [Crosse/SchannelGroupPolicy] Setting the TLS 1.1 and 1.2 setting creates a "Default" registry key DWORD of 1. (#10)

For what it's worth, I don't think there has been much innovation related to Schannel recently, except for TLS 1.3. We could probably cleanup or complete some descriptions, but for now these templates are doing their job really well as is !

I recently added a policy to help configure TLS cipher suites with a notion of "profiles", inspired by the Mozilla TLS recommendantions, let me know if you think this could be a useful addition to your templates: @.***https://github.com/Harvester57/Security-ADMX/commit/d34c8bd7377a42686bfc436d9169201468c37cd2

— Reply to this email directly, view it on GitHubhttps://github.com/Crosse/SchannelGroupPolicy/issues/10#issuecomment-1325505511, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6QEVN5QHZ4HDMFEDALPZ3WJZQIXANCNFSM4G75NBMQ. You are receiving this because you were mentioned.Message ID: @.***>

[Crosse]

This is all good to hear! I'm glad this project is still helping people, then.