Cómo detectar certificados SSL "falsificados" desde el extremo del servidor web

Si entiendo la pregunta correctamente, está preguntando si es posible detectar (en el extremo del servidor de una conexión HTTPS) si la conexión proviene de un servidor proxy o un cliente real (un navegador).

(Inicialmente no pude ver cómo el certificado proporcionaría información valiosa, pero ahora me doy cuenta de lo que me perdí antes. Lo que se sugirió es proporcionar al usuario un javascript, activarlo a través del código HTML y el usuario devuelve los datos extraídos del certificado SSL como lo sería el certificado proporcionado por el proxy. Sí, eso debería funcionar y parece un poco improbable que el servidor proxy filtre tales "acciones" del javascript. Sugerencia inteligente ! )

Analizar lo siguiente puede ayudar a descubrir el originador de una conexión:

• ordenamiento de encabezado HTTP
• encabezados HTTP no específicos del navegador
• valores HTTP-cookie
• comportamiento HTTP

Ordenación de encabezado HTTP - La detección del originador de la conexión debería ser teóricamente posible mediante el análisis del orden de los encabezados HTTP. Los navegadores tienden a estructurar sus encabezados HTTP en "patrones" específicos, utilizando este conocimiento puede ser posible:

1. Cree una huella digital única para el proxy al determinar cómo el proxy organiza los encabezados HTTP.
2. Por "de antemano" sabiendo cómo los navegadores comunes ordenan sus encabezados HTTP y lo comparan con el orden de la solicitud actual. (Claramente no es la mejor idea ...)

Encabezados HTTP no específicos del navegador - Es posible que el servidor proxy incluya encabezados HTTP específicos que un navegador no. Estos pueden ser para equilibrar la carga, o solicitar redirecciones de tipo y así sucesivamente.

valores HTTP-cookie - También es posible que el proxy inserte un valor de cookie específico para establecer una conexión con un servidor específico si se utiliza el equilibrio de carga o la agrupación en clústeres.

Comportamiento HTTP - Si bien no es exactamente fácil de implementar, puede ser posible detectar la presencia de un proxy al iniciar una serie de códigos de retorno específicos de HTTP y analizar cómo responde el "cliente" a las solicitudes. Quizás esto pueda permitir la detección de un comportamiento inusual que sería considerado poco común para los navegadores normales.

Asumiendo un servidor HTTP Apache puede ser posible usar reglas de seguridad de mod para lograr algunos de los anteriores.

Algunas otras formas, probablemente improbables y poco confiables, de detectar el origen de una conexión serían inspeccionar campos específicos del protocolo (IP / TCP), como sellos de tiempo, opciones de IP. Estos pueden cambiar de maneras particulares asumiendo un origen de servidor proxy.

También puede ser posible determinar el origen en función de los tiempos, a pesar de que estarían sujetos a un poco de vibración y ruido, en teoría podría determinarse si un proxy intercepta la conexión. No estoy sugiriendo que esto sea confiable o incluso posible, pero se puede determinar bastante a través de los tiempos.

La única forma que puedo ver es abrir una solicitud XMLHTTP sobre SSL y retirar el certificado de esa conexión:

• MDN: Cómo verificar el estado del estado del estado del estado de la bolsa: ( archivo )

Esto no funciona desde una página web, pero se requiere que se ejecute desde una extensión.

Como ya se señaló, el proxy puede cambiar fácilmente el javascript para eliminar esto.

Si el servidor usa autenticación de cliente basada en certificados (es decir, cliente también tiene un certificado y usa su clave privada para autenticarse), entonces el servidor detectará el interceptor, porque en ese caso el cliente firma un valor de hash calculado sobre los mensajes de intercambio recibidos anteriormente, que incluyen el certificado del servidor como lo ve el cliente. En presencia del interceptor, el cliente firma el valor incorrecto y el interceptor no puede corregirlo.

Una solución alternativa es utilizar TLS con SRP , en el que la autenticación no se basa en certificados sino en contraseñas. mutuo.

De lo contrario, no.

Por convención, un proxy estándar debería incluir la solicitud HTTP para X-Forwarded-For encabezado , aunque no esté en el RFC se considera estándar de facto.

Dicho esto, si el proxy quiere ocultar su existencia, no hay problema para simplemente ignorar el poner este encabezado.

Estas respuestas están un poco anticuadas y los siguientes desarrollos recientes deberían ser relevantes:

enlace

  

Un Pin es una relación entre un nombre de host y un criptográfico      identidad (en este documento, 1 o más de las claves públicas en una cadena      de los certificados X.509). La validación de pin es el proceso que realiza una AU      para garantizar que un host se autentique de hecho con su      Pin establecido.

     

La fijación de claves es un mecanismo de confianza en el primer uso (TOFU). La primera vez   una UA se conecta a un host, carece de la información necesaria para
  realizar la Validación de Pin; Los AU solo pueden aplicar su criptografía normal.   validación de identidad. (En este documento, se supone que los AU se aplican   Validación de la cadena de certificados X.509 de acuerdo con [RFC5280].)

     

La UA no podrá detectar e impedir que un MITM ataque al
  Primera conexión de UA al host. (Sin embargo, el requisito de que
  El MITM proporciona una cadena de certificados X.509 que puede pasar los
de la UA   Los requisitos de validación, sin error, mitigan este riesgo.   algo.) Peor aún, tal MITM puede inyectar su propio encabezado PKP en el   Transmisión HTTP, y pin la UA a sus propias claves. Para evitar post facto
  Detección, el atacante tendría que estar en posición de interceptar
  todas las futuras solicitudes al host desde esa UA.

     

Por lo tanto, la fijación de claves como se describe en este documento no es un elemento perfecto.   Defensa contra atacantes MITM capaces de pasar la cadena de certificados
  Procedimientos de validación: nada menos que las claves precompartidas pueden ser.
  Sin embargo, proporciona un valor significativo al permitir que los operadores de host a
  limitar el número de autoridades de certificación que pueden responder por el   la identidad del host y permite que los agentes de usuario detecten los ataques MITM en proceso
  después de la comunicación inicial.

...

  

2.1.4. La directiva report-uri

     

La directiva OPCIONAL de informe-uri indica la URI a la que la UA   DEBE informar los fallos de validación de pines (Sección 2.6). Los UA POSTs
  los informes a la URI dada como se describe en la Sección 3.

Además de estar estandarizado, creo que actualmente es compatible con al menos Chrome y Firefox, pero tendría que verificarlo.