TLS 1.0, 1.1 test active when blocked
Reported by
larrylac...@yahoo.com,
Nov 11
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Example URL: https://tls-v1-1.badssl.com:1011/ Steps to reproduce the problem: 1. In Windows Settings Internet Options> Advanced: uncheck TLS 1.0, 1.1 2. test with badssl TLS 1.1 or 1.0 https://tls-v1-1.badssl.com:1011/ 1.1 or https://tls-v1-1.badssl.com:1010/ 1.0 or 3. run ssllabs client check https://www.ssllabs.com/ssltest/viewMyClient.html What is the expected behavior? The badssl pages should be blocked, ssllabs client report should not show TLS 1.0 and 1.1 as Yes In Edge the badssl pages are blocked ('Can't connect securely') and the ssllabs client report shows 1.0 and 1.1 as No. What went wrong? On generic, industry standard SSL test pages, TLS 1.0 and 1.1 still work, although disabled at the OS network stack level. On the badssl test pages the OIB padlock displays as secure the TLS 1.0 or 1.1 content is displayed On the ssllabs client report, TLS 1.0 and 1.1 display Yes See attached. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 70.0.3538.102 Channel: stable OS Version: 10.0 Flash Version: This is obviously a low impact security TLS bug, but if I create the CR under Security I won't be able to track it. I tested with old 65.0.3325.181, stable 70.0.3538.102 and canary 72.0.3607.0, as TLS 1.0, 1.1 will be deprecated in M72 bug 896013, see also Platform Status: https://www.chromestatus.com/feature/5654791610957824 I'm not sure if this a problem in the test reporting or in Chrome, but Edge behaves as expected.
,
Nov 11
Looks like this is a rehash duplicate of bug 391955 - The UI proxy settings options are still misleading. This CR was a follow up on an 11/09 user report here: https://productforums.google.com/forum/#!topic/chrome/vr5od3KJpUo
,
Nov 11
The only part of this CR that doesn't overlap with 391955 is the OIB padlock status for the badssl tests, which should downgrade from secure.
,
Nov 11
,
Nov 12
Thanks for the issue... As per comment #0, the issue seems to be related to test with badssl TLS 1.1 or 1.0. Hence, CC'ing dev for further inputs on it.
,
Nov 12
,
Nov 12
Those settings are for Edge and IE, not Chrome. If you wish to disable TLS 1.0/1.1, use the SSLVersionMin enterprise policy (or wait until https://security.googleblog.com/2018/10/modernizing-transport-security.html happens in 2020).
,
Nov 13
Run the badssl.com TLS 1.0 or 1.1 tests Observe that the omnibox OIB secure padlock status doesn't downgrade. This is the best we can do? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by larrylac...@yahoo.com
, Nov 11