Отключить поддержку шифров 3des windows server 2008 r2

We got it to work!

  • We got it to work!

    Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168.  2012/8.1/10 does not.  

    the key on 2008 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168/168

    And the key on 2012 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168

    I can confirm that use of «Triple DES 168/168» DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL] «EventLogging»=dword:00000007

    You will then have events in the SYSTEM log for example;

    An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

    Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

    For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

    When I use «Triple DES 168» (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

    Per the article: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

    Remote Desktop Services (RDS)

    For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

    Per the  article: «System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing» security setting effects in Windows XP and in later versions of Windows

    This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows.
    The effect depends on whether TLS is being used for server authentication. 

    If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used. 

    By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote
    Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true:

    • The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
    • The SHA-1 algorithm is used to create message digests.
    • Clients must use the RDP 5.2 client program or a later version to connect.

    So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

    The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

    • CALG_RSA_KEYX — RSA public key exchange algorithm
    • CALG_3DES — Triple DES encryption algorithm
    • CALG_AES_128 — 128 bit AES
    • CALG_AES_256 — 256 bit AES
    • CALG_SHA1 — SHA hashing algorithm
    • CALG_SHA_256 — 256 bit SHA hashing algorithm
    • CALG_SHA_384 — 384 bit SHA hashing algorithm
    • CALG_SHA_512 — 512 bit SHA hashing algorithm

    Ultimately it’s not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn’t.

    I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it’s entirely possible that Server 2012 R2 supports
    additional protocols. You’ll note the additional protocols in the FIPS 140 Validation link.

    In conclusion: I don’t think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more
    than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

    • Proposed as answer by

      Tuesday, January 10, 2017 10:25 PM

    • Marked as answer by
      r.mangan
      Tuesday, January 10, 2017 11:32 PM

    • Источник

    Ноя
    15
    2018

    Данные методы шифрования являются устаревшими и уязвимыми ко взломам. Все чаще, в рамках требований политик безопасности и лучших практик, 3DES и RC4 рекомендуется отключить.

    Отключение 3DES и RC4 в Windows Server 2016 (Powershell)

    Disable-TlsCipherSuite -Name «TLS_RSA_WITH_3DES_EDE_CBC_SHA»

    #RC4

    ([Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,$env:COMPUTERNAME)).CreateSubKey(‘SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128’)

    New-ItemProperty -path ‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

    ([Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,$env:COMPUTERNAME)).CreateSubKey(‘SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128’)

    New-ItemProperty -path ‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

    ([Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine,$env:COMPUTERNAME)).CreateSubKey(‘SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128’)

    New-ItemProperty -path ‘HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128’ -name ‘Enabled’ -value ‘0’ -PropertyType ‘DWord’ -Force | Out-Null

    Отключение 3DES и RC4 в Windows Server 2012

    Сохраните ключи реестра в файл с расширением .reg и примените его двойным щелчком мыши
    Disable_3DES_RC4.reg

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers]

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]

    @=«»

    «Enabled»=dword:00000000

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]

    @=«»

    «Enabled»=dword:00000000

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]

    @=«»

    «Enabled»=dword:00000000

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168]

    @=«»

    «Enabled»=dword:00000000

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]

    @=«»

    «Enabled»=dword:00000000

    Источник

    RRS feed

    • Remove From My Forums

    • Question

    • User158051622 posted

      Hi,

      We are looking for how to disable Disable DES and 3-DES Ciphers from IIS <g class=»gr_ gr_43 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del» id=»43″ data-gr-id=»43″>Webservers</g>?

      Regards,

      Lokesh

    All replies

    • User-2064283741 posted
      The easiest way is to use iiscrypto

      https://www.nartac.com/Products/IISCrypto

    • User158051622 posted

      Hi, 
      We are looking how to disable DES and 3DES Ciphers from Windows Server 2008 Registry settings.
      Regards,
      Loki

    • User-2064283741 posted
      Yep that does that for you.

    • User-72702933 posted

      Hi Lokesh Baskararajan,

      As far as I know, if you want to disable the disable the DES and Triple DES, I suggest you could try below register codes.

      Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
"Enabled"=dword:00000000

      Command:

      reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168" /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168" /v Enabled /d 0 /t REG_DWORD /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168" /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168" /v Enabled /d 0 /t REG_DWORD /f

      Best Regards,

      Brando

    • User158051622 posted

      Hi Brando,

      But in the Server’s Registry settings I couldn’t able to find both DES and 3DES Ciphers. So does the Servers take the value as True by default even if it is not there in the registry? I am wondering in order to disable we need to create the Ciphers manually
      and disable it?

      Regards,

      Lokesh

    • User680244069 posted

      Hi Brando,

      Even for my setup, I do not have any parameters related to DES and 3DES in the system’s registry. 

      So do I need to explicitly create new DES and 3DES parameter under the registry and give the value accordingly for disabling it? Or does it by default take the value as disabled since the parameters related to DES and 3DES is missing from the registry?

      Regards,

      Priyanka

    • User680244069 posted

      Hey Brando,

      Could you provide any information on how to check the if the DES and 3DES ciphers are enabled or disabled at my server level?

      Currently i do not see any registry parameters on the server level with the DES or 3DES param.

      Regards,

      Priyanka

    • User-158764254 posted

      you’d need to create the reg keys to alter the defaults.

      or as previously mentioned, just use

      https://www.nartac.com/Products/IISCrypto

      It’s free.

      It’s widely used.

      It’s safe.

      It doesn’t need to be «installed» — just run the exe and pick your options.

    Источник

  • We got it to work!

    Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168.  2012/8.1/10 does not.  

    the key on 2008 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168/168

    And the key on 2012 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168

    I can confirm that use of «Triple DES 168/168» DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL] «EventLogging»=dword:00000007

    You will then have events in the SYSTEM log for example;

    An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

    Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

    For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

    When I use «Triple DES 168» (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

    Per the article: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

    Remote Desktop Services (RDS)

    For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

    Per the  article: «System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing» security setting effects in Windows XP and in later versions of Windows

    This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows.
    The effect depends on whether TLS is being used for server authentication. 

    If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used. 

    By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote
    Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true:

    • The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
    • The SHA-1 algorithm is used to create message digests.
    • Clients must use the RDP 5.2 client program or a later version to connect.

    So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

    The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

    • CALG_RSA_KEYX — RSA public key exchange algorithm
    • CALG_3DES — Triple DES encryption algorithm
    • CALG_AES_128 — 128 bit AES
    • CALG_AES_256 — 256 bit AES
    • CALG_SHA1 — SHA hashing algorithm
    • CALG_SHA_256 — 256 bit SHA hashing algorithm
    • CALG_SHA_384 — 384 bit SHA hashing algorithm
    • CALG_SHA_512 — 512 bit SHA hashing algorithm

    Ultimately it’s not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn’t.

    I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it’s entirely possible that Server 2012 R2 supports
    additional protocols. You’ll note the additional protocols in the FIPS 140 Validation link.

    In conclusion: I don’t think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more
    than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

    • Proposed as answer by

      Tuesday, January 10, 2017 10:25 PM

    • Marked as answer by
      r.mangan
      Tuesday, January 10, 2017 11:32 PM

    • Источник

  • We got it to work!

    Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168.  2012/8.1/10 does not.  

    the key on 2008 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168/168

    And the key on 2012 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168

    I can confirm that use of «Triple DES 168/168» DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL] «EventLogging»=dword:00000007

    You will then have events in the SYSTEM log for example;

    An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

    Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

    For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

    When I use «Triple DES 168» (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

    Per the article: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

    Remote Desktop Services (RDS)

    For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

    Per the  article: «System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing» security setting effects in Windows XP and in later versions of Windows

    This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows.
    The effect depends on whether TLS is being used for server authentication. 

    If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used. 

    By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote
    Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true:

    • The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
    • The SHA-1 algorithm is used to create message digests.
    • Clients must use the RDP 5.2 client program or a later version to connect.

    So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

    The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

    • CALG_RSA_KEYX — RSA public key exchange algorithm
    • CALG_3DES — Triple DES encryption algorithm
    • CALG_AES_128 — 128 bit AES
    • CALG_AES_256 — 256 bit AES
    • CALG_SHA1 — SHA hashing algorithm
    • CALG_SHA_256 — 256 bit SHA hashing algorithm
    • CALG_SHA_384 — 384 bit SHA hashing algorithm
    • CALG_SHA_512 — 512 bit SHA hashing algorithm

    Ultimately it’s not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn’t.

    I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it’s entirely possible that Server 2012 R2 supports
    additional protocols. You’ll note the additional protocols in the FIPS 140 Validation link.

    In conclusion: I don’t think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more
    than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

    • Proposed as answer by

      Tuesday, January 10, 2017 10:25 PM

    • Marked as answer by
      r.mangan
      Tuesday, January 10, 2017 11:32 PM

    • Источник

    Hi,

    a measure to protect your Windows System against Sweet32 attacks is to disable the DES and Triple DES.

    To do this, add 2 Registry Keys to the SCHANNEL Section of the registry.

    As registry file

    Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
"Enabled"=dword:00000000

    or from command line

    reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168" /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168" /v Enabled /d 0 /t REG_DWORD /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168" /f
reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168" /v Enabled /d 0 /t REG_DWORD /f

    Michael

    Advertisment to support michlstechblog.info

    My Knowledgebase for things about Linux, Windows, VMware, Electronic and so on…

    This website uses cookies to improve your experience and to serv personalized advertising by google adsense. By using this website, you consent to the use of cookies for personalized content and advertising. For more information about cookies, please see our Privacy Policy, but you can opt-out if you wish. Accept Reject Read More

    Источник

  • We got it to work!

    Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168.  2012/8.1/10 does not.  

    the key on 2008 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168/168

    And the key on 2012 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168

    I can confirm that use of «Triple DES 168/168» DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL] «EventLogging»=dword:00000007

    You will then have events in the SYSTEM log for example;

    An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

    Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

    For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

    When I use «Triple DES 168» (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

    Per the article: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

    Remote Desktop Services (RDS)

    For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

    Per the  article: «System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing» security setting effects in Windows XP and in later versions of Windows

    This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows.
    The effect depends on whether TLS is being used for server authentication. 

    If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used. 

    By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote
    Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true:

    • The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
    • The SHA-1 algorithm is used to create message digests.
    • Clients must use the RDP 5.2 client program or a later version to connect.

    So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

    The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

    • CALG_RSA_KEYX — RSA public key exchange algorithm
    • CALG_3DES — Triple DES encryption algorithm
    • CALG_AES_128 — 128 bit AES
    • CALG_AES_256 — 256 bit AES
    • CALG_SHA1 — SHA hashing algorithm
    • CALG_SHA_256 — 256 bit SHA hashing algorithm
    • CALG_SHA_384 — 384 bit SHA hashing algorithm
    • CALG_SHA_512 — 512 bit SHA hashing algorithm

    Ultimately it’s not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn’t.

    I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it’s entirely possible that Server 2012 R2 supports
    additional protocols. You’ll note the additional protocols in the FIPS 140 Validation link.

    In conclusion: I don’t think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more
    than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

    • Proposed as answer by

      Tuesday, January 10, 2017 10:25 PM

    • Marked as answer by
      r.mangan
      Tuesday, January 10, 2017 11:32 PM

    • Источник

  • We got it to work!

    Apparently 2008 and 2012 have syntax issues and the 2008/7 requires a trailing /168.  2012/8.1/10 does not.  

    the key on 2008 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168/168

    And the key on 2012 looks like this:  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple
    DES 168

    I can confirm that use of «Triple DES 168/168» DOES NOT disable 3DES on the system. You can prove this to yourself with a protocol scanner (like Nessus) or by enabling SCHANNEL logging:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL] «EventLogging»=dword:00000007

    You will then have events in the SYSTEM log for example;

    An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

    Protocol: TLS 1.0 CipherSuite: 0x2f Exchange strength: 1024

    For me the result is 0xa which Google reveals as TLS_RSA_WITH_3DES_EDE_CBC_SHA.

    When I use «Triple DES 168» (without the /168), the System event ID 36880 does not appear and the RDP session is blocked.

    Per the article: System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

    Remote Desktop Services (RDS)

    For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.

    Per the  article: «System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing» security setting effects in Windows XP and in later versions of Windows

    This setting also affects Terminal Services in Windows Server 2003 and in later versions of Windows.
    The effect depends on whether TLS is being used for server authentication. 

    If TLS is being used for server authentication, this setting causes only TLS 1.0 to be used. 

    By default, if TLS is not being used, and this setting is not enabled on the client or on the server, the Remote
    Desktop Protocol (RDP) channel between the server and the client is encrypted by using the RC4 algorithm with a 128-bit key length. After you enable this setting on a Windows Server 2003-based computer, the following is true:

    • The RDP channel is encrypted by using the 3DES algorithm in Cipher Block Chaining (CBC) mode with a 168-bit key length.
    • The SHA-1 algorithm is used to create message digests.
    • Clients must use the RDP 5.2 client program or a later version to connect.

    So both of these support the idea that RDP can only utilize 3DES. However, this article suggests a larger range of ciphers is available: FIPS 140 Validation

    The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

    • CALG_RSA_KEYX — RSA public key exchange algorithm
    • CALG_3DES — Triple DES encryption algorithm
    • CALG_AES_128 — 128 bit AES
    • CALG_AES_256 — 256 bit AES
    • CALG_SHA1 — SHA hashing algorithm
    • CALG_SHA_256 — 256 bit SHA hashing algorithm
    • CALG_SHA_384 — 384 bit SHA hashing algorithm
    • CALG_SHA_512 — 512 bit SHA hashing algorithm

    Ultimately it’s not clear whether RDP can support non-3DES protocols when FIPS mode is enabled but evidence would suggest it doesn’t.

    I see no evidence that Server 2012 R2 would function differently from Server 2008 R2, however it does seem that Server 2008 R2 was based around FIPS 140-1 compliance and Server 2012 R2 follows FIPS 140-2 so it’s entirely possible that Server 2012 R2 supports
    additional protocols. You’ll note the additional protocols in the FIPS 140 Validation link.

    In conclusion: I don’t think Server 2008 R2 can support RDP in FIPS mode with 3DES disabled. My recommendation is to ascertain whether your system meets the conditions for a SWEET32 attack (more
    than 768GB sent in a single session) and whether disabling 3DES is worth removing RDP capability. Other utilities exist to manage servers beyond RDP especially in a world where virtualization is highly commonplace.

    • Proposed as answer by

      Tuesday, January 10, 2017 10:25 PM

    • Marked as answer by
      r.mangan
      Tuesday, January 10, 2017 11:32 PM

    • Источник

    and changed all DES / Triple DES and RC4 ciphers to enabled=0x00000000(0) <disabled>

    reports ciphers being presented which are vulnerable to SWEET32 <see output below>

    Starting Nmap 7.40 ( https://nmap.org Opens a new window ) at 2017-06-28 15:49 GMT Summer Time

    Nmap scan report for xx.xx.xx.xx

    Host is up (0.0044s latency).

    PORT   STATE SERVICE VERSION

    8194/tcp open ssl/giop omg.org CORBA naming service

    | ssl-enum-ciphers:

    | TLSv1.0:

    |   ciphers:

    |     TLS_RSA_WITH_3DES_EDE_CBC_SHA — F

    |     TLS_RSA_WITH_AES_128_CBC_SHA — F

    |     TLS_RSA_WITH_AES_256_CBC_SHA — F

    |     TLS_RSA_WITH_CAMELLIA_128_CBC_SHA — F

    |     TLS_RSA_WITH_CAMELLIA_256_CBC_SHA — F

    |   compressors:

    |     NULL

    |   cipher preference: client

    |   warnings:

    |     64-bit block cipher 3DES vulnerable to SWEET32 attack

    |     Insecure certificate signature: MD5

    | TLSv1.1:

    |   ciphers:

    |     TLS_RSA_WITH_3DES_EDE_CBC_SHA — F

    |     TLS_RSA_WITH_AES_128_CBC_SHA — F

    |     TLS_RSA_WITH_AES_256_CBC_SHA — F

    |     TLS_RSA_WITH_CAMELLIA_128_CBC_SHA — F

    |     TLS_RSA_WITH_CAMELLIA_256_CBC_SHA — F

    |   compressors:

    |     NULL

    |   cipher preference: client

    |   warnings:

    |     64-bit block cipher 3DES vulnerable to SWEET32 attack

    |     Insecure certificate signature: MD5

    | TLSv1.2:

    |   ciphers:

    |     TLS_RSA_WITH_3DES_EDE_CBC_SHA — F

    |     TLS_RSA_WITH_AES_128_CBC_SHA — F

    |     TLS_RSA_WITH_AES_128_CBC_SHA256 — F

    |     TLS_RSA_WITH_AES_128_GCM_SHA256 — F

    |     TLS_RSA_WITH_AES_256_CBC_SHA — F

    |     TLS_RSA_WITH_AES_256_CBC_SHA256 — F

    |     TLS_RSA_WITH_AES_256_GCM_SHA384 — F

    |     TLS_RSA_WITH_CAMELLIA_128_CBC_SHA — F

    |     TLS_RSA_WITH_CAMELLIA_256_CBC_SHA — F

    |   compressors:

    |     NULL

    |   cipher preference: client

    |   warnings:

    |     64-bit block cipher 3DES vulnerable to SWEET32 attack

    |     Insecure certificate signature: MD5

    |_ least strength: F

    Can anyone tell me what I’m missing to truly disable 3DES ciphers on a Windows Server 2008 R2 box.

    Источник

    Понравилась статья? Поделить с друзьями:
  • Отключить повышенную безопасность ie windows 2012
  • Отключить отправку образцов защитник windows 10
  • Отключить поворот этого экрана windows 10
  • Отключить отключение экрана windows 10 при закрытии крышки ноутбука
  • Отключить планировщик заданий windows 10 через реестр