Cómo el gobierno intentó HTTPS, pero falló

imagen


La legislación exige que los sitios web de las autoridades ejecutivas federales proporcionen cifrado y protección de la información transmitida . ¿Cómo hicieron frente los constructores del "Runet sostenible" a la protección de sus propios sitios y al cumplimiento de los requisitos pertinentes de las leyes?



Avance: este es un material adicional a la sección "Confidencialidad" del informe "Seguridad de la información de los sitios web de los organismos estatales de la Federación de Rusia: resultados anormales" .



Este año, comenzamos a utilizar una nueva metodología para evaluar la implementación del soporte en los sitios web de las agencias gubernamentales del protocolo HTTPS en el marco del proyecto "Monitor de Sitios Estatales" , cada criterio del cual fue formalizado y descrito. Por primera vez lo probamos en el estudio de los sitios de los servicios estatales , y ahora lo hemos aplicado en el estudio anual de los sitios de los organismos estatales de la Federación de Rusia. Los criterios se dividen en cinco grupos:



Mínimo (Grupo D):el incumplimiento de al menos uno de ellos significa que no se puede considerar que el sitio admita una conexión segura. Solo hay dos criterios en este grupo: el servidor web debe responder con un código de estado HTTP de 200 o 301 cuando se accede con el identificador de protocolo HTTPS en el puerto 443, y debe transmitir un certificado TLS válido al cliente.



Si todo resultó ser simple con el cumplimiento del primer criterio - ya sea sí o no, entonces con el segundo, se activó la "lógica ternaria" - sí / no / tal vez. "Quizás" aquí significa que si se accede al sitio mediante un nombre de host, entonces "sí", y si agrega el subdominio www a la dirección, entonces , ¡Ups! Se olvidaron de esta opción al solicitar un certificado.“No” o viceversa. En esto, los sitios web del Ministerio de Defensa (a estas alturas el certificado ya se ha vuelto a emitir antes de lo previsto) y el Servicio Penitenciario Federal se llenaron, y en el sitio web de Rostekhnadzor simplemente había un certificado inválido (de otro anfitrión).



Por lo tanto, el 4% de los sitios estudiados no dominaban las reglas básicas del TRP Básico (Grupo B):HTTPS, y el 22% de los sitios ni siquiera pretendían admitirlo. Al mismo tiempo, el 15% de los sitios estudiados pertenecen a las autoridades ejecutivas federales (FOIV), que están obligadas a soportar HTTPS .



el incumplimiento de al menos uno de ellos significa que el sitio solo admite formalmente una conexión segura, que de hecho puede resultar no segura. Ya existen seis criterios en este grupo, unidos por el lema “2021 está en el patio”: ausencia de vulnerabilidades graves con el identificador CVE en el servidor web, deshabilitación de la compresión TLS, soporte de extensiones TLS estándar de facto, etc. se requiere.



Todos los sitios cumplieron con solo dos criterios: los parámetros del certificado TLS y la compresión TLS deshabilitada. Del diario de observación de gossites: 100% usa un certificado TLS firmado usando el algoritmo RSA, y ninguno usa ECDSA.



El Ministerio de Finanzas, Rosreestr y Rosstandart no han oído hablar de la expansión Fallback SCSV. El Ministerio de Relaciones Exteriores, Rosreestr, Rosalkogolregulirovanie, Rosstandart y el Banco Central no saben que en 2021, la reconciliación solo es segura. El Ministerio de Desarrollo Económico, Rosreestr, Roszdravnadzor, Rosnedra y FSS no saben qué año es; sus sitios están brillando en Internet con vulnerabilidades descubiertas hace casi diez años.



Los sitios del Ministerio de Desarrollo Económico y Roszdravnadzor ofrecen a los visitantes NCSA Mosaic bajo Windows 1.0use el conjunto de cifrado RSA_WITH_RC4_128_MD5 cuando se conecte a través del protocolo TLS versión 1.2. Rosnedra, aparentemente, cree que OpenSSL Padding Oracle es algo sobre la apertura de la información, y no un "agujero" en el servidor web. El FSS y Rosreestr parecen no tener idea de que "2014" en CVE-2014-3566 (POODLE) es el año del descubrimiento y descripción de la vulnerabilidad, y el software debe actualizarse al menos algunas veces (Rosreestr, a juzgar por la web identificador del servidor, se encuentra en el ensamblado de Apache desde 2010).



Casi la mitad (47%) de los administradores de sitios estatales no han oído hablar de la extensión Extended Master Secret, que recibió el estado RFC en el lejano 2015 (para el 53% restante).



En total, otro 52% de los sitios estatales estudiados no pudieron pasar ni siquiera el marco bastante modesto del grupo D.



Recomendado (Grupo B):Se requiere el cumplimiento de cada uno de ellos para considerar satisfactorio el soporte de una conexión segura. Hay siete criterios y tampoco nada extraordinario: soporte solo para HTTPS, TLS 1.2 y superior, conjuntos de cifrado AEAD, parámetros de protocolo DH estables, etc.



Todo hizo frente solo con soporte para TLS 1.2 y curvas elípticas estándar. El 12% no cumplió con los requisitos para los parámetros DH ("secreto proactivo"), el 15% no encontró la fuerza para abandonar el soporte HTTP, el 37% no admite los conjuntos de cifrado AEAD, el 36% no pudo darles prioridad sobre los conjuntos de cifrado débiles , y el 15% tuvo el mismo problema al establecer la prioridad de las curvas elípticas estándar sobre cualquier sect283k1 o sect409r1 (¿a quién sugiere Rosstandart estas curvas para hacer coincidir?)



En esta etapa, otro 15% de los sitios estatales abandonaron la carrera.



Adicional (Grupo A): Cumplir con ellos proporcionará confiabilidad adicional de la conexión segura. Los criterios son en su mayoría simples: la cadena de certificados TLS se transmite correctamente, la transparencia de certificados, CRL / OCSP, HSTS son compatibles y las versiones obsoletas de TLS, conjuntos de cifrado que no son AEAD, curvas elípticas no estándar no son compatibles. Una cuestión de un par de comandos en la consola, y un certificado sin CT u OCSP hoy todavía lo consigues.



Así que nadie recibió un certificado "opaco": las autoridades de certificación conocen su negocio, pero cuando se trata de trabajar con los bolígrafos y corregir las configuraciones de los servidores web ...



El 35% de los sitios estatales no pudieron transferir la cadena correcta de certificados TLS: incluyen un "ancla", no transfieren certificados intermedios, etc. El 69% no domina el encabezado HSTS, no lo transmite en absoluto, lo transmite es incorrecto o está incompleto. El Ministerio de Agricultura debería sentirse especialmente ofendido: si no fuera por esto, su sitio se habría convertido en el único del grupo A. El



18% de los sitios, junto con las curvas elípticas estándar, están listos para ofrecer a sus visitantes exóticos, por ejemplo, brainpoolP512r1 o sect283k1. Estimados desarrolladores de nginx, desactive todas las curvas predeterminadas; de lo contrario, el sector público no puede averiguar en qué se diferencia secp256r1 de brainpoolP256r1 o secp256k1, y en caso de que las deje todas (para aquellos que no están inmersos en el tema, estas son curvas diferentes, que solo tienen un nombre similar).



El 57% de los sitios admiten conjuntos de cifrado que no son AEAD (aunque, como mostramos anteriormente , esto no tiene sentido práctico hoy en día, así como el soporte para versiones TLS inferiores a 1.2, y mucho menos SSL). Sin embargo, aquí debe tenerse en cuenta que consideramos el soporte de solo ciertos conjuntos de cifrado que realmente se utilizan hoy como cumplimiento con el criterio, por lo que el soporte para algunos ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 no cumple con nuestros criterios, ya que es AEAD, pero en realidad nadie lo apoya.



El 47% de los sitios no pueden separarse de TLS 1.0 y 1.1 (y Rosreestr y FSS, con SSL), incluso a pesar de que el IETF finalmente los enterró y los reconoció como obsoletos, y los fabricantes de todos los navegadores populares abandonaron su soporte incluso antes. .



Por desgracia, nadie ha cumplido con los criterios del grupo A, y solo 6 (7%) sitios podrían estar en el grupo B, felicitemos a los ganadores: el Ministerio de Agricultura, el Ministerio del Interior, el Ministerio de Situaciones de Emergencia, Rosarchiv , el Ministerio de Educación y Ciencia y la Agencia Federal de Administración de la Propiedad.



Extendido , se recomienda su cumplimiento para garantizar la máxima confiabilidad y seguridad de una conexión segura, pero puede ser indeseable o inalcanzable en algunos casos.



Ningún sitio admite CAA y solo curvas elípticas seguras. Sin embargo, solo Curve25519 y Curve448 cumplen con el último criterio, ambos son compatibles solo con versiones modernas de navegadores, por lo que este criterio actualmente no se recomienda por razones de accesibilidad del sitio.



El 10% de los sitios admiten DNSSEC, el 6% admite el engrapado OCSP, pero ninguno de ellos requiere engrapar un certificado TLS con una respuesta de CA sobre su estado (OCSP debe engrapar). El 5% admite TLS versión 1.3, pero ninguno es compatible con Encrypted ClientHello (ECH). Y solo los sitios web del Ministerio de Transporte y Rosstat transmiten el encabezado HTTP de la Política de seguridad de contenido con la directiva de solicitudes de actualización inseguras a sus visitantes.



En total, los sitios web del 22% de los organismos gubernamentales de la Federación de Rusia no admiten HTTPS, aunque se requiere que el 15% apoyo, ya que son los sitios de las autoridades ejecutivas federales. Otro 56% pretende ser compatible con HTTPS, pero solo lo hace formalmente. Es decir, menos de una cuarta parte de los sitios a través de los cuales se difunde información sobre las actividades de los organismos estatales, se envían documentos a estos organismos, se transfieren datos personales y otra información sensible a sus visitantes, se proporciona un nivel aceptable de protección de conexión a sus visitantes.



Todavía soy escéptico sobre la posibilidad de que estas personas construyan un análogo del Gran Cortafuegos de China, ¿y tú?



All Articles