¿Los principales navegadores implementan CRL? (¿Y si no, Pórque no?)

En primer lugar, agregar el falso certificado comodín de Google a una CRL no detendría el ataque si los malos realmente tienen el control del certificado raíz. No puedes asumir que no lo hacen.

En segundo lugar, las CRL tienen algunos problemas incorporados, particularmente en el área de escalabilidad. Debe agregar cada certificado revocado a la lista, y cada navegador debe actualizar su copia de la lista completa con la frecuencia suficiente para evitar ser atacado.

Hay un estándar más nuevo llamado OCSP que se implementa ampliamente y que aborda algunas de estas inquietudes, pero porque funciona haciendo que el navegador verifique cada certificado según sea necesario con el respondedor OSCP (que puede o no ser administrado por la misma entidad que el CA), crea un problema de privacidad: el respondedor de OCSP ahora sabe donde quiera que vaya. Además, crea un problema de confiabilidad si el servidor OCSP de la CA está inactivo.

Hay una variante en este esquema llamada grapado OCSP que resuelve la mayoría de los problemas OCSP y es probablemente lo mejor que podemos hacer a corto plazo. En este esquema, el servidor, no el cliente, obtiene una validación OCSP del servidor y la “grapa” al certificado. El cliente puede verificar criptográficamente que la afirmación OCSP. Esto elimina el problema de privacidad y mitiga el problema de disponibilidad.

https://secure.wikimedia.org/wik…

Sin embargo, hay un problema más profundo: los clientes generalmente no hacen lo correcto cuando el servidor CRL u OCSP no está disponible. En particular, una amplia variedad de clientes ignora un servidor OCSP no disponible, suponiendo que el certificado sea válido. Esto es, por supuesto, exactamente al revés: un atacante podría simplemente filtrar su tráfico OCSP y no tendría forma de saber que el certificado fue revocado.

De hecho, en Mac, por ejemplo, debe usar una combinación de teclas secretas en las preferencias de Llavero para incluso activar las opciones para tratar estrictamente la verificación de OCSP y CRL. Es una locura. (Bueno, es el resultado del hecho de que muchas CA no manejan bien OCSP y CRL, pero esa es otra historia).

Entonces, el resultado es que sí, casi todos los navegadores son compatibles con CRL (y OCSP) en principio, pero generalmente se configura de tal manera que es inútil.

¿Por qué revocar certificados específicos cuando puede eliminar la confianza en todo el emisor del certificado ?

Esto es tangencial a la pregunta, pero según mi lectura de http://www.microsoft.com/technet …,

Todas las ediciones compatibles de Windows Vista, Windows 7, Windows Server 2008 y Windows Server 2008 R2 utilizan la Lista de confianza de certificados de Microsoft para validar la confianza de una autoridad de certificación. Los usuarios de estos sistemas operativos recibirán un error de certificado no válido cuando naveguen a un sitio web o intenten instalar programas firmados por el certificado raíz de DigiNotar. En esos casos, los usuarios deben seguir las instrucciones del mensaje. Microsoft lanzará una futura actualización para abordar este problema para todas las ediciones compatibles de Windows XP y Windows Server 2003.

Me imagino que las cosas “simplemente funcionan” para los usuarios de IE.

Y Firefox revocó manualmente el certificado raíz de DigiNotar en una actualización que envió a todos los usuarios, http://blog.mozilla.com/security
Chrome también promovió una actualización que tuvo el mismo efecto (lo siento, no hay enlace).

Por separado, los usuarios de OS X que intentaron usar KeyChain para “desconfiar” de DigiNotar a nivel del sistema operativo informaron problemas a la revista PC World, http://www.pcworld.com/businessc… .