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?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
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:
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.
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:
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.
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.
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
<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
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.
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.
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