Chrome: Your connection is private but someone might be able to change the look of the page

Question

I happened to come across this (govt) website which should be HTTPS-secured, but Chrome does not show the green lock. Instead it shows this:

What does it mean? How can attackers leverage this vulnerability?

Answer 1

The page that your browser displays on the screen might consist of many elements: the HTML code, CSS, images, etc. Also some of the content might be provided, enhanced, or altered by (legitimate) scripts downloaded from the site. These elements might be included from the same server or from other servers.

For Chrome to display the "Your connection to this site is private" message, for each element of the page:

• an encrypted HTTPS connection must be established
• site certificate (identity) must be valid
• non-deprecated protocols and algorithms must be used

If one or more of the elements is included through a non-encrypted HTTP link, then:

• if it is a script, Chrome will display a message:

  Your connection to this site is not private because the site loaded an insecure script.

  In such case there is a possibility that the script was replaced with a malicious one. Any data you receive from the site or sent to the site can be intercepted and changed.

• if it is (only) a passive content (like an image), Chrome will display a message:

  Your connection to this site is private but someone on the network might be able to change the look of the page.

  In such case no one would be able to sniff on your data or read the information that the site provided. However by altering the look of the page you might be tricked into performing an action you did not originally intend to, for example resetting your password. Although the password change itself would be secure and legitimate, it might benefit the attacker.

  Also, this message is not 100% accurate. Depending on the actual passive content being included, a passive attacker can deduce what actions did you take on the encrypted site. Unlike with HTTPS, with HTTP the full URL would be visible, so if a certain page loaded a unique set of icons, an attacker would be able to tell you reached that page.

Answer 2

techraf's answer has a great general explanation, I just want to add the direct cause in the page you identified in your comment:

https://egov.uscis.gov/crisgwi/go?action=offices

The warning that Chrome gives you is a bit confusing, but the specific issue on this page is the Search button at the top, which is part of a form that contains a non-HTTPS endpoint:

<form action="http://www.uscis.gov/portal/site/uscis/menuitem/" 
      method="get" name="searchForm">
    ...
    <input type="image" name="submit" 
           src="images/branding/searchButton.gif" 
           id="uscisSearchBtn" title="Search">
</form>

Chrome is complaining about the HTTP target of that form.

The way you can find this out is:

1. Click the icon to the left of the URL in the address bar to bring up the warning.
2. Click "details" underneath. You'll see some details.
3. In this case, there's another little warning icon on the top right of the analysis window. This will bring up the console (you could also skip these first 3 steps and just open up the developer console directly, if you're already used to doing this).
4. Here you will generally find a more detailed message, containing both a description of the issue and identifying the problematic resource.
5. To the right of this message you'll find the name of a file and a line number. Clicking it will open up the page source with the item in question underlined in red.

Here's my attempt at recording that process in an animated GIF (click it to view it in full res):

Sorry, I don't know what risks are associated with this, but that's at least the precise source of Chrome's warning. Hope that helps.

Answer 3

This means the site loaded requested http resources on an https link. An attacker could manipulate the http resources and attack through those. If you open the console, you will see many Mixed-Content warnings, which explain it.
Reference: https://productforums.google.com/forum/#!topic/chrome/NLTAR28lqU0

Answer 4

If you hit the Chrome console you will see this:

Mixed Content: The page at 'https://egov.uscis.gov/crisgwi/go?action=offices' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://www.uscis.gov/portal/site/uscis/menuitem.5600b9f6b2899b1697849110543f6d1a/'. This endpoint should be made available over a secure connection.

Inspecting for that url reveals that it's the <action> for a <form> being sent via http://

<form action="http://www.uscis.gov/portal/site/uscis/menuitem.5600b9f6b2899b1697849110543f6d1a/" method="get" name="searchForm"><label for="criteria" class="s508"><span>Search</span></label><input type="text" id="criteria" onblur="setSearchField(document.searchForm, this);" title="Enter search terms" onfocus="clearSearchField(this);" maxlength="50" value="Search" name="searchQuery"><input type="image" name="submit" src="images/branding/searchButton.gif" id="uscisSearchBtn" title="Search"></form>

As far as why it says "might be able to change the look" - most likely its a generic message triggered when insecure elements are present. Most of the time these would be media, css, or js. In this case it's a <form>.

If a resource/asset/call/etc is requested via HTTP, then there is no encryption applied. This means that anyone "in the middle" can listen in, pick up the data, mitigate it, and pass it on. If the data were encrypted, and using proper ciphers, secrecy, and TLS, then they could not listen in, and if they did, would not "see" the real data.

Answer 5

Actually, this (Mixed Content) problem sometimes can be very dangerous.

Assume you have site https://example.com/ with very reliable authentication, and everything goes over very reliable HTTPS except one small image which is used in one (maybe very rarely used) page by it's http (not https) address. e.g. http://example.com/img/hackme.png (problem A)

Now, assume that session cookie (which is given after successful authentication) is used without 'secure' attribute. This is not very good, but quite secure as long as we dont have mixed content. (problem B)

Now, if we have both problem A + problem B on same site, when you open web page with mixed content on https://example.com/, browser will request that image over HTTP and http request will have all non-secure cookies for example.com domain. So, MITM can sniff the most important thing that could be sniffed over network - authentication cookie from http request headers (and will also sniff that useless image from http reply body, this is really not a problem. problem is in cookie). Now he can use any cookie manager browser addon to set his cookie to sniffed value and he will be logged into that site.

This is 'two locks' situation. When at least one of them is locked - door is locked. But if both locks are hacked, door is open.

Answer 6

I think @Stoud pretty much nailed it. although the strange thing is in looking into the site you mentioned (lightly) seems the cert is okay and (I am using Firefox) does not seem to be loading any non HTTPS / Secure components... That being said are you using a public computer (library or something)? or your own machine. It could be possible your machine could be compromised by a MitM or some other issue... possibly a bad proxy server / redirect?

Have you tried a different browser?

https://egov.uscis.gov
Version: 1.11.7-static
OpenSSL 1.0.2i-dev  xx XXX xxxx

Testing SSL server egov.uscis.gov on port 443

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
Accepted  TLSv1.2  256 bits  AES256-SHA256                
Accepted  TLSv1.2  256 bits  AES256-SHA                   
Accepted  TLSv1.2  128 bits  AES128-SHA256                
Accepted  TLSv1.2  128 bits  AES128-SHA                   
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Preferred TLSv1.1  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.1  256 bits  AES256-SHA                   
Accepted  TLSv1.1  128 bits  AES128-SHA                   
Accepted  TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Preferred TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.0  256 bits  AES256-SHA                   
Accepted  TLSv1.0  128 bits  AES128-SHA                   
Accepted  TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  egov.uscis.gov
Altnames: DNS:egov.uscis.gov
Issuer:   Symantec Class 3 Secure Server CA - G4

Not valid before: Nov 12 00:00:00 2015 GMT
Not valid after:  Nov 12 23:59:59 2017 GMT