Mas então surgem questões menos ambíguas, por exemplo: o suporte para TLS_RSA_EXPORT_WITH_RC4_40_MD5 é um "chapéu" completo ou apenas uma desvantagem? E se esse pacote de cifras dos
Como resultado, nasceu uma metodologia para compilar um índice, que permite avaliar formalmente o grau de confiabilidade de uma conexão HTTPS em 31 pontos, divididos em 5 grupos, desde "não é HTTPS de jeito nenhum" até "continue assim!"
O que o índice definitivamente não é, é a "resposta russa" ao NIST / HIPAA / PCI DSS etc. por duas razões.
Primeiro, o índice considera apenas a confiabilidade da conexão HTTPS. Desempenho do servidor Web (NPN / ALPN / retomada da sessão), etc. Não considera índice de matéria, não por isso foi inventado.
A segunda é que o NIST.SP.800 e outros padrões da indústria são guiados pelas curvas elípticas do NIST, nas quais há pouco mais do que nenhuma confiança, mas há dúvidas do ponto de vista do ECDLP / ECC (uma observação alegre sobre um chapéu de alumínio pode ser deixada nos comentários, sem exceção ).
Embora, quem sabe, talvez com o tempo um padrão soberano com
A ideia principal do índice: em 2020, apenas o TLS 1.2 e superior com o conjunto correspondente de suítes de criptografia e curvas elípticas podem ser considerados "HTTPS real". É hora de pacotes de criptografia antigos, mesmo que não tenham vulnerabilidades conhecidas, para a lata de lixo da história. Os argumentos sobre a necessidade de oferecer suporte a clientes legados são a favor dos pobres: o Windows XP ainda é popular, mas seus usuários não navegam pela Internet hoje através do Internet Explorer 8 com seu Schannel pré-histórico, mas usam navegadores baseados em Chromium / Firefox usando NSS para essa finalidade ... O mesmo se aplica a usuários de versões mais antigas do Android - eles instalaram um navegador alternativo que não depende da biblioteca de criptografia do sistema ou não podem usar a maioria dos sites modernos, mesmo via HTTP (sem suporte CSS3 e outros acordos de denúncia modernos).
A partir dessas posições, propõe-se criticar o projeto de metodologia. Você levou tudo em consideração? Você apertou as porcas com muita força? Você não interpretou mal nada? Abaixo está uma lista de critérios, e o link é um texto mais detalhado, com notas e comentários .
1. Critérios mínimos
1.1. A comunicação HTTP criptografada (HTTPS) é suportada usando o protocolo criptográfico TLS. Uma conexão HTTPS é estabelecida com o identificador de protocolo (esquema URI) https na porta TCP 443.
1.2. A criptografia da conexão é validada por um certificado de site TLS X.509 versão 3 válido, não autoassinado e não vazio, emitido por uma autoridade de certificação (CA) autorizada.
2. Critérios adicionais
2.1. O servidor não é suscetível a vulnerabilidades conhecidas na implementação de suporte de conexão segura (BEAST, POODLE, GOLDENDOODLE, etc.)
2.2. A compactação TLS não é compatível.
2.3. Apenas a renegociação segura iniciada pelo servidor é suportada; a renegociação iniciada pelo cliente não é suportada.
3. Critérios recomendados
3.1. A conexão HTTP é automaticamente (forçada) a mudar para HTTPS.
3.2. A chave pública dos certificados TLS do site tem ≥2048 bits de comprimento. O certificado é assinado digitalmente usando o algoritmo ≥SHA256 com criptografia RSA ou ECDSA.
3.3. O protocolo TLS versão 1.2 é compatível.
3.4. SSL e TLS versão ≤1.1 não são suportados.
3,5. Suporta pacotes de criptografia padrão baseados em algoritmos robustos.
3,6. Pacotes de criptografia fracos, inadequados e vulneráveis não são suportados.
3,7. Curvas elípticas ECDLP / ECC-safe são suportadas.
3,8. A ordem de coordenação dos conjuntos de criptografia é definida.
3,9. Os parâmetros robustos dos algoritmos de acordo de chave Diffie-Hellman (DH) são usados.
3,10. Extensões TLS importantes são suportadas.
3,11. A indicação do nome do servidor (SNI) é suportada.
4. Critérios estendidos
4.1. Uma cadeia de certificados TLS completa e não redundante foi publicada com sua sequência de cadeia correta.
4.2. O certificado TLS do site é compatível com Transparência de certificado.
4.3. O certificado TLS do site oferece suporte à Lista de Revogação de Certificado (CRL) e ao Protocolo de Status de Certificado Online (OCSP).
4,4. Os certificados TLS em cadeias alternativas estão em conformidade com os critérios 1.2, 4.1.
4.5. As curvas elípticas ECDLP / ECC não seguras não são suportadas.
4,6. A ordem de correspondência das curvas elípticas é definida.
4.7. Os cabeçalhos de resposta do servidor contêm o cabeçalho HTTP Strict Transport Security com a diretiva includeSubDomains.
5. Critérios de bônus
5.1. O certificado TLS do site oferece suporte para grampeamento OCSP.
5,2 O certificado de site TLS é emitido usando um procedimento de verificação da organização (OV) ou validação estendida (EV).
5.3. O protocolo TLS versão 1.3 é compatível.
5,4 A ordem de coordenação dos conjuntos de cifras estáveis do mais resistente ao menos estável (por parâmetros comparáveis) é definida.
5.5. Os registros de recursos DNS para o nome de domínio do site incluem um registro CAA (Autorização de Autoridade de Certificação).
5,6. Os registros de recursos DNS para o nome de domínio do site incluem registros DS e TLSA (DNSSEC e DANE são suportados).
5.7. Há suporte para ESNI (Encrypted Server Name Indication).
5,8. Os cabeçalhos de resposta do servidor (cabeçalhos de resposta HTTP) contêm um cabeçalho Content-Security-Policy com a diretiva upgrade-insecure-requests.