Desde que actualicé Firefox a la versión 38, encuentro un problema al enviar un formulario específico en el sitio web https://usercenter.checkpoint.com/ La mayor parte del sitio web funciona normalmente pero envía un formulario durante la apertura de un ticket de soporte (URL en el registro a continuación ) hace que Firefox falle en la negociación de TLS. La página de error de Firefox no explica casi nada:
Conexión Segura Fallida
La conexión al servidor se restableció mientras se cargaba la página.
- La página que está intentando ver no se puede mostrar porque no se pudo verificar la autenticidad de los datos recibidos.
- Póngase en contacto con los propietarios del sitio web para informarles de este problema.
Informar este error
Informar la dirección y la información del certificado de usercenter.checkpoint.com nos ayudará a identificar y bloquear sitios maliciosos. ¡Gracias por ayudar a crear una web más segura!
Informar automáticamente errores en el futuro Más información ...
En la consola del desarrollador web solo veo esto:
19:58:44.470 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 AjaxCall
19:58:44.589 POST https://usercenter.checkpoint.com/usercenter/portal/js_pane/supportId,CreateServiceRequestId [178ms]
La primera línea es solo una advertencia de que en el futuro SHA-1 no será compatible. ¿Tengo que encender algo para ver la causa de la falla de TLS? El TLS y la información del certificado de la consola se encuentran a continuación:
No veo nada malo allí. Desesperado, intenté jugar con los parámetros TLS about:configsin éxito:
security.tls.insecure_fallback_hosts
security.tls.unrestricted_rc4_fallback
security.tls.version.fallback-limit
security.tls.version.max
security.tls.version.min
La prueba SSL de Qualy no muestra nada completamente incorrecto: https://www.ssllabs.com/ssltest/analyze.html?d=usercenter.checkpoint.com
Hay un artículo prometedor en la base de conocimiento de Red Hat: Firefox 38 y servidores SSL / TLS que son intolerantes a la versión TLS pero la solución está disponible solo para clientes de pago.
También he comprobado la compatibilidad del sitio para Firefox 38 .
Preguntas
- ¿Cómo puedo solucionar cuál es el motivo del error de TLS?
- En Firefox, ¿hay alguna otra lista blanca configurable por el usuario donde pueda intentar agregar la dirección del sitio web que falla?
- ¿Cuáles podrían ser los motivos por los que no aparece solo después de enviar un formulario determinado mientras la consola muestra que la solicitud POST va al mismo host
usercenter.checkpoint.comque la comunicación exitosa anterior?
{Distinguished Name, Serial Number}hace que el certificado sea único, por lo que puede seleccionarse sin ambigüedades; ver RFC 4158 . Pero vea las advertencias a continuación sobre cómo seleccionarlo porque no es algo fácil de hacer. Además, Checkpoint no debe enviar el antiguo certificado G5 como parte de la cadena.Respuestas:
Uso
openssl s_client. Es una navaja suiza para cosas como esta. Y usaropenssl x509para volcar certificados.Usualmente estás interesado en los
{Issuer, Subject}pares de la cadena como este:Observe cómo el emisor en el servidor se convierte en el sujeto para el próximo certificado superior. Gutmann proporciona el siguiente diagrama para describirlo en su libro Engineering Security :
En la parte superior, la raíz de CA está auto firmada, y el problema y el tema son los mismos. Si hubiera un nivel 3, sería:
Pero generalmente no lo ves en una cadena porque debes confiar en él. Y parte de los requisitos para el ancla de confianza es que ya lo tiene para asegurarse de que no sea manipulado.
El uso de nombres de sujeto y emisor es utilizar lo que se denomina nombres distinguidos . La otra forma de formar una cadena es con
KEYIDs. A veces lo verá a través del Identificador de clave de sujeto (SKI) y el Identificador de clave de autoridad (AKI). Los identificadores de clave son solo huellas digitales de una clave pública digerida.Puede encontrar lecturas sobre nombres distinguidos en estándares como RFC 4514 ; y el uso de KEYID en estándares como RFC 4518 , que se ocupa de la construcción de rutas.
Parece que el problema es con el navegador (pero ver más abajo). Parece que le falta la
Class 3 Public Primary Certification Authorityhuella digitala1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b.Cuando visito los certificados raíz de Symantec y descargo la autoridad de certificación primaria pública de Clase 3 , puedo crear una ruta para la validación (observe lo
Verify return code: 0 (ok)siguiente)Debe descargar e instalar
Class 3 Public Primary Certification Authorityen la tienda raíz de confianza de su navegador. O determine por qué el navegador no lo está utilizando para construir la ruta (ver a continuación).Mozilla y Firefox hablan
Class 3 Public Primary Certification Authorityen una publicación de blog: Eliminación de certificados con claves RSA de 1024 bits . Según la publicación, han dejado de usar ese certificado de CA desde Firefox 32. Realmente no los culpo, ya que estas claves se usan a largo plazo para las operaciones de firma de CA y necesitan parámetros "más fuertes" porque tienen que vivir de 10 a 30 años. (literalmente).Checkpoint necesita obtener un nuevo certificado de servidor emitido bajo un certificado (cadena) con parámetros contemporáneos, como una CA con un módulo RSA de 4096 bits y SHA-256. O una CA subordinada con un módulo RSA de 2048 bits y SHA-256 ...
(También vea lo que no funcionó para mí a continuación).
Aquí hay un ejemplo de validación del certificado del servidor con la Autoridad de certificación primaria pública de clase 3 utilizando OpenSSL
s_client:Anteriormente dije "En la parte superior, la raíz de CA está auto firmada, y el problema y el tema son los mismos" . Aquí hay un volcado de esa raíz CA autofirmada, donde el Asunto y el Emisor son iguales. También muestra los módulos de 1024 bits y sha1WithRSAEncryption.
Anteriormente dije "Checkpoint necesita obtener un nuevo certificado de servidor emitido bajo un certificado (cadena) con parámetros contemporáneos, como una CA con un módulo RSA de 4096 bits y SHA-256. O una CA subordinada con un módulo RSA de 2048 bits y SHA-256 ... " .
Esto es lo que no funcionó para mí: enraizar o anclar la confianza en la CA subordinada más fuerte
VeriSign Class 3 Public Primary Certification Authority - G5, y no en la CA raíz de 1024 bits más débil.EDITAR : esto se debe a un error en OpenSSL 1.0.2ay debajo. Fue corregido en OpenSSL 1.0.2b. Consulte ¿ Comportamiento esperado para la verificación cuando un subordinado en una cadena es promovido a una raíz autofirmada?
El problema práctico es que Symantec vuelve a emitir un certificado con el mismo nombre y la misma clave pública, por lo que el nombre distinguido , el identificador de clave de sujeto y el identificador de clave de autoridad no cambiaron; pero solo cambiando el número de serie .
Pude detectarlo a continuación debido a los diferentes números de serie entre el certificado enviado en la cadena y el descargado del sitio de Symantec. Luego se hizo evidente que el certificado reemitido se cambió de una CA subordinada a una CA raíz.
Puede usar
-showcertscon OpenSSLs_clientpara ver los certificados en la cadena:Lo que normalmente hago a continuación es copiar un certificado codificado PEM en la cadena a un portapapeles, y luego usarlo
pbpastepara pegarlo en un terminal y conectarlo a OpenSSLx509. Por ejemplo, aquí seVeriSign Class 3 Public Primary Certification Authority - G5envía el Nivel 2 como parte de la cadena:fuente
Esto se soluciona escribiendo: config en la barra de direcciones, luego seleccionando "¡Tendré cuidado, lo prometo!" botón. En ese momento, haga doble clic en la opción security.tls.insecure_fallback_hosts y luego agregue la dirección a la que está intentando acceder.
Tuve que eliminar el "https: \" (poner ambas barras diagonales inversas, el superusuario eliminó el segundo) de mi dirección para que funcione, pero sus resultados pueden variar, así que quizás intente con ambos.
Esto es exacto a partir de Firefox versión 43.0.1.
fuente
security.tls.insecure_fallback_hostsese no era el caso. Más tarde, en un comentario, escribió que el problema estaba en el lado del servidor. El servidor estaba cerrando las conexiones.Si observa la Autoridad de certificación primaria pública de VeriSign Clase 3 - G5 proporcionada en la cadena con
openssl s_client ... -showcertsy la Autoridad de certificación primaria pública de VeriSign Clase 3 - G5 disponible para descargar, verá que son certificados diferentes. Por lo tanto, Verisign volvió a emitir un certificado con el mismo nombre distinguido y clave pública del sujeto .La versión en cadena de VeriSign Class 3 Public Primary Certification Authority - G5 tiene el siguiente número de serie, y no está autofirmado (observe que el Sujeto y el Emisor son diferentes):
La versión descargada de Symantec Root Certificates de VeriSign Class 3 Public Primary Certification Authority - G5 tiene el siguiente número de serie y está autofirmado (observe que el Asunto y el Emisor son los mismos):
Realmente solo hay una solución aquí.
El punto de control debe dejar de enviar la versión anterior VeriSign Class 3 Public Public Certification Authority - G5 subordinado en la cadena.
Esto se debe a que, en la práctica, esas rutas de verificación y selección de certificados se confundirán porque el antiguo certificado G5 y el nuevo certificado G5 son demasiado similares. Son demasiado similares porque usan el mismo nombre distinguido y el mismo identificador de clave de sujeto / identificador de clave de autoridad .
En teoría, podría extraer el antiguo certificado G5 de la cadena enviada por el servidor y ponerlo en la tienda Mozilla Trust. Pero sospecho fuertemente que confundirá a los agentes de usuario que intentan construir una ruta porque lo único que cambió es el número de serie.
Para comprender la confusión, mire RFC 4158 y cómo seleccionar un certificado. Una forma es la
{Distinguished Name, Serial Number}tupla. Pero un certificado que se verifica no incluye el número de serie del emisor. Solo incluye el nombre distinguido y el identificador de clave de autoridad .La sección 3.5.12 Identificadores clave coincidentes (KID) especifica:
Pero no es obligatorio, y falta en el warez que Symantec proporcionó. Para verlo de primera mano, descargue el nivel 1 intermedio enviado en la cadena. Se llama VeriSign Class 3 Secure Server CA - G3 . Observe que tiene un identificador de clave de autoridad , pero no un número de serie :
fuente