A partir da iminente versão 90, o Chrome mostrará um erro de certificado quando um usuário tentar acessar qualquer site com um certificado assinado por Camerfirma. Embora possa não ser o AC mais popular, está muito presente na Espanha em muitos organismos públicos , por exemplo, na Agência Tributária. Se esta “exclusão” do Chrome não for resolvida, para a campanha de locação pode haver problemas de acesso aos sites oficiais.

Muitas outras organizações na Espanha (incluindo o site da campanha de vacinação COVID , vacunacovid.gob.es) dependem do certificado. Mas o que houve? Por que exatamente o Chrome para de confiar nesta CA? A Microsoft e a Mozilla ainda confiam, mas é claro que a decisão do Chrome criará um efeito cascata que provavelmente tornará impossível confiar em qualquer coisa emitida por esta CA a partir dos principais sistemas operacionais ou navegadores.

Noutra notícia sobre o assunto, fala-se dos erros cometidos por Camerfirma e da sua incapacidade de os responder e resolver mas, para ser justo, é preciso conhecer um pouco do mundo dos certificados. A primeira coisa é deixar claro que todos os CAs cometem erros: muitos, sempre. Você só precisa fazer compras no Bugzilla. O mundo da criptografia é extremamente complexo, e o mundo dos certificados… também.

Seguir os requisitos nem sempre é fácil e, por isso, a organização do CA/Fórum e muitos pesquisadores estão encarregados de garantir o perfeito funcionamento das autoridades certificadoras e o cumprimento estrito e rigoroso desses padrões, pelo que costumam estar muito habituados a essas falhas, erros e omissões e toleram os problemas de certa forma, desde que sejam revogados a tempo e corrigidos. É uma questão de mostrar vontade e eficiência na gestão, ao invés de ser perfeito .

Os incidentes ocorrem diariamente e são variados e complexos, mas normalmente os CAs reagem resolvendo-os e aumentando a vigilância, o que melhora o sistema a cada dia. Mas às vezes, a confiança em um CA é perdida porque um certo limite relacionado a suas respostas e reações é ultrapassado. No caso da Camerfirma, parece que a chave é que eles têm cometido erros há anos, alguns repetidamente, e que já mostraram muitas vezes que os remédios e as práticas decisivas dessa autoridade de confiança não são confiáveis. Especialmente, suas desculpas e explicações não parecem se adequar a eles.

A reação do Chrome mostra, portanto, que a segurança criptográfica deve ser levada a sério e que não aceitará CAs que confessem não ter o pessoal necessário, que ignoram as especificações, etc. Esses movimentos são necessários. Claro, com decisões como essa, o Chrome está se tornando uma CA de fato. Já discutimos que as CAs tradicionais estão perdendo o controle dos certificados. Este pode ser um dos possíveis motivos pelos quais o Chrome terá um novo armazenamento raiz.

As 26 razões

Vamos descrever as razões muito brevemente e em ordem de importância ou relevância (subjetiva). O texto entre aspas é literal do que encontramos no rastreador do Bugzilla, que parece se gabar da fragilidade das desculpas de Camerfirma . Para ser justo, você deve lê-los em seu contexto completo e concreto para compreendê-los. Mas, mesmo assim, o que se destila por um lado é uma certa incapacidade da Camerfirma para o trabalho que lhe foi confiado de ser um AC sério e capaz de responder em tempo oportuno … e por outro, um cansaço importante por parte daqueles que garantem que isso seja assim.

• Um: em 2017, o mundo parou de depender do WoSign / StartCom como CA por diferentes motivos. A Camerfirma continuou a ter uma relação com a StartCom como forma de validar determinados certificados, e o fez sob o critério de «outros métodos» que é a forma mais estranha (e última) de o conseguir e, portanto, suscita suspeitas. O CA / Fórum não queria que esses “outros métodos” fossem usados ​​(que vieram de uma especificação desatualizada) ou que a validação do certificado pudesse ser delegada à StartCom. A Camerfirma não retificou e continuou o relacionamento com a StartCom sem deixar claro como.
• Dois: eles não respeitaram o padrão CAA. Este registro DNS deve conter quais CAs são preferidos para um site. Por exemplo, não quero que o CA X emita um certificado para mim … ou quero apenas que o CA Y emita certificados para o meu domínio. A Camerfirma achava que, se existisse a certificate transparency , eles já poderiam evitar o respeito aos padrões da CAA, pois “estavam com pressa e não entenderam os requisitos”.
• Três: as respostas OCSP (para revogar rapidamente) não atenderam aos padrões.
• Quatro: os campos de Nomes alternativos de assunto de muitos de seus certificados estavam errados. Quando denunciaram o Camerfirma, não obtiveram resposta, porque esses relatos “foram para uma única pessoa” que não respondeu. Nunca resolveu «intencionalmente» certificados deste tipo e, mesmo depois de revogar alguns, a Camerfirma voltou a emiti-los erroneamente.
• Quinto: o intesa Sanpaolo, um dos sub-CAs do Camerfirma, também cometeu vários erros quando se tratou de revogar a tempo. Até emitiu um certificado para «com.com» por «erro humano».
• Seis: eles cometeram certas revogações por engano, confundindo números de série em certificados válidos e inválidos. Na Camerfirma decidiram fazer uma «revogação», o que é intolerável no mundo dos certificados, mas a implementaram de forma inconsistente. Em meio a todos os problemas, eles alegaram que usariam o software de gerenciamento EJBCA para mitigar isso no futuro, mas aí … então confirmaram que desenvolveram software próprio com características semelhantes. Como não se sabia muito mais sobre isso posteriormente, eles alegaram que estavam em «reuniões diárias para discutir esses assuntos».
• Sete: Camerfirma violou uma regra relacionada à inclusão do nome e número de série do emissor no campo de ID da chave (não vencido). Todos os certificados da Camerfirma estavam errados desde 2003. Eles alegaram que não o entenderam e corrigiram no final de 2019. Mas eles não revogaram os anteriores emitidos. Em 2020, eles reemitiram certificados que violavam essa política, que também não revogaram.
• Oito, nove e dez: eles não devem emitir certificados com sublinhados em seus nomes. De acordo com um «erro humano» em sua emissão e detecção, eles não foram capazes de detectá-los a tempo e alguns foram perdidos. Também aconteceu com um nome de domínio com o caractere «:». E com um domínio que existia, mas estava incorreto no certificado.
• Onze: Camerfirma (e outros) emitiram sub-CAs que poderiam dar respostas OCSP para o próprio Camerfirma, porque não incluíram uma restrição adequada nos EKUs do certificado (EKUs são campos para limitar o poder e o uso do certificado). Eles argumentaram que não estavam cientes dessa violação de segurança e não os revogaram a tempo. A razão para não revogar é que uma das sub-CAs foi usada no campo da saúde dos smartcards e se eles deveriam ser substituídos, anulando os cartões inteligentes.O problema era tão importante que eles tiveram que levá-lo a órgãos superiores em nível nacional. Em 2 de outubro de 2020, parece que as chaves nesses cartões foram destruídas, mas essa destruição não foi supervisionada ou testemunhada por um auditor qualificado ou pela própria Camerfirma.
• Doze: emitiu um subCA para uso em S / MIME para o governo de Andorra, que não foi auditado. Quando o fizeram, descobriram que estavam cometendo alguns erros. No final, eles tiveram que revogá-lo e alegaram que, como eram certificados pelo TLS, pensavam que não estavam dentro do escopo das auditorias. Mais uma vez, o problema parecia ser que eles não tinham pessoal suficiente e necessário.
• De treze a vinte e seis: trapaceamos aqui para reunir o resto das razões que são muito semelhantes. Por exemplo, dezenas de bugs técnicos em outros campos de certificado que eles não puderam revogar a tempo. E para isso as desculpas eram variadas. Já que a legislação local os obrigava a certas fórmulas que não atendiam aos padrões (coisas que eles não demonstravam)… até que seu sistema funcionou bem por 17 anos, mas depois, à medida que cresceu muito, alguns controles internos falharam. Às vezes não havia desculpas. Eles simplesmente não responderam aos pedidos. Em um dos incidentes, eles deveriam divulgar a existência de um sub-CA no máximo uma semana após sua criação, mas não o fizeram. O que estava acontecendo, segundo eles, é que “o responsável não estava disponível”. Nem o endosso dessa pessoa. Camerfirma tentou resolver dizendo que colocaria «um backup para o responsável por essa comunicação». Para resolver outros problemas, alegaram que seus funcionários estavam completamente «sobrecarregados» ou «de férias». Basicamente, de todas as falhas comuns em muitos certificados (entropia insuficiente, extensões incorretas …), Camerfirma sempre não conseguiu revogar os certificados em tempo hábil.

Conclusões

Não é fácil ser um CA. Camerfirma não é a primeira nem a última revogada. Até mesmo a Symantec sofreu um revés nesse sentido. O FMNT também teve um momento muito ruim para o Firefox incluir seu certificado em seu repositório e levou uma jornada de vários anos. Em alguns momentos dessa incrível história com o FMNT, também ocorrem paradas, em que se percebe que falta pessoal adequado para atender às demandas da Mozilla.

E é isso que o mundo dos certificados é exigente. Mas é assim que deve ser. O bom trabalho do AC depende, literalmente, da internet que foi construída. Tolerar o funcionamento de um CA que deixa um milímetro de vigilância, controle e demanda contínuos ou não responde em tempo hábil, é como permitir condescendência diante de um policial ou juiz que comete qualquer indício de corrupção. Não deve ser tolerado para nosso próprio bem e pelas consequências significativas que isso acarretaria.