Chrome: su conexión es privada pero alguien podría cambiar el aspecto de la página

La página que muestra su navegador en la pantalla puede contener muchos elementos: el código HTML, CSS, imágenes, etc. También parte del contenido puede ser proporcionado, mejorado o alterado por scripts (legítimos) descargados del sitio. . Estos elementos pueden incluirse desde el mismo servidor o desde otros servidores.

Para que Chrome muestre el mensaje "Su conexión a este sitio es privada", para cada elemento de la página:

• se debe establecer una conexión HTTPS cifrada
• el certificado del sitio (identidad) debe ser válido
• deben utilizarse protocolos y algoritmos no obsoletos

Si uno o más de los elementos se incluyen a través de un enlace HTTP no cifrado, entonces:

• si se trata de un script, Chrome mostrará un mensaje:

    

  Su conexión a este sitio no es privada porque el sitio cargó un script inseguro.

  En tal caso, existe la posibilidad de que el script haya sido reemplazado por uno malicioso. Cualquier información que reciba del sitio o que se envíe al sitio se puede interceptar y modificar.

• si es (solo) un contenido pasivo (como una imagen), Chrome mostrará un mensaje:

    

  Su conexión a este sitio es privada, pero alguien en la red podría cambiar el aspecto de la página.

  En tal caso, nadie podrá rastrear sus datos o leer la información que el sitio proporcionó. Sin embargo, al modificar el aspecto de la página, es posible que se le engañe para que realice una acción que originalmente no tenía la intención de realizar, por ejemplo, restablecer su contraseña. Aunque el cambio de contraseña en sí sería seguro y legítimo, podría beneficiar al atacante.

  Además, este mensaje no es 100% exacto. Según el contenido pasivo real que se incluya, un atacante pasivo puede deducir qué acciones tomó usted en el sitio cifrado. A diferencia de HTTPS, con HTTP, la URL completa sería visible, por lo que si una determinada página cargase un conjunto único de iconos, un atacante podría decirle que llegó a esa página.

la respuesta de techraf tiene una gran explicación general, solo quiero agregar la causa directa en la página que identificó en tu comentario :

  

enlace

La advertencia que le da Chrome es un poco confusa, pero el problema específico en esta página es el botón Buscar en la parte superior, que forma parte de un formulario que contiene un punto final que no es HTTPS:

<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 se está quejando del destino HTTP de ese formulario.

La forma en que puedes averiguarlo es:

1. Haz clic en el icono a la izquierda de la URL en la barra de direcciones para que aparezca la advertencia.
2. Haga clic en "detalles" debajo. Verás algunos detalles.
3. En este caso, hay otro pequeño icono de advertencia en la parte superior derecha de la ventana de análisis. Esto abrirá la consola (también puede omitir estos primeros 3 pasos y simplemente abrir la consola del desarrollador, si ya está acostumbrado a hacer esto).
4. Aquí, por lo general, encontrará un mensaje más detallado, que contiene una descripción del problema e identifica el recurso problemático.
5. A la derecha de este mensaje encontrará el nombre de un archivo y un número de línea. Al hacer clic en él se abrirá la fuente de la página con el elemento en cuestión subrayado en rojo.

Este es mi intento de grabar ese proceso en un GIF animado (haga clic para verlo en resolución completa):

Lo siento, no sé qué riesgos están asociados con esto, pero esa es al menos la fuente precisa de la advertencia de Chrome. Espero que ayude.

Esto significa que el sitio cargó los recursos http solicitados en un enlace https. Un atacante podría manipular los recursos http y atacar a través de ellos. Si abre la consola, verá muchas advertencias de contenido mixto, que lo explican.
Referencia: enlace

Si golpeas la consola de Chrome, verás esto:

  

Contenido mixto: la página en   Se cargó ' enlace ' en un   Conexión segura, pero contiene un formulario que apunta a un inseguro.   punto final   ' enlace '.   Este punto final debe estar disponible a través de una conexión segura.

La inspección de esa url revela que es el <action> para un <form> que se envía a través de 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>

En cuanto a por qué dice "podría ser capaz de cambiar el aspecto", lo más probable es que se genere un mensaje genérico cuando hay elementos inseguros presentes. La mayoría de las veces estos serían medios, css o js. En este caso, es un <form> .

Si un recurso / activo / llamada / etc se solicita a través de HTTP, entonces no se aplica ningún cifrado. Esto significa que cualquier persona "en el medio" puede escuchar, recoger los datos, mitigarlos y transmitirlos. Si los datos estuvieran encriptados y usaran cifrados, secreto y TLS adecuados, no podrían escucharlos y, si lo hicieran, no "verían" los datos reales.

En realidad, este problema (contenido mixto) a veces puede ser muy peligroso.

Suponga que tiene el sitio enlace con una autenticación muy confiable, y todo pasa por HTTPS muy confiable, excepto una imagen pequeña que se usa en una (tal vez muy raramente utilizado) página por su dirección http (no https). p.ej. enlace ( problema A )

Ahora, suponga que la cookie de sesión (que se proporciona después de la autenticación exitosa) se usa sin el atributo 'seguro'. Esto no es muy bueno, pero es bastante seguro siempre y cuando no tengamos contenido mixto. ( problema B )

Ahora, si tenemos el problema A + problema B en el mismo sitio, cuando abra una página web con contenido mixto en enlace , el navegador solicite que la imagen sobre HTTP y la solicitud http tengan todas las cookies no seguras para el dominio example.com. Por lo tanto, MITM puede detectar lo más importante que se puede detectar en la red: cookie de autenticación de los encabezados de solicitud http (y también detectará esa imagen inútil del cuerpo de respuesta de http, esto realmente no es un problema. El problema está en la cookie). Ahora puede usar cualquier complemento del navegador del administrador de cookies para establecer su cookie a un valor de sniff y se registrará en ese sitio.

Esta es la situación ' dos bloqueos '. Cuando al menos uno de ellos está cerrado, la puerta está cerrada. Pero si se cortan ambas cerraduras, la puerta está abierta.

Creo que @Stoud lo ha clavado. aunque lo extraño es mirar el sitio que mencionó (a la ligera), parece que el certificado está bien y (estoy usando Firefox) no parece estar cargando ningún componente que no sea HTTPS / Seguro ... Dicho esto, ¿está usando un público? computadora (biblioteca o algo)? o su propia máquina. Podría ser posible que su máquina pudiera verse comprometida por un MitM o algún otro problema ... ¿posiblemente un servidor proxy / redireccionamiento incorrecto?

¿Has probado un navegador diferente?

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