New issue
Advanced search Search tips

Issue 687067 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Chrome Does not label page as Not Secure when reverse proxy in use on site

Reported by jasonod...@gmail.com, Jan 31 2017

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://www.chromium.org/Home
/chromium-security/security-faq

Please see the following link for instructions on filing security bugs:
http://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.

When accessing an site that does not implement TLS, chrome shows Not Secure in the address bar (omnibox) as expected in the new version.
However, when accessing a non-encrypted site which is using a reverse proxy Chrome does not display this.

VERSION
Chrome Version: 56.0.2924.76  + stable
Operating System: Debian GNU/Linux 8.7 (jessie)
REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

This can be reproduced by accessing a non-encrypted site and a site that is using a reverse proxy. In this test, Nginx was used. 

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab, browser, etc.]
Crash State: [see link above: stack trace, registers, exception record]
Client ID (if relevant): [see link above]

 
Labels: -Restrict-View-SecurityTeam
Status: WontFix (was: Unconfirmed)
That's correct; Chrome only has the ability to detect the security of the connection from the browser to the endpoint that terminates the TLS connection. In the case of a reverse proxy, that's often the proxy itself. That's not to say that reverse proxies are inherently non-secure (the proxy could communicate to the application server over TLS itself, or by using other security mechanisms, network isolation, etc).

If you're suggesting that the URL in the URL Bar in the scenario described *doesn't* start with HTTPS:// (implying that the reverse proxy isn't using TLS either), please reopen this issue. That would be a great surprise, and a bug.

Sign in to add a comment