We are wanting to configure our Windows client to use only TLS 1.1 and greater. We’ve learned that we can do this by editing the registry. Now we want to make several HTTPS requests from different applications and check to be sure that they all use TLS 1.1 and above.
What we have tried is to run Wireshark with (ip.dst == 137.117.17.70) && ssl and with (ip.src == 137.117.17.70) && ssl as the filter and then run a web request from Internet Explorer. The results show this for the Client Hello.
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Version: TLS 1.0
Handshake Protocol: Client Hello
Version: TLS 1.2
And they show this for the Server Hello.
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Version: TLS 1.2
Handshake Protocol: Server Hello
Version: TLS 1.2
My sense is that that means we have not successfully turned off the legacy protocol, because the Client Hello initially says 1.0. Is that right?
Here is a better way of filtering for the Client Hello and Server Hello for a specific IP address.
(ip.src == 137.117.17.70) && ssl.handshake.type == 1
(ip.dst == 137.117.17.70) && ssl.handshake.type == 2
asked Sep 10, 2015 at 21:16
Shaun LuttinShaun Luttin
1,4333 gold badges12 silver badges13 bronze badges
8
You want to look at the «protocol version» in the ServerHello message. Consider this image, shamelessly plundered from the Web and that shows a screenshot of a ServerHello being decoded by Wireshark:
There are two «Version: TLS 1.0 (0x0301)» instances in this picture. The first one is from the header of the record that contains the ServerHello. The second one is from the contents of the ServerHello message itself. The second one is the one you are interested in, because it is the way the server informs the client about the protocol version that will be used for this connection.
answered Sep 10, 2015 at 21:45
Thomas PorninThomas Pornin
322k58 gold badges785 silver badges954 bronze badges
3
Have you tried the command?
openssl s_client -connect $host:$sslport
That’s an standard output that shows the protocol being used.
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIIadjDodBFIPEwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwODI2MTczMTE1WhcNMTUxMTI0MDAwMDAw
WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3
Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDL658m
A7raUi5Md0svZq0uIUbLRE0IQT7j5PpNp8d1IL0T2o1vsO//g1vFFlYlRon1zDUr
ku3FKjD9saf+hZ4Xu75zQxTOq6OQn808fsUfORqknUOVuL9/JUBXelQedy5RQCHM
LQ88kCsdFPCZOhM5MoSTFEfBowihnkwaphf0VULzr5mvB+7rhniDB6V/Bg7gNtkY
jkaa4nsVPW4j+mDAdnbsWAyS/3DB70r+lWZCfSCC0g+KBuc/t2+fPxbABpH7G/4j
mJTaPYLC6EK/jvhlbUuKcrkh9lWS+yzk66FxaxJk09rjot9UH+Co57IesCGB5ve5
jPWnB+DmGidrMzfjAgMBAAGjggFBMIIBPTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE
XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0
MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G
A1UdDgQWBBRHCy9UAa8aPpibWBmZbfiRehl5KjAMBgNVHRMBAf8EAjAAMB8GA1Ud
IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMBcGA1UdIAQQMA4wDAYKKwYBBAHW
eQIFATAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB
RzIuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQAy8TxeKLUaLeHXF0+DlqHs4D/0Jfki
a2bAZw/og6pZ1mDpqjXn1EESHhiEIFz7LUImCDgeQHOMkUYnw2Q16+rhag30yHOp
usHsDs9IZ2jJh/Zdog4Mg38YEB+UC79cNqx65fq81X/fxr1GSAKsEUUtZ8gXLSiu
oisctt+FM5v+t0Cdo9QbV0i5mcTPh4F/JU71ox9UOzt7ST9+rNg45ygqbIvpM/p4
cBWLOaAQYZxjFN2kOUIgEMYpMa7iXWyBrNAi6oRlTTYbr1e1ElU5rr1GqNZJ5TLr
lkcMZpRwGomeFxWMdMWHQxWM1gs9cROAvRq0dz7PpqYHo7kcR61CT2Vl
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3719 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 5832B5186C5F842ED93B49CBFA04C93DA5099ABA72E6D8C2A11EEFCCBCAEC563
Session-ID-ctx:
Master-Key: F5BC199D27A2AFDB16A120AC706DBF68F024129E351E32B6C636AD087A3C775459F4A7941C7D1509B0B115A82BDFEA98
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb b9 4a df 5a 50 e7 ae-14 fe 81 95 04 a7 1f 62 ..J.ZP.........b
0010 - 7c 22 71 99 e8 55 31 f2-53 bb 4b d5 4e b3 0e 8f |"q..U1.S.K.N...
0020 - 7a 75 b3 7f 68 9a ed 25-bb 5e 88 97 26 db cf 7a zu..h..%.^..&..z
0030 - 40 65 65 60 e3 34 b3 15-44 50 a3 57 98 77 ca 6c @ee`.4..DP.W.w.l
0040 - 63 45 84 07 7e cc b4 5c-4d e5 66 d6 df 9a bb 7e cE..~..M.f....~
0050 - 24 f3 5b 08 5a 7a 03 1c-b4 2d 01 4b 3c 33 f6 34 $.[.Zz...-.K<3.4
0060 - 4c df 5c c9 22 08 b2 94-25 aa 48 07 a2 f6 50 b8 L.."...%.H...P.
0070 - f7 90 a7 46 25 bf 9e 46-05 62 7e bb 6e 61 8e ef ...F%..F.b~.na..
0080 - ad 37 c4 e1 17 f4 57 42-c9 d0 e9 85 cb 65 cf b2 .7....WB.....e..
0090 - 4c 2e 98 e0 38 6a da 16-62 de 3e 51 e2 2c de 84 L...8j..b.>Q.,..
00a0 - a0 ab b7 e6 ....
Start Time: 1441848276
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Hope this helps.
answered Sep 10, 2015 at 22:27
OctotoposOctotopos
911 gold badge1 silver badge3 bronze badges
3
We are wanting to configure our Windows client to use only TLS 1.1 and greater. We’ve learned that we can do this by editing the registry. Now we want to make several HTTPS requests from different applications and check to be sure that they all use TLS 1.1 and above.
What we have tried is to run Wireshark with (ip.dst == 137.117.17.70) && ssl and with (ip.src == 137.117.17.70) && ssl as the filter and then run a web request from Internet Explorer. The results show this for the Client Hello.
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Version: TLS 1.0
Handshake Protocol: Client Hello
Version: TLS 1.2
And they show this for the Server Hello.
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Version: TLS 1.2
Handshake Protocol: Server Hello
Version: TLS 1.2
My sense is that that means we have not successfully turned off the legacy protocol, because the Client Hello initially says 1.0. Is that right?
Here is a better way of filtering for the Client Hello and Server Hello for a specific IP address.
(ip.src == 137.117.17.70) && ssl.handshake.type == 1
(ip.dst == 137.117.17.70) && ssl.handshake.type == 2
asked Sep 10, 2015 at 21:16
Shaun LuttinShaun Luttin
1,4333 gold badges12 silver badges13 bronze badges
8
You want to look at the «protocol version» in the ServerHello message. Consider this image, shamelessly plundered from the Web and that shows a screenshot of a ServerHello being decoded by Wireshark:
There are two «Version: TLS 1.0 (0x0301)» instances in this picture. The first one is from the header of the record that contains the ServerHello. The second one is from the contents of the ServerHello message itself. The second one is the one you are interested in, because it is the way the server informs the client about the protocol version that will be used for this connection.
answered Sep 10, 2015 at 21:45
Thomas PorninThomas Pornin
322k58 gold badges785 silver badges954 bronze badges
3
Have you tried the command?
openssl s_client -connect $host:$sslport
That’s an standard output that shows the protocol being used.
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEdjCCA16gAwIBAgIIadjDodBFIPEwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwODI2MTczMTE1WhcNMTUxMTI0MDAwMDAw
WjBoMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEXMBUGA1UEAwwOd3d3
Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDL658m
A7raUi5Md0svZq0uIUbLRE0IQT7j5PpNp8d1IL0T2o1vsO//g1vFFlYlRon1zDUr
ku3FKjD9saf+hZ4Xu75zQxTOq6OQn808fsUfORqknUOVuL9/JUBXelQedy5RQCHM
LQ88kCsdFPCZOhM5MoSTFEfBowihnkwaphf0VULzr5mvB+7rhniDB6V/Bg7gNtkY
jkaa4nsVPW4j+mDAdnbsWAyS/3DB70r+lWZCfSCC0g+KBuc/t2+fPxbABpH7G/4j
mJTaPYLC6EK/jvhlbUuKcrkh9lWS+yzk66FxaxJk09rjot9UH+Co57IesCGB5ve5
jPWnB+DmGidrMzfjAgMBAAGjggFBMIIBPTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20waAYIKwYBBQUHAQEE
XDBaMCsGCCsGAQUFBzAChh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3J0
MCsGCCsGAQUFBzABhh9odHRwOi8vY2xpZW50czEuZ29vZ2xlLmNvbS9vY3NwMB0G
A1UdDgQWBBRHCy9UAa8aPpibWBmZbfiRehl5KjAMBgNVHRMBAf8EAjAAMB8GA1Ud
IwQYMBaAFErdBhYbvPZotXb1gba7Yhq6WoEvMBcGA1UdIAQQMA4wDAYKKwYBBAHW
eQIFATAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lB
RzIuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQAy8TxeKLUaLeHXF0+DlqHs4D/0Jfki
a2bAZw/og6pZ1mDpqjXn1EESHhiEIFz7LUImCDgeQHOMkUYnw2Q16+rhag30yHOp
usHsDs9IZ2jJh/Zdog4Mg38YEB+UC79cNqx65fq81X/fxr1GSAKsEUUtZ8gXLSiu
oisctt+FM5v+t0Cdo9QbV0i5mcTPh4F/JU71ox9UOzt7ST9+rNg45ygqbIvpM/p4
cBWLOaAQYZxjFN2kOUIgEMYpMa7iXWyBrNAi6oRlTTYbr1e1ElU5rr1GqNZJ5TLr
lkcMZpRwGomeFxWMdMWHQxWM1gs9cROAvRq0dz7PpqYHo7kcR61CT2Vl
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3719 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 5832B5186C5F842ED93B49CBFA04C93DA5099ABA72E6D8C2A11EEFCCBCAEC563
Session-ID-ctx:
Master-Key: F5BC199D27A2AFDB16A120AC706DBF68F024129E351E32B6C636AD087A3C775459F4A7941C7D1509B0B115A82BDFEA98
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb b9 4a df 5a 50 e7 ae-14 fe 81 95 04 a7 1f 62 ..J.ZP.........b
0010 - 7c 22 71 99 e8 55 31 f2-53 bb 4b d5 4e b3 0e 8f |"q..U1.S.K.N...
0020 - 7a 75 b3 7f 68 9a ed 25-bb 5e 88 97 26 db cf 7a zu..h..%.^..&..z
0030 - 40 65 65 60 e3 34 b3 15-44 50 a3 57 98 77 ca 6c @ee`.4..DP.W.w.l
0040 - 63 45 84 07 7e cc b4 5c-4d e5 66 d6 df 9a bb 7e cE..~..M.f....~
0050 - 24 f3 5b 08 5a 7a 03 1c-b4 2d 01 4b 3c 33 f6 34 $.[.Zz...-.K<3.4
0060 - 4c df 5c c9 22 08 b2 94-25 aa 48 07 a2 f6 50 b8 L.."...%.H...P.
0070 - f7 90 a7 46 25 bf 9e 46-05 62 7e bb 6e 61 8e ef ...F%..F.b~.na..
0080 - ad 37 c4 e1 17 f4 57 42-c9 d0 e9 85 cb 65 cf b2 .7....WB.....e..
0090 - 4c 2e 98 e0 38 6a da 16-62 de 3e 51 e2 2c de 84 L...8j..b.>Q.,..
00a0 - a0 ab b7 e6 ....
Start Time: 1441848276
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Hope this helps.
answered Sep 10, 2015 at 22:27
OctotoposOctotopos
911 gold badge1 silver badge3 bronze badges
3
I like to use curl which can report a TLS version negotiation quite nicely.
For example, this tries to connect with TLS 1.1, which the server negotiates to upgrade to 1.2:
$ curl -Iiv --tlsv1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
[...]
To forbid that the server upgrades the TLS version use the --tls-max option:
$ curl -Iiv --tlsv1.1 --tls-max 1.1 https://example.com
* Trying 192.168.205.11:443...
* TCP_NODELAY set
* Connected to example.com (192.168.205.11) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, internal error (592):
* error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
* Closing connection 0
curl: (35) error:141E70BF:SSL routines:tls_construct_client_hello:no protocols available
In this case, the connection fails because the client does not offer any TLS version above 1.1, but the server does not accept any version below 1.2. If used like this, the output is very similar to the openssl_client output.
I need to check if TLS 1.2 is enabled on my Windows Server 2019.
In the registry the key TLS 1.2 is not present under Protocols
But when I browse on a secure website (hosted on this server in IIS) from a client browser I can clearly see that TLS 1.2 is used to secure the connection.
What to conclude ? Is TLS 1.2 enabled ? Is there no need for the TLS 1.2 key to be present in the registry ?
asked Nov 5, 2020 at 11:02
According to Microsoft documentation TLS 1.2 is enabled by default on Windows Server 2012 and newer versions. This default behaviour means you don’t need to create specific registry values to enable it.
answered Nov 6, 2020 at 19:45
Загрузить PDF
Загрузить PDF
В этой статье мы расскажем вам, как узнать, какие версии TLS настроены на веб-сервере. Также можно выяснить, какие версии TLS поддерживаются веб-браузером.
-
1
Запустите веб-браузер на компьютере или мобильном устройстве. Это может быть любой браузер, например Chrome, Safari или Firefox.
-
2
Перейдите на https://www.ssllabs.com/ssltest. Это бесплатный онлайн-сервис, с помощью которого можно узнать версию TLS для любого веб-сайта.[1]
-
3
Введите доменное имя сайта или его IP-адрес. Сделайте это в строке «Hostname» (Имя хоста) вверху страницы.
- Чтобы доменное имя или IP-адрес не отображались в списке последних запросов сервиса SSL Labs, установите флажок у «Do not show the results on the boards» (Не показывать результаты на форумах).
-
4
Нажмите Submit (Отправить). Запустится проверка сайта. Когда процесс завершится, отобразится отчет о безопасности веб-сайта.
- Процесс займет около 3 минут.
-
5
Прокрутите страницу вниз до раздела «Configuration» (Конфигурация). Вы найдете его под разделом(-ами) «Certificate» (Сертификат).
-
6
Найдите все версии TLS, возле которых есть слово «Yes» (Да). Сделайте это в разделе «Protocols» (Протоколы). Вы найдете все версии TLS (поддерживаемые и не поддерживаемые) вверху раздела «Конфигурация». Версии, возле которых значится «Да», настроены на исследуемом сайте.
Реклама
-
1
Запустите веб-браузер на компьютере или мобильном устройстве. Это может быть любой браузер, например Chrome, Safari или Firefox.
-
2
Откройте сайт https://www.howsmyssl.com. Этот онлайн-сервис протестирует браузер и отобразит результаты проверки.[2]
-
3
Найдите версию в разделе «Version» (Версия). Чтобы найти его на мобильном устройстве, прокрутите страницу вниз.
Реклама
Об этой статье
Эту страницу просматривали 12 166 раз.
Была ли эта статья полезной?
Написать эту статью подоткнул тот факт, что Windows Server 2016, установленный из коробки, почему-то не имеел TLS протокол, включенный как основный по умолчанию, в то время как SSL3.0 был включен. Приводит это к разным последствиям, как для безопасности, так и для функционирования различных сервисов и приложений.
Проблемы версий протоколов SSL и TLS и совместимости приложений
Для начала рассмотрим проблемы связанные с версиями SSL протоколов:
- SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
- SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
- TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
- TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.
SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1). Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.
В более ранних версиях Windows Servers (2008, 2012) SSL v3 все еще включен, т. е. Вам необходимо вручную отключить устаревшие протоколы. Windows Server 2016 и выше уже имеют конфигурацию SSL, которая соответствует действующим регламентам безопасности (например, SSL v2 и SSL v3 отключены).
Но и это оказывается не полной правдой. Дело в том, что использование протоколов зависит не только от системных настроек, но и от того, как написаны приложения. Например, я выяснил, что .NET приложения используют свои собственные настройки безопасности. Также известно, что если включить поддержку TLS 1.2 на SQL Server (например, применив патч https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server), установленный на Windows Server 2012, то приложения .NET и JAVA потеряют возможность подключаться к SQL.
Также давно известна проблема с вэб приложениями, написанными на базе интерфейса WinHTTP API. После включения TLS 1.1/1.2 они также перестают подключаться.
Службы IIS и ADFS при этом прекрасно используют новые протоколы, следуя системным настройкам. Более того, к сервисам Azure вы не сможете подключиться через TLS 1.2, но при этом, как выяснилось, Powershell даже в Windows Server 2016 использует SSL3.0 и TLS 1.0, несмотря на то, что согласно системной настройке они отключены.
Начнем с того, что для всего есть свои реестровые ключи, однако нужно точно понимать, какой тип приложения вы хотите настроить, чтобы избежать проблем. Начну с того, что полный список доступных системных ключей в Windows 10/Windows Server 2016/2019 доступен по ссылке https://docs.microsoft.com/ru-ru/windows-server/security/tls/tls-registry-settings. Изменяя их, вы можете настроить IIS, ADFS и прочие службы. Однако, эти ключи не влияют на работу приложений .NET (и в частности, Powershell) и WinHTTP!
В чем же дело? Дело в библиотеках. IIS и ADFS используют Schannel — поставщик поддержки безопасности (SSP), реализующий стандартные протоколы проверки подлинности SSL, TLS и DTLS Internet. Интерфейс поставщика поддержки безопасности (SSPI) является интерфейсом API, используемым системами Windows для выполнения функций, связанных с безопасностью, включая проверку подлинности. В Windows все функции SSPI выполняет библиотека Schannel.dll, в которой реализованы все протоколы и наборы шифрования.
Итак, ветки реестра, которые нас интересуют:
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols — включение и отключение протоколов для Schannel.dll, как клиентских, так и серверных. Для каждого протокола — своя ветка;
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers — здесь можно изменить список и порядок просмотра (это важно!) наборов шифрования;
- HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp — в параметре DefaultSecureProtocols настраиваются протоколы для приложений на WinHttp API;
- HKEY_LOCAL_MACHINECurrentControlSetControlCryptographyECCParameters — настройка эллиптических кривых для криптографии;
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELHashesMD5 — отключение MD5 шифрования для маркеров безопасности.
Внимание! После его отключения перестает корректно работать Shаrepoint 2010! Он использует MD5 для генерации внутренних идентификаторов безопасности, поэтому не найдя её очень страдает.
- HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLSA — настройка размера пула потоков для TLS рукопожатий в HTTP.SYS (это веб серверная имплементация на ASP.NET Core, которая является альтернативой популярному веб серверу Kestrel).
Теперь пройдем по конкретным примерам и настройкам.
Отключение SSL и TLS 1.0 протоколов на системном в Schannel подробно описано в документации Microsoft. Отключить небезопасные можно как через реестр, так и с помощью Powershell.
В этой же статье ниже описано, как отключить небезопасные алгоритмы шифрования, такие как RC4.
Отключить небезопасные наборы шифрования (cipher suites) можно через параметр Functions в ключе реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010002.
Этот параметр является многострочным текстовым значением, который просто содержит построчный список наборов (один на строку). Удалите ненужные строки.
Будьте внимательны, список и порядок следования наборов меняется от версии к версии! Актуальный список для Windows 10 build 1903 доступен по ссылке.
Порядок проверки наборов шифрования также удобно изменять с помощью групповых политик. Это также описано в документации.
Ну и наконец, для управления доступными наборами появились командлеты Powershell. Например, с помощью Disable-TlsCipherSuite вы можете отключить неугодный набор.
Отключение SSL для Powershell и других .NET приложений
Как я уже писал, системные настройки выше не влияют на Powershell сессии. Проверить, какие протоколы сейчас активны в вашей Powershell сессии, можно выполнив команду
[Net.ServicePointManager]::SecurityProtocol
Если в выводе команды увидите ssl30, tls, то их надо отключить.
Для этого в Windows Srver 2012 / Windows 2016 используйте ключ реестра
HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319 "SchUseStrongCrypto"=dword:00000001
С помощью самого Powershell это можно изменить одной командой:
New-ItemProperty -path 'HKLM:SOFTWAREMicrosoft.NetFrameworkv4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
Включение TLS 1.2 для WinHTTP
Если коротко, то в ключе реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp нужно добавить параметр DefaultSecureProtocols, который в 16-ричном виде будет содержать сумму значений всех протоколов, которые необходимо включить. Например, для включения TLS 1.1 и 1.2 надо добавить значение 0x00000A00, которое будет суммой значений TLS 1.1 (0x00000200) и TLS 1.2 (0x00000800).
Готовый патч от Microsoft для исправления этого также можно скачать по ссылке KB3140245
Настройка с помощью IISCrypto
IISCrypto — это бесплатная утилита, не требующая установки, которая позволяет включить/выключить многие настройки Schannel через графический интерфейс, .NET и WinHTTP она не настраивает.
Скачать её можно с сайта разработчика без регистрации.
[Посещений: 6 355, из них сегодня: 2]
Есть ли команда для проверки версии TLS, требуемой хост-сайтом. На данный момент я знаю, что единственный способ проверить это настроить максимальную версию TLS в моем браузере и проверить, могу ли я получить доступ к сайту. Однако я подозреваю, что есть более изощренный способ сделать это.
4 ответа
Лучший ответ
Вы можете проверить, используя следующие команды
Для TLS 1.2
openssl s_client -connect www.google.com:443 -tls1_2
Для TLS 1.1
openssl s_client -connect www.google.com:443 -tls1_1
Для tls 1
openssl s_client -connect www.google.com:443 -tls1
Если вы получаете цепочку сертификатов и рукопожатие, то поддерживается версия tls. Если вы не видите цепочку сертификатов и что-то похожее на «ошибку рукопожатия», значит, это не так.
27
manuj
11 Ноя 2016 в 23:47
Из https: // maxchadwick. xyz / blog / check-ssl-tls-version-support-of-remote-host-from-command-line:
Nmap ssl-enum-ciphers
Другой вариант проверки поддержки версий SSL / TLS — это nmap. Nmap обычно не устанавливается по умолчанию, поэтому вам придется установить его вручную. После установки вы можете использовать следующую команду, чтобы проверить поддержку версии SSL / TLS…
$ nmap --script ssl-enum-ciphers -p 443 www.google.com
Сценарий nmap ssl-enum-ciphers не только проверяет поддержку версий SSL / TLS для всех версий (TLS 1.0, TLS 1.1 и TLS 1.2) за один раз, но также проверяет поддержку шифров для каждой версии, включая выставление оценок.
8
Colin Curtin
19 Апр 2019 в 16:07
Кажется, самый изощренный способ — это проверить для каждой версии вот так:
Openssl s_client -connect: —
1
LakeMichigan
11 Ноя 2016 в 22:55