O cataclismo de lançamento do Big Sur, com instalações suspensas, lentidão do sistema e aplicativos não abrindo rapidamente, deu lugar à investigação do que estava acontecendo e esta investigação levou a conclusões um tanto precipitadas que não condizem com a realidade. direção e outra.
Vamos tentar explicar o que aconteceu
Com o lançamento do macOS Big Sur na quinta-feira, os usuários de Mac começaram a ter problemas ao tentar abrir aplicativos enquanto estavam conectados à Internet. O sistema de pagamento do estado na Apple atribuiu a situação a problemas com o sistema de reconhecimento de identidade do desenvolvedor, e o desenvolvedor Jeff Johnson determinou que esses eram problemas com o servidor OCSP da Apple.
O que é OCSP
https://twitter.com/lapcatsoftware/status/1326990296412991489?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1326990296412991489%7Ctwgr%5E%2Fiderf_url? e-perché-apple-non-lascia-che-accada-di nuovo?
Lembre-se que, desde Mojave, a Apple exige que um aplicativo seja instalado, deve ser assinado e registrado na Apple, para que sua autenticidade possa ser verificada. A parte do macOS que lida com isso é chamada de Gatekeeper e você pode encontrá-la nas Preferências do Sistema.
O Gatekeeper realiza verificações online para ver se um aplicativo contém malware conhecido e se o certificado de desenvolvedor é válido.
A sigla “OCSP” refere-se ao grampeamento do protocolo de status do certificado online ou, mais resumidamente, ao “grampeamento do certificado”. A Apple usa esse certificado “grampo” para ajudar a simplificar o processo de ter milhões de dispositivos Apple verificando a validade de milhões e milhões de certificados todos os dias.
Como o nome sugere, ele é usado para verificar a validade de um certificado sem a necessidade de baixar e verificar longas listas de revogação de certificados. O macOS usa OCSP para garantir que o certificado de desenvolvedor não tenha sido cancelado antes de o aplicativo ser aberto. (por exemplo, é isso que é feito se alguém tentar abrir o Fortnite).
O Serviço de Notarização da Apple é um sistema automatizado que verifica o software em busca de conteúdo malicioso, verifica a assinatura do código e retorna rapidamente o resultado. Se não houver problemas, o serviço de notarização gera um ticket para anexar ao software e também o publica online para que o Gatekeeper possa encontrá-lo.
O que acontece se o aplicativo não se conectar ao servidor OCSP?
Se um dispositivo Apple não conseguir se conectar à rede, mas você deseja abrir um aplicativo, a validação do certificado deve "ter um erro de software" (ou seja, é cancelado sem notificar o usuário) para que quando detecte que não consigo conectar na Internet, abrimos o aplicativo mesmo assim.
Esse processo de conexão com os servidores da Apple para autenticação aparece no Console como trustd - o nome do processo no macOS responsável por verificar com os servidores da Apple se um aplicativo está "autenticado" e sua missão é conectar-se a um domínio chamado ocsp.apple. com.
Então o que aconteceu?
O problema surge porque o servidor nunca "parou". Ele continuou a receber solicitações, mas foi tão lento em processá-los que eles acabaram "tempo limite", o que significa que foram cancelados depois de um tempo, devido à falta de resposta.
Como o servidor não travou, mas continuou a receber solicitações (o sistema sabia que o servidor ainda estava ativo porque obteve o DNS correto ao realizar uma pesquisa), a "falha suave" não ocorreu, mas estava aguardando um resposta, o que fazia com que os aplicativos não abrissem e/ou todo o sistema estivesse lento (portanto, desconectar-se da internet resolveu o problema).
Mas questões técnicas à parte, trata-se de privacidade e envio de informações pessoais para a Apple.
Isso parece ter sido uma má interpretação - ou ignorância - do que realmente estava acontecendo com o reconhecimento de firma. Na realidade, o macOS envia informações opacas sobre o certificado de desenvolvedor dos aplicativos que você deseja abrir, mas não o nome do aplicativo (um desenvolvedor usa o mesmo certificado em todos os aplicativos) ou a ID do dispositivo. fonte
A Apple também respondeu especificamente a este caso atualizando sua nota "Abra aplicativos com segurança no seu Mac" (a nota em espanhol ainda não foi atualizada)
O macOS foi projetado para proteger os usuários e seus dados, respeitando sua privacidade.
O Gatekeeper realiza verificações online para ver se um aplicativo contém malware conhecido e se o certificado de desenvolvedor foi cancelado. Nunca combinamos dados desses controles com informações sobre usuários da Apple ou seus dispositivos. Não usamos os dados desses controles para descobrir o que cada usuário está abrindo ou usando em seu dispositivo.
As verificações do cartório são apenas para saber que o aplicativo não contém malware e é realizado por meio de uma conexão criptografada preparada para superar uma falha no servidor.
Essas verificações de segurança nunca incluíram o ID Apple do usuário ou a identidade de seu dispositivo. Para proteger ainda mais a privacidade, paramos de incluir o endereço IP associado às verificações de certificado de ID do desenvolvedor e garantiremos que todos os endereços IP sejam removidos dos logs. As verificações de segurança nunca incluíram o ID Apple do usuário ou a identidade de seu dispositivo. Para proteger ainda mais a privacidade, paramos de registrar os endereços IP associados às verificações de certificados do Developer ID e garantiremos que todos os endereços IP coletados sejam removidos dos logs.
Por que transportar esse tráfego usando solicitações não criptografadas?
É comum o OCSP usar HTTP, para evitar loops. Se HTTPS for usado para verificar um certificado com OCSP, o certificado da conexão HTTPS também deverá ser verificado usando OCSP. Isso envolveria a abertura de outra conexão HTTPS e assim por diante.
Obviamente, embora o OCSP não exija criptografia, as respostas devem ser assinadas pelo servidor.
Problemas para a Apple
Embora haja uma explicação técnica de como esse mecanismo funciona em HTTP não criptografado, e o respeito da Apple pela privacidade tenha sido bastante claro, ainda há duas grandes sombras pairando sobre esse problema.
O primeiro é, claro, o problema da imagem, que mais uma vez traz sombras de épocas passadas quando a Apple parecia incapaz de antecipar a demanda por seus produtos e o ônus que isso acarretaria.
Que a empresa mais preciosa do mundo tenha um obstáculo desse tamanho no dia do lançamento de sua nova versão do sistema operacional, que é tão importante que deixou de ser macOS X e está começando a se chamar macOS 11, é algo realmente inédito.
Claro, a Apple não está sozinha em calcular mal os recursos ou ter implementações desastrosas de software, mas é o que atrai mais atenção, e um rubor é óbvio demais para fechar os olhos.
Backups não criptografados
De acordo com o artigo que levantou o debate, a Apple deixou uma porta aberta no desligamento de ponta a ponta do iMessage (Mensagens). Atualmente, o iOS solicita que você insira seu ID Apple durante a configuração e ativa automaticamente o backup do iCloud e o Backup do iCloud.
O Backup do iCloud não é criptografado de ponta a ponta - ele criptografa o backup do dispositivo com teclas da Apple. Qualquer dispositivo com o iCloud Backup ativado (é ativado por padrão) faz backup do histórico do iMessage nos servidores da Apple, juntamente com as chaves secretas do dispositivo para o iMessage, assim que se conecta à energia para carregar.
A Apple pode descriptografar e ler essas informações sem sequer tocar no dispositivo. Mesmo que você tenha o iCloud e/ou iCloud Backup desativado: aqueles com quem você está enviando mensagens de texto provavelmente não o desligaram e sua conversa é carregada para a Apple (e, via PRISM, disponível gratuitamente para a comunidade de inteligência americana, FBI e outros amigos, sem ter que pedir um mandado ou ter uma causa provável).
Isso certamente merece alguma explicação da empresa que coloca a privacidade do usuário em primeiro lugar. Você não acha?
![Coisas que você não sabe sobre o iOS 15 [atualizado]](/images/posts/0eddbf33fbf8f7bac43d1cee73e01454-0.jpg)
