HTTPS responses with HTTP/5xx errors and no body show as neutral (i)
Reported by
jonat...@inikup.com,
Aug 21 2017
|
||||||||||
Issue descriptionChrome Version : 60.0.3112.90 OS Version: OS X 10.12.6 URLs (if applicable) : - https://httpbin.org/status/500 - https://httpbin.org/status/501 - https://httpbin.org/status/502 - https://httpbin.org/status/503 - https://httpbin.org/status/504 Other browsers tested: Safari 10.1.2: OK Firefox 55.0.2: OK Chrome 60 (Windows 10): FAIL What steps will reproduce the problem? 1. Go to https://httpbin.org/status/200 2. This page is labelled as "Secure" in the omnibox. 3. Go to https://httpbin.org/status/50{0,1,2,3,4} 4. These pages are labelled as "Not Secure". What is the expected result? Pages with a valid TLS certificates chain must be marked as Secure, irrespective of the HTTP response code. What happens instead of that? Pages with HTTP response code 500, 501, 502, 503 and 504 are labelled as "Not Secure". UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
,
Aug 22 2017
Able to reproduce the issue on Windows 7,Mac 10.12.6 & Ubuntu 14.04 using chrome stable#60.0.3112.101 & latest Canary#62.0.3192.0 as per the URL's in comment#0. 1. https://httpbin.org/status/200 ->labelled as "Secure" in the omnibox 2. https://httpbin.org/status/500 & 501....etc -> Observed server error Manual bisect info: ------------------ Good-45.0.2454.101 Bad-46.0.2490.71 As good and bad builds are from 2 different milestones,please find the below CL from omahaproxy. https://chromium.googlesource.com/chromium/src/+log/45.0.2454.0..46.0.2490.0?pretty=fuller&n=10000 Unable to pinpoint single suspect from the above CL.Hence marking it as 'Untriaged' to get more inputs from Dev. Please find the attached screencast for reference.Could some one from dev team please look into this issue. Thanks.
,
Aug 24 2017
,
Sep 1 2017
Another one Emily....
,
Sep 4 2017
Hm, apparently if a server sends a 50x status code with an empty body, Chrome shows its own error page: https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?type=cs&sq=package:chromium&l=3963 I could be convinced that this either is or isn't a bug. On the one hand, we successfully connected to the server and got a response, so we should show the connection information. On the other hand, we're not showing the actual response from the server, so it's a little weird to show Secure: we're not showing what the server actually sent.
,
Sep 4 2017
I think this is bug because: - We are connected securely to the server. - Even if Chrome inject its own HTML code in the response, this one is "under control": its not arbitrary data but a predefined HTML code who do not alter the security of the connection.
,
Sep 13 2017
Issue 763945 has been merged into this issue.
,
Sep 13 2017
,
Oct 23 2017
,
Nov 10 2017
,
Feb 18 2018
,
Feb 24 2018
@elawrence This also happens on https 4xx errors, and data: URIs (e.g. base64 PNG). Although the latter might still want to be considered insecure. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by nyerramilli@google.com
, Aug 21 2017