No final, o tweet de Jeff Johnson indicou claramente a causa raiz. Acontece que o serviço OCSP Responder da Apple estava muito sobrecarregado, então o macOS não pôde verificar os certificados criptográficos dos desenvolvedores de aplicativos.
Mas por que o OCSP Responder está no caminho crítico para lançar aplicativos? Neste artigo, discutiremos brevemente a assinatura de código, como funciona o Protocolo de status de certificado online (OCSP), por que ele é completamente errado e algumas das melhores alternativas. Ao contrário de outras notas sobre este incidente, quero discutir os aspectos criptográficos práticos (em um alto nível) e oferecer uma perspectiva equilibrada.
Assinatura de código
No portal do desenvolvedor, a Apple explica a finalidade da assinatura de código:
Assinar o código do seu aplicativo garante aos usuários que ele vem de uma fonte conhecida e não foi alterado desde a última assinatura. Um aplicativo deve ser assinado com um certificado emitido pela Apple antes de ser integrado, instalado em um dispositivo ou inserido no catálogo de aplicativos.
Em outras palavras, para que um aplicativo seja confiável no macOS, ele precisa ser assinado com seu próprio certificado baseado em par de chaves. Um keychain é usado para criar um certificado exclusivo de "ID do desenvolvedor" que inclui uma chave privada para uso pelo desenvolvedor e uma chave pública para distribuição. Quando a Apple assina um certificado de ID de desenvolvedor, o desenvolvedor pode usar a chave privada para criar assinaturas criptográficas em seus aplicativos a cada lançamento.
Quando o aplicativo é iniciado, sua assinatura é verificada em relação à chave pública do certificado do desenvolvedor. O próprio certificado é então verificado para garantir que não tenha expirado (os certificados geralmente são válidos por um ano) e que, em última análise, foi assinado pelo certificado raiz da Apple. Também pode haver certificados intermediários como parte da cadeia até o certificado raiz. Esta é uma "cadeia de confiança" porque o certificado de ID do desenvolvedor foi assinado pelo aplicativo, o certificado intermediário assinou o certificado de ID do desenvolvedor e o certificado raiz da Apple assinou o certificado intermediário. Qualquer dispositivo Apple pode verificar essa cadeia de confiança e, portanto, aprovar o lançamento do aplicativo.
Isso é semelhante à infraestrutura de chave pública TLS da Internet. Mas também fundamentalmente diferente, já que a Apple tem controle total sobre sua própria cadeia de confiança. Outras CAs não têm permissão para emitir certificados de assinatura de código válidos porque todos os certificados devem estar vinculados à Apple.
Se a verificação falhar, o usuário verá uma janela terrível:
Comentários
O que acontece se um desenvolvedor violar as políticas da Apple ou perder sua chave privada? A autoridade de certificação deve revogar instantaneamente os certificados emitidos. Se um certificado for usado de forma maliciosa, é inaceitável esperar dias ou meses para que ele expire naturalmente, caso contrário, um vazamento da chave privada tornaria todo o sistema inútil.
É nesta situação que o certificado é revogado. Esta é uma etapa adicional no processo de verificação de assinatura, que envolve perguntar à autoridade de certificação se o certificado ainda é válido.
Na Internet, isso é feito da maneira mais simples. A CA fornece uma Lista de Revogação de Certificados (CRL) com os números de série de todos os certificados revogados e você verifica se o certificado não está na lista. No entanto, os navegadores pararam de usar essa abordagem à medida que a lista ficava cada vez mais longa. Especialmente depois que exploits terríveis como o Heartbleed exigiram revogações massivas de certificados.
O protocolo OCSP (Online Certificate Status Protocol) é uma alternativa que permite validar certificados em tempo real. Cada certificado contém um Respondente OCSP integrado, que é o URL que você solicita e que informa se o certificado foi revogado. No caso da Apple, é
ocsp.apple.com... Portanto, agora, além de verificar a validade criptográfica da assinatura, cada vez que você inicia o aplicativo, você realiza uma verificação em tempo real no site da Apple (com algum cache) que eles ainda consideram o certificado do desenvolvedor legítimo.
Problema de disponibilidade de OCSP
O grande problema do OCSP é que o serviço externo se torna um ponto único de falha. O que acontece se o respondente do OCSP estiver inativo ou indisponível? Estamos apenas nos recusando a verificar o certificado (falha forçada)? Ou fingimos que a verificação foi bem-sucedida (falha suave)?
A Apple é forçada a usar o comportamento de falha suave, caso contrário, os aplicativos não funcionarão offline. Todos os principais navegadores também implementam o comportamento de falha suave, pois os respondentes OCSP tradicionalmente não são confiáveis e o navegador deseja carregar o site mesmo se o respondente CA estiver temporariamente fora do ar.
Mas a falha suave não é uma boa opção, porque com o controle da rede, um invasor pode bloquear solicitações ao respondente e a verificação será ignorada. Na verdade, essa "correção" do erro circulou amplamente no Twitter durante esse incidente: o tráfego para ele foi
ocsp.apple.combloqueado por uma linha no arquivo / etc / hosts. Muitos deixarão esta linha por um tempo, pois a desativação do OCSP não causa problemas perceptíveis.
Incidente
Se a validação OCSP da Apple se baseia em falha suave, por que os aplicativos travariam quando o respondente OCSP fosse desabilitado? Provavelmente porque era na verdade uma falha diferente: o respondente do OCSP não estava completamente desativado. Simplesmente não funcionou bem.
Devido à carga de milhões de usuários em todo o mundo que estavam atualizando para o macOS Big Sur, os servidores da Apple ficaram lentos e não responderam adequadamente às solicitações do OCSP. Mas, ao mesmo tempo, funcionaram bem o suficiente para que o soft-fail não funcionasse.
Problema de privacidade OCSP
Além do problema de disponibilidade do OCSP, o protocolo não foi projetado para proteger a privacidade em primeiro lugar. A solicitação OCSP básica inclui uma solicitação HTTP não criptografada para o respondente OCSP com o número de série do certificado. Dessa forma, não apenas o respondente pode determinar em qual certificado você está interessado, mas também o seu ISP e qualquer outra pessoa que esteja interceptando os pacotes. A Apple pode listar, em ordem, quais aplicativos de desenvolvedor você abre, e terceiros podem fazer o mesmo.
A criptografia poderia ter sido adicionada, e há uma versão melhor e mais privada chamada grampeamento OCSP , mas a Apple também não fez isso. O grampeamento OCSP realmente não faz sentido neste cenário, mas essa tecnologia ilustra que o OCSP não deve vazar dados por padrão.
Futuro melhor
O incidente gerou uma discussão animada na comunidade, com um lado afirmando: "Seu computador não é realmente seu" e o outro argumentando: "Estabelecer confiança nos aplicativos é difícil, mas a Apple o faz bem . " Estou tentando mostrar que o OCSP é uma maneira terrível de gerenciar revogações de certificados e, no futuro, levará a mais incidentes relacionados à disponibilidade e privacidade do respondente. Na minha opinião, esta é uma má decisão de engenharia - definir a dependência do inicializador de aplicativos no OCSP. Pelo menos no curto prazo, eles reduziram os danos aumentando os tempos de cache de resposta .
Felizmente, o melhor método para revogar certificados, CRLite, está quase maduro. Ele permite que você reduza todas as listas de revogação de certificados para um tamanho razoável. No blog de Scott Helme fornece um bom resumo de como o CRLite usa filtros Bloom para retornar a abordagem antiga com uma lista de certificados revogados, que funcionava até OCSP.
Dispositivos MacOS podem receber periodicamente atualizações para esta CRL e realizar verificações localmente no dispositivo, abordando a disponibilidade de OCSP e questões de privacidade. Por outro lado, como a lista de revogação de ID de desenvolvedor é muito menor do que a lista de todos os certificados revogados de PKI, vale a pena perguntar por que a Apple não usa CRLs. Eles podem não querer divulgar quais certificados foram revogados.
Conclusão
No geral, esse incidente foi um bom motivo para refletir sobre o modelo de confiança promovido por organizações como a Apple e a Microsoft. O malware se tornou mais sofisticado e a maioria das pessoas não consegue determinar se é seguro executar determinados binários. A assinatura de código parece ser uma ótima maneira criptográfica de estabelecer confiança para aplicativos e, pelo menos, vincular aplicativos a desenvolvedores conhecidos. E revogar certificados é uma parte necessária dessa confiança.
Mas apenas algumas falhas no processo de verificação OCSP estragam a elegância criptográfica da assinatura do código e do processo de verificação. OCSP também é amplamente usado para certificados TLS na Internet, mas as falhas lá são menos catastróficas devido ao grande número de CAs e à ignorância generalizada de falhas dos navegadores. Além disso, as pessoas estão acostumadas a ver sites indisponíveis de vez em quando, mas não esperam o mesmo de aplicativos em seus próprios computadores. Os usuários do MacOS temiam que seus próprios aplicativos fossem afetados pelos problemas de infraestrutura da Apple. No entanto, este é um resultado inevitável, decorrente do fato de que a validação de certificados depende de infraestrutura externa, e nenhuma infraestrutura é 100% confiável.
Scott Helme também expressa preocupação sobre o poder que as CAs obtêm se a revogação de certificados realmente funcionar. Mesmo que você não esteja preocupado com o potencial de censura, às vezes podem ocorrer erros e devem ser avaliados em relação aos benefícios de segurança. Como um desenvolvedor descobriu quando a Apple revogou por engano seu certificado , o risco de rodar em uma plataforma isolada é que você pode ficar isolado dela.