Pero luego surgen preguntas menos ambiguas, por ejemplo: ¿es el soporte para TLS_RSA_EXPORT_WITH_RC4_40_MD5 un "sombrero" completo o simplemente un inconveniente? ¿Y si este conjunto de cifrado de los
Como resultado, nació una metodología para compilar un índice, que permite evaluar formalmente el grado de confiabilidad de una conexión HTTPS en 31 puntos, divididos en 5 grupos, desde "esto no es HTTPS en absoluto" hasta "¡sigue así!"
Lo que definitivamente no es el índice es la "respuesta rusa" a NIST / HIPAA / PCI DSS, etc. por dos razones.
Primero, el índice solo considera la confiabilidad de la conexión HTTPS. Rendimiento del servidor web (NPN / ALPN / reanudación de la sesión), etc. índice de materia no considera, no para eso fue inventado.
El segundo es que NIST.SP.800 y otros estándares de la industria se guían por las curvas elípticas del NIST, en las que hay poco más que ninguna confianza, pero hay preguntas desde el punto de vista de ECDLP / ECC (un comentario alegre sobre un sombrero de aluminio se puede dejar en los comentarios sin excepción ).
Aunque quién sabe, tal vez con el tiempo un estándar soberano con
La idea principal del índice: en 2020, solo TLS 1.2 y superior con el conjunto correspondiente de conjuntos de cifrado y curvas elípticas se pueden considerar "HTTPS real". Es hora de que las antiguas suites de cifrado, incluso si no tienen vulnerabilidades conocidas, se vayan al basurero de la historia. Los argumentos sobre la necesidad de admitir clientes heredados están a favor de los pobres: Windows XP sigue siendo popular, pero sus usuarios no recorren Internet hoy a través de Internet Explorer 8 con su Schannel prehistórico, sino que usan navegadores basados en Chromium / Firefox que usan NSS para este propósito. ... Lo mismo se aplica a los usuarios de versiones anteriores de Android: o instalaron un navegador alternativo que no depende de la biblioteca de cifrado del sistema o no pueden usar la mayoría de los sitios modernos incluso a través de HTTP (sin soporte para CSS3 y otros acuerdos modernos de denuncia de irregularidades).
Desde estas posiciones se propone criticar el proyecto de metodología. ¿Lo has tenido todo en cuenta? ¿Apretó demasiado las tuercas? ¿No distorsionaste nada? A continuación se muestra una lista de criterios y el enlace es un texto más detallado, con notas y comentarios .
1. Criterios mínimos
1.1. La comunicación HTTP cifrada (HTTPS) se admite mediante el protocolo TLS criptográfico. Se establece una conexión HTTPS con el identificador de protocolo (esquema URI) https sobre el puerto TCP 443.
1.2. El cifrado de la conexión está validado por un certificado de sitio TLS versión 3 X.509 válido, no autofirmado y no vacío emitido por una autoridad de certificación (CA) autorizada.
2. Criterios adicionales
2.1. El servidor no es susceptible a vulnerabilidades conocidas en la implementación del soporte de conexión segura (BEAST, POODLE, GOLDENDOODLE, etc.)
2.2. La compresión TLS no es compatible.
2.3. Solo se admite la renegociación segura iniciada por el servidor; no se admite la renegociación iniciada por el cliente.
3. Criterios recomendados
3.1. La conexión HTTP cambia automáticamente (forzada) a HTTPS.
3.2. La clave pública de los certificados TLS del sitio tiene una longitud de ≥2048 bits. El certificado está firmado digitalmente utilizando el algoritmo ≥SHA256 con encriptación RSA o ECDSA.
3.3. Se admite la versión 1.2 del protocolo TLS.
3.4. SSL y TLS versión ≤1.1 no son compatibles.
3.5. Se admiten conjuntos de cifrado estándar basados en algoritmos sólidos.
3.6. No se admiten conjuntos de cifrado débiles, inadecuados y vulnerables.
3.7. Se admiten curvas elípticas ECDLP / ECC-safe.
3.8. Se establece el orden de coordinación de los conjuntos de cifrado
3.9. Se utilizan los parámetros robustos de los algoritmos de acuerdo de claves Diffie-Hellman (DH).
3.10. Se admiten extensiones importantes de TLS.
3.11. Se admite la indicación de nombre de servidor (SNI).
4. Criterios ampliados
4.1. Se ha publicado una cadena de certificados TLS completa y no redundante con su secuencia de cadena correcta.
4.2. El certificado TLS del sitio es compatible con la transparencia de certificados.
4.3. El certificado TLS del sitio es compatible con la Lista de revocación de certificados (CRL) y el Protocolo de estado de certificados en línea (OCSP).
4.4. Los certificados TLS en cadenas alternativas cumplen con los Criterios 1.2, 4.1.
4.5. Las curvas elípticas no seguras ECDLP / ECC no son compatibles.
4.6. Se establece el orden de coincidencia de las curvas elípticas.
4.7. Los encabezados de respuesta HTTP contienen el encabezado HTTP Strict Transport Security con la directiva includeSubDomains.
5. Criterios de bonificación
5.1. El certificado TLS del sitio es compatible con el grapado OCSP.
5.2. El certificado del sitio TLS se emite mediante un procedimiento de Verificación de la organización (OV) o Validación extendida (EV).
5.3. Se admite la versión 1.3 del protocolo TLS.
5.4. Se establece el orden de concordancia de los conjuntos de cifrado estables de más resistente a menos estable (por parámetros comparables).
5.5. Los registros de recursos DNS para el nombre de dominio del sitio incluyen un registro CAA (Autorización de autoridad de certificación).
5.6. Los registros de recursos DNS para el nombre de dominio del sitio incluyen registros DS y TLSA (se admiten DNSSEC y DANE).
5.7. Se admite la indicación de nombre de servidor cifrado (ESNI).
5.8. Los encabezados de respuesta del servidor (encabezados de respuesta HTTP) contienen un encabezado de política de seguridad de contenido con la directiva de solicitudes de actualización inseguras.