Con HTTPS, ¿qué información podría recopilar un atacante MitM?

Con MitM a través de un sitio web HTTPS, la mayor amenaza proviene de la capacidad de reemplazar el certificado SSL del sitio con su falso. Sí, el usuario recibirá una advertencia de que el sitio no coincide con el certificado, pero es probable que los usuarios simplemente hagan clic en continuar. Una vez que el certificado ha sido reemplazado, puede descifrar todas las comunicaciones ya que tiene la clave privada para su propio certificado.

Si asumimos que él no reemplaza el certificado, entonces tiene razón al decir que no hay mucho que pueda deducir al escuchar la conexión. Creo que has cubierto la mayoría de los puntos.

En una conexión SSL, la parte GET o POST está encriptada. Por ejemplo: visitante: enlace

www.yoursite.com          visible 
GET /shoppingcart.aspx    encrypted
HTTP/1.0                  encrypted

Lo que estás pensando se llama ataque de inferencia , donde con poca información, un atacante puede poner juntos piezas de un rompecabezas. Así que preguntas:

  

Si el hacker sabe qué hace el sitio y qué se espera que sea   descargado o publicado en él, me imagino que sería capaz de hacer ejercicio   aproximadamente lo que el usuario está haciendo solo por el tamaño de los datos de cada https   solicitud / respuesta.

Este no es necesariamente el caso. Nuevamente, dado que tanto un GET como un POST están encriptados, en cierta medida sería un juego de adivinanzas sin valor. Considera lo siguiente:

Ejemplo A

Site contains 1mb file called topsecret.docx
Visitor uploads a 1mb video of cats

Lo que verá:

Site <--> 1mb session <--> Visitor

Debido a que GET y POST están encriptados, no hay forma de que usted determine si el usuario ha descargado o subido. Todo lo que estás viendo es un intercambio de 1mb. Cualquier atacante perdería mucho tiempo y recursos en un juego de adivinanzas, sin embargo, considere un tercer sitio en la mezcla.

Ejemplo B

Site A contains 1mb file called topsecret.docx
Visitor does something
Visitor visits Site B
Site B now contains topsecret.docx

Lo que verá (por supuesto, mediante el rastreo de la red):

   Visitor <--> Site A (1mb session)
   Visitor <--> Site B (1mb session)

Si pudiera encontrar los mismos documentos en ambos sitios, podría inferir que el visitante fue al sitio a, descargó un archivo y luego visitó el sitio b donde apareció el archivo. Podría md5 para documentar aún más la prueba, sin embargo, tendría que encontrar el archivo inicial. De lo contrario, el visitante podría haber visitado ambos sitios y haber subido o descargado videos de gatos.

Sería más fácil para alguien con los recursos llevar a cabo este tipo de ataque, simplemente para MiTM en los sitios con certificados robados, sslstrip o algún otro truco en lugar de jugar un juego de adivinanzas.

MODIFICADO PARA RESPONDER el comentario de Lekensteyn

Lekensteyn, agregué un ejemplo ficticio para ilustrar un punto. Y sigue siendo cierto, así que te daré otro ejemplo

El sitio A contiene 2 archivos (File1 (1mb) y File2 (200mb)

Visitor <--> download File2 <--> SiteA 

En lo anterior, el visitante está descargando un archivo de 200 mb y, al comenzar, detiene la sesión en 1 md. Como no puede ver lo que hizo, el análisis de tráfico muestra que la sesión fue una conexión de 1 MB. Lo que verás:

Visitor <--> 1mb session <--> Site A

¿Estaría dispuesto a apostar a su último dólar que el visitante descargó el Archivo 1 en función del tamaño? En mi ejemplo, utilicé un mecanismo burdo para ilustrar mi respuesta. Hubo muchos detalles con los que podría haber entrado en detalles, pero elijo no por brevedad

  

El hecho de que el usuario va al sitio en absoluto. Supongo que es probable que hubiera una solicitud de DNS para el nombre de dominio y que esa solicitud no se hubiera cifrado, por lo que el pirata informático sabe al menos que el usuario está accediendo a este sitio específico.

Sí, la solicitud de DNS revelará el nombre del host si la solicitud de DNS puede ser MITM'd y la IP de destino y el puerto de la conexión HTTPS también están visibles en texto sin cifrar para poder enrutarlos al servidor. Si SNI está habilitado en el cliente, el nombre del dominio también se transmite en texto claro, si no es el SubjectAltNames devuelto en el certificado indicará un nombre de dominio o una pequeña lista de posibles nombres de dominio que pueden ser fáciles de restringir dependiendo del conocimiento del atacante Puede tener de otras fuentes.

  

URL: ¿Están las URL reales de la solicitud cifradas, así como el contenido? De lo contrario, algunas URL pueden contener información útil para el atacante (es decir, qué páginas se han solicitado, los números de identificación de los datos solicitados, etc.)

Las URL son privadas durante una sesión HTTPS. Entonces, si el usuario va a https://example.com:444/buyThing/thing.php?id=123 , solo sería posible que el MITM determinara que el destino era example.com en el puerto 444 sobre TLS.

  

El tamaño de los datos transmitidos: si el pirata informático sabe lo que hace el sitio y lo que se espera que se descargue o publique en él, supongo que sería capaz de averiguar aproximadamente lo que el usuario está haciendo solo con el Tamaño de los datos de cada solicitud / respuesta https. Por ejemplo, si el propósito del sitio es permitir a los usuarios descargar documentos protegidos, el pirata informático podría deducir cuál de los documentos del sitio ha descargado el usuario.

Sí, es posible que la cantidad de datos se utilice en un ataque de canal lateral .

  

Tiempos de solicitud / respuesta: similar al anterior, si el pirata informático tiene conocimiento del sitio y sabe que una página en particular tiene un tiempo de respuesta lento, podría deducir cuándo el usuario fue a esa página.

Sí, esto es cierto y es como la vulnerabilidad de canal lateral / sincronización descrita aquí .

  

¿Cuánto de lo anterior es realmente factible? ¿Tendría razón en preocuparme por ellos si estoy desarrollando un sitio sensible? ¿Hay otros ángulos que no haya pensado?

Bueno, todos son factibles. El nombre de dominio que se revela es más un problema de privacidad para el individuo que un problema de seguridad. Si a ellos mismos les preocupa esto, tendrían que usar un servicio como TOR.

Consulte esta respuesta para conocer algunas de mis otras ideas sobre lo que un MITM puede ver, como URL en el encabezado referer si el sitio y / o el navegador manejan estos datos de manera incorrecta.

Otros tipos de ataques de canal lateral como estos también pueden ejecutarse, como cuando un autocompletado a través de HTTPS puede llevar a que se determinen los caracteres debido al pequeño tamaño de los datos cifrados.