18

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

Secure Sockets Layer

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
Shaun Luttin
  • 1,423
  • 3
  • 12
  • 13
  • 4
    For starters, the Registry fixes only work for applications that use SCHANNEL (the built-in SSL/TLS provider for Windows). For the most part, that will just be built-in Windows components and some other Microsoft products. (Internet Explorer & IIS being the most obvious ones.) Many third-party programs will have their own SSL/TLS implementations built-in, which will have to be configured separately. – Iszi Sep 10 '15 at 21:19
  • That's good to know. The main use case is configuring an ASP.NET application to make requests using TLS 1.1 and greater. – Shaun Luttin Sep 10 '15 at 21:22
  • 2
    BTW: Have you tried Fiddler? It's a bit more specialized for web debugging than WireShark. I find it generally easier to use in many situations. – Iszi Sep 10 '15 at 21:28
  • @Iszi I have tried Fiddler though I did not know that it can detect the SSL/TLS version. – Shaun Luttin Sep 10 '15 at 21:29
  • 1
    I don't think I've ever actually tried using it for that particular purpose, but since it can go so far as to intercept & decrypt HTTPS traffic (and in a pretty easy, user-friendly manner no less) I'd think that should be possible. Firebug may or may not also be of use, if you're doing this client-side and have Firefox handy. Also, do make sure both the server *and* client OS & applications are properly configured. – Iszi Sep 10 '15 at 21:36
  • 1
    Nice thing about Firebug is you don't have to install certs for SSL intercept - since it's a MitB instead of MitM, it already has access to the cleartext. – Iszi Sep 10 '15 at 21:38
  • 1
    The first filter should be `ssl.handshake.type == 1` (not 2). – dave_thompson_085 Sep 11 '15 at 06:03
  • While you have enough answers on how to snoop the version, this will not actually help. Servers will usually negotiate a higher version if available, regardless of wether a lower version would be allowed. What you want to do is set up a test server that only supports TLS 1.1 and see if your client correctly refuses to connect. – averell Feb 01 '20 at 10:12

2 Answers2

12

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:

SSL ServerHello in 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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • So, how do we know what protocol version the client is requesting? Isn't that in the Client Hello? – Shaun Luttin Sep 10 '15 at 21:58
  • 1
    In the `ClientHello`, the client sends the maximum version that it supports. Then the server chooses, usually by using the highest version that both client and server support. Note that nowhere in the handshake will you find any indication of how low the client or the server would accept to stoop; that the client says "TLS-1.2" does not mean that the client would have refused to do some TLS-1.0... – Thomas Pornin Sep 11 '15 at 00:41
  • 2
    @ShaunLuttin To emphasize, **ClientHello does not tell you the minimum the client will accept**. You must **try connecting to a server that responds with lower protocol versions** and see if the client accepts or aborts. Depending on your undescribed app server(s), it may be easy, difficult or impossible for it to do that. If your client app can do at least one path-only (no query) GET request that accepts a static textual reply, you can use `openssl s_server` with `-WWW` (note uppercase) to serve a static file (or several) under manually specified protocol versions and see which are accepted. – dave_thompson_085 Sep 11 '15 at 06:13
4

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.

Octotopos
  • 91
  • 1
  • 1
  • 3