No se pueden abrir aplicaciones en macOS. Por qu茅 la firma de c贸digo OCSP era una mina de tiempo

Hace dos semanas, los usuarios de macOS comenzaron a reportar bloqueos extra帽os al abrir aplicaciones que no se descargaron de la Mac App Store. Muchos sospechaban problemas de hardware con sus dispositivos, pero aprendieron de las redes sociales que este es un problema generalizado. Y no es casualidad que surgiera poco despu茅s del lanzamiento de macOS Big Sur.



Al final, el tuit de Jeff Johnson indic贸 claramente la causa ra铆z. Result贸 que el servicio OCSP Responder de Apple estaba demasiado sobrecargado, por lo que macOS no pudo verificar los certificados criptogr谩ficos de los desarrolladores de la aplicaci贸n.





Pero, 驴por qu茅 OCSP Responder se encuentra en la ruta cr铆tica para iniciar aplicaciones? En este art铆culo, analizaremos brevemente la firma de c贸digo, c贸mo funciona el Protocolo de estado de certificado en l铆nea (OCSP), por qu茅 es completamente incorrecto y algunas de las mejores alternativas. A diferencia de otras notas sobre este incidente, quiero discutir los aspectos criptogr谩ficos pr谩cticos (a un alto nivel) y ofrecer una perspectiva equilibrada.



Firma de c贸digo



En el portal de desarrolladores, Apple explica el prop贸sito de la firma de c贸digo:



Firmar el c贸digo de su aplicaci贸n garantiza a los usuarios que proviene de una fuente conocida y que no se ha modificado desde la 煤ltima vez que se firm贸. Una aplicaci贸n debe estar firmada con un certificado emitido por Apple antes de que se pueda integrar, instalar en un dispositivo o ingresar al cat谩logo de aplicaciones.


En otras palabras, para que una aplicaci贸n sea confiable en macOS, debe estar firmada con su propio certificado basado en pares de claves. Se utiliza un llavero para crear un certificado de "ID de desarrollador" 煤nico que incluye una clave privada para que la utilice el desarrollador y una clave p煤blica para la distribuci贸n. Cuando Apple ha firmado un certificado de ID de desarrollador, el desarrollador puede usar la clave privada para crear firmas criptogr谩ficas en sus aplicaciones con cada lanzamiento.



Cuando se inicia la aplicaci贸n, su firma se verifica con la clave p煤blica del certificado del desarrollador. A continuaci贸n, se verifica el certificado en s铆 para asegurarse de que no haya caducado (los certificados suelen tener una validez de un a帽o) y que, en 煤ltima instancia, est茅 firmado por el certificado ra铆z de Apple. Tambi茅n puede haber certificados intermedios como parte de la cadena hasta el certificado ra铆z. Esta es una "cadena de confianza" porque el certificado de ID de desarrollador fue firmado por la aplicaci贸n, el certificado intermedio firm贸 el certificado de ID de desarrollador y el certificado ra铆z de Apple firm贸 el certificado intermedio. Cualquier dispositivo de Apple puede comprobar esta cadena de confianza y por tanto aprobar el lanzamiento de la aplicaci贸n.



Esto es similar a la infraestructura de clave p煤blica TLS de Internet. Pero tambi茅n fundamentalmente diferente, ya que Apple tiene un control total sobre su propia cadena de confianza. Otras CA no pueden emitir certificados de firma de c贸digo v谩lidos porque todos los certificados deben estar vinculados a Apple.



Si la verificaci贸n falla, el usuario ver谩 una ventana terrible:







Retroalimentaci贸n



驴Qu茅 sucede si un desarrollador viola las pol铆ticas de Apple o pierde su clave privada? La autoridad de certificaci贸n debe revocar instant谩neamente los certificados emitidos. Si un certificado se utiliza de forma maliciosa, es inaceptable esperar d铆as o meses hasta que expire de forma natural, de lo contrario, una filtraci贸n de la clave privada inutilizar铆a todo el sistema.



Es en esta situaci贸n que se revoca el certificado. Este es un paso adicional en el proceso de verificaci贸n de la firma, que implica preguntar a la autoridad de certificaci贸n que el certificado a煤n es v谩lido.



En Internet, esto se hace de la forma m谩s sencilla. La CA le proporciona una Lista de revocaci贸n de certificados (CRL) con los n煤meros de serie de todos los certificados revocados y usted verifica que el certificado no est茅 en la lista. Sin embargo, los navegadores dejaron de utilizar este enfoque a medida que la lista se hac铆a cada vez m谩s larga. Especialmente despu茅s de que exploits horribles como Heartbleed requirieran revocaciones masivas de certificados.



El Protocolo de estado de certificados en l铆nea (OCSP) es una alternativa que le permite validar certificados en tiempo real. Cada certificado contiene un OCSP Respondedor integrado, que es la URL que solicita y le indica si el certificado ha sido revocado. En el caso de Apple, esto esocsp.apple.com... Entonces, ahora, adem谩s de verificar la validez criptogr谩fica de la firma, cada vez que inicias la aplicaci贸n, realizas una verificaci贸n en tiempo real en el sitio de Apple (con algo de almacenamiento en cach茅) que a煤n consideran que el certificado del desarrollador es leg铆timo.



Problema de disponibilidad de OCSP



El gran problema con OCSP es que el servicio externo se convierte en un 煤nico punto de falla. 驴Qu茅 sucede si el respondedor OCSP no funciona o no est谩 disponible? 驴Nos estamos negando a verificar el certificado (falla)? 驴O pretendemos que la verificaci贸n fue exitosa (falla suave)?



Apple se ve obligada a utilizar un comportamiento de falla suave, de lo contrario, las aplicaciones no funcionar谩n sin conexi贸n. Todos los navegadores principales tambi茅n implementan un comportamiento de falla suave, ya que los respondedores OCSP tradicionalmente no son confiables y el navegador quiere cargar el sitio incluso si el respondedor CA est谩 temporalmente inactivo.



Pero la falla suave no es una buena opci贸n, porque con el control de la red, un atacante puede bloquear las solicitudes al respondedor y se omitir谩 la verificaci贸n. De hecho, esta "soluci贸n" del error circul贸 ampliamente en Twitter durante este incidente: el tr谩fico fue ocsp.apple.combloqueado por una l铆nea en el archivo / etc / hosts. Muchos dejar谩n esta l铆nea por un tiempo, ya que deshabilitar OCSP no causa ning煤n problema notable.



Incidente



Si la validaci贸n OCSP de Apple se basa en fallas de software, 驴por qu茅 las aplicaciones se bloquear铆an cuando el respondedor OCSP est谩 desactivado? Probablemente porque en realidad se trataba de una falla diferente: el respondedor OCSP en realidad no estaba completamente deshabilitado. Simplemente no funcion贸 bien.



Debido a la carga de millones de usuarios de todo el mundo que se estaban actualizando a macOS Big Sur, los servidores de Apple se ralentizaron y no respondieron correctamente a las solicitudes de OCSP. Pero al mismo tiempo, funcionaron lo suficientemente bien como para que el fallo suave no funcionara.



Problema de privacidad de OCSP



Adem谩s del problema de disponibilidad de OCSP, el protocolo no fue dise帽ado para proteger la privacidad en primer lugar. La solicitud OCSP b谩sica incluye una solicitud HTTP no cifrada al respondedor OCSP con el n煤mero de serie del certificado. De esta manera, no solo el respondedor puede determinar qu茅 certificado le interesa, sino tambi茅n su ISP y cualquier otra persona que intercepte los paquetes. Apple puede enumerar, en orden, qu茅 aplicaciones de desarrollador abre, y los externos pueden hacer lo mismo.







Se podr铆a haber agregado el cifrado, y hay una versi贸n mejor y m谩s privada llamada grapado OCSP , pero Apple tampoco lo ha hecho. El grapado OCSP realmente no tiene sentido en este escenario, pero esta tecnolog铆a ilustra que OCSP no deber铆a filtrar datos por defecto.



Un futuro mejor



El incidente provoc贸 una animada discusi贸n en la comunidad, en la que un lado dijo: "Tu computadora no es realmente tuya" y el otro argument贸: "Establecer confianza en las aplicaciones es dif铆cil, pero Apple lo hace bien" . De todos modos, estoy tratando de demostrar que OCSP es una forma terrible de administrar las revocaciones de certificados y, en el futuro, dar谩 lugar a m谩s incidentes relacionados con la disponibilidad y la privacidad del personal de respuesta. En mi opini贸n, esta es una mala decisi贸n de ingenier铆a: establecer la dependencia del lanzador de aplicaciones en OCSP. Al menos a corto plazo, mitigaron el da帽o aumentando los tiempos de respuesta en cach茅 .



Afortunadamente, el mejor m茅todo para revocar certificados, CRLite, est谩 casi listo. Le permite acortar todas las listas de revocaci贸n de certificados a un tama帽o razonable. En el blog de Scott Helme se proporciona un buen resumen de c贸mo CRLite usa los filtros Bloom para devolver el enfoque anterior con una lista de certificados revocados, que operaron hasta OCSP.



Los dispositivos MacOS pueden recibir peri贸dicamente actualizaciones de esta CRL y realizar comprobaciones localmente en el dispositivo, abordando problemas de privacidad y disponibilidad de OCSP. Por otro lado, dado que la lista de revocaci贸n de ID de desarrollador es mucho m谩s peque帽a que la lista de todos los certificados revocados de PKI, vale la pena preguntarse por qu茅 Apple no usa CRL. Es posible que no quieran revelar qu茅 certificados se han revocado.



Conclusi贸n



Con todo, este incidente fue un buen motivo para reflexionar sobre el modelo de confianza que impulsan organizaciones como Apple y Microsoft. El malware se ha vuelto m谩s sofisticado y la mayor铆a de las personas no pueden determinar si es seguro ejecutar ciertos binarios. La firma de c贸digo parece una excelente forma criptogr谩fica de establecer confianza para las aplicaciones y al menos vincular aplicaciones con desarrolladores reconocidos. Y revocar certificados es una parte necesaria de esa confianza.



Pero solo unos pocos fallos en el proceso de verificaci贸n OCSP estropean la elegancia criptogr谩fica del proceso de verificaci贸n y firma de c贸digo. OCSP tambi茅n se usa ampliamente para certificados TLS en Internet, pero las fallas all铆 son menos catastr贸ficas debido a la gran cantidad de CA y al desconocimiento generalizado de las fallas de los navegadores. Adem谩s, las personas est谩n acostumbradas a ver sitios web que no est谩n disponibles de vez en cuando, pero no esperan lo mismo de las aplicaciones en sus propias computadoras. A los usuarios de MacOS les preocupaba que sus propias aplicaciones se vieran afectadas por los problemas de infraestructura de Apple. Sin embargo, este es un resultado inevitable, debido al hecho de que la validaci贸n de certificados depende de una infraestructura externa y ninguna infraestructura es 100% confiable.



Scott Helme tambi茅n expresa su preocupaci贸n por el poder que obtienen las CA si la revocaci贸n de certificados realmente funciona. Incluso si no est谩 preocupado por la posibilidad de censura, a veces se producir谩n errores y deben compararse con los beneficios de seguridad. Como descubri贸 un desarrollador cuando Apple revoc贸 por error su certificado , el riesgo de ejecutar en una plataforma aislada es que puede aislarse de ella.



All Articles