Agregar un certificado autofirmado al almacén de confianza

Imagina que quieres visitar enlace .

¿Cómo puede estar seguro de que, de hecho, está visitando enlace ? Puede comprobar que la información proporcionada por el certificado SSL es auténtica.

SiunatacanterealizaunataqueMITMcontrati,elnavegadormostraráunaadvertenciaenformadeuncandadorojoenlugardeunoverde.

Si un atacante tiene la capacidad de agregar un certificado autofirmado a su tienda de confianza, el navegador verificará que el sitio web falso que el atacante está usando para atacarle es de hecho auténtico. Esto tiene implicaciones de seguridad obvias, ya que no tendrá la capacidad de verificar la autenticidad de un sitio web a través del certificado SSL.

( EDIT : Gracias, @Adnan y @ D3C4FF por señalar mi respuesta originalmente no aborda la situación de la adición de sus propios certificados de desarrollo).

Con respecto a la adición de certificados que usted mismo generó para fines de desarrollo, no creo que exista un gran riesgo de seguridad. Suponiendo que el certificado de CA raíz que generó se mantenga local y no se publique en algún lugar (o que aún se elimine después de que termine), nadie más podrá firmar certificados que se mostrarán de confianza en su navegador. Sin embargo, la sugerencia de Microsoft sigue siendo acertada, no tiene sentido saturar su almacén raíz con certificados aleatorios que usted mismo generó. Esto podría hacer que sea mucho más difícil detectar un certificado raíz malicioso real agregado por un atacante.

Certificados autofirmados

Si tiene una CA (privada), que es la misma que la del CSR que firma, luego creas un certificado autofirmado . Si, en cambio, crea claves separadas para la entidad cuya identidad desea confirmar y la CA usó para confirmar la identidad, formalmente ya no es un certificado autofirmado.

Los certificados autofirmados se utilizan principalmente para fines de prueba y, por lo tanto, son temporales. Esto se puede hacer limitando su período de validez, pero a menudo no se hace a favor de la conveniencia.

Cómo lo hacen las CA del mundo real

Las CA tendrán una jerarquía de claves / certificados (que comprende la cadena de certificados de la que probablemente haya oído hablar). Si usted, o su proveedor de sistema operativo, opta por confiar en un certificado de CA raíz, ello implica confianza en los Sub-CA cuyos certificados se firmaron con la clave de CA raíz.

Lo que esto significa es que la clave de la CA raíz requiere la mayor seguridad, ya que se puede usar para crear cualquier cantidad de Sub-CAs en las que se confiará en última instancia si alguien elige confiar en el certificado de CA raíz.

  

Asegúrese de eliminar cualquier certificado temporal de autoridad raíz de la   Entidades de certificación raíz de confianza y carpetas personales por   haga clic con el botón derecho en el certificado, luego haga clic en Eliminar.

Tiene mucho sentido ahora, si considera que un certificado CA raíz (con clave) adecuado tendrá el mayor potencial de ser abusado y creará el mayor impacto para un atacante. si comprometido Querrá mantenerlos escondidos de manera segura a menos que los esté utilizando ahora mismo para firmar un CSR de Sub-CA. Por lo tanto, elimínelos y guarde una copia para fines posteriores de firma de CSR (si lo necesita).

Sin embargo, dado que la cita es claramente sobre "certificados de autoridad raíz temporal", creo que la pista está oculta en temporary y eso es algo que el administrador del sistema define para sus propias CA y Sub-CA (es decir, si desea utilizarlas en el futuro o no).

Básicamente, puede considerar la eliminación de un certificado / clave de CA temporal para que no esté disponible para un atacante, de forma similar a las medidas de seguridad de las claves de CA raíz reales. Se supone que esta CA temporal no se utilizará para firmar más certificados (uso de desarrollo).

De modo que la pequeña palabra temporary implica un poco más en la cita de lo que parece a primera vista.

Cómo se ve esto en la práctica

Supongamos que tiene una clave de CA raíz que nunca caduca (aunque en la mayoría de los casos simplemente será un período relativamente largo, como 20 años) y un certificado de CA raíz correspondiente. Querrá mantener la clave a salvo de cualquier compromiso, especialmente si muchas personas confían en el certificado. Ese es el caso de los certificados CA raíz de, por ejemplo, Verisign o Comodo.

Esa clave de CA raíz se usará únicamente para firmar el certificado de una Sub-CA (que tiene su propia clave distinta), creando así los dos primeros enlaces en una cadena de certificados que su navegador o signtool de Microsoft, así como muchas otras utilidades, le permiten inspeccionar. La clave de CA raíz nunca se usaría directamente para procesar su CSR y, por lo tanto, confirmar su identidad como usuario final / sitio web / empresa.

Cada Sub-CA respectiva usualmente solo se usará para un propósito particular (hay campos adicionales para ciertos propósitos, como la firma de códigos) y su período de validez será un subconjunto de los certificados de CA raíz.

Pero, y esa es una diferencia entre la clave de la CA raíz y la clave de la Sub-CA: la clave de las CA raíz se puede guardar de forma segura (hablando seguridad física aquí) la mayoría de las veces , a menos que sea absolutamente necesario firmar el CSR para un nuevo Sub-CA, mientras que la clave del Sub-CA probablemente se usará en algún tipo de servidor altamente seguro para firmar los CSR del cliente (cuando se considera una autoridad de certificación de la vida real como Verisign). Esto significa que la Sub-CA está en mayor riesgo que la CA raíz y por qué quiere aplicar diferentes niveles de seguridad en primer lugar.

La ventaja es que, si alguna vez la Sub-CA se compromete, su certificado se puede colocar en una ARL / CRL (lista de revocación de autoridad / certificado), mientras que poner el certificado de la CA raíz en una ARL / CRL solo está realmente garantizado por razones técnicas (por ejemplo, utilizando el hash MD5 ahora comprometido, una longitud de clave que ya no se considera segura ...). Los costos asociados a cualquiera de estos son el factor definitorio en varios niveles:

• los costos para almacenar las claves de forma segura, en particular, la clave de CA raíz tiene que ser la más segura
• costos al cambiar los certificados de CA raíz frente a cambiar los certificados de Sub-CA
• costos al revocar (Sub) certificados CA

Si un malvado roba la clave privada de una CA en la que su computadora confía, entonces podrá emitir certificados falsos para nombres de servidores arbitrarios, y su computadora los aceptará como auténticos sin tan solo una advertencia. Ahí va su última línea de defensa contra el falso www.google.com , www.paypal.com , y así sucesivamente: bienvenidos Man En los ataques intermedios , adiós su cuenta bancaria.

Este peor escenario puede evitarse por suerte (que a menudo funciona bien) y protegiendo la clave privada de su AC personalizada contra el robo, que no es tan fácil como parece, especialmente contra los compañeros de trabajo, que a menudo tienen acceso físico intermitente a su máquina, por ejemplo, cuando se toma un descanso para tomar un café (con el acceso físico pueden hacer muchas cosas malas en su contra, pero robar un archivo de clave privada es especialmente discreto y difícil de detectar). p>     

La respuesta de Terry le da una muy buena explicación de cómo funcionan los certificados. Trataré directamente de responder tu pregunta.

El objetivo principal de tener certificados digitales en un navegador web es permitir la confianza entre el navegador y el servidor web con el que desee comunicarse. Su navegador valida el certificado enviado por el servidor utilizando la validación de firma digital utilizando los certificados raíz preinstalados. Este mecanismo criptográfico está ahí para darle una sensación de seguridad de que la parte con la que se está comunicando es realmente quien dice ser.

Puede agregar su propia jerarquía de certificados de tres niveles en el navegador para su uso personal. Esto evitará las páginas de advertencia mostradas por los navegadores cuando se encuentren con un certificado no confiable, pero imagine el caso cuando extravíe un certificado en el que su navegador confíe. Un atacante inteligente puede realizar un MITM exitoso utilizando el certificado robado y, dado que su navegador confía en el certificado, no habrá ninguna advertencia al visitar el sitio web falso que parece legítimo.

N.b. El propósito de tener confianza basada en certificados SSL es evitar MITM