SSL / TLS - ¿Distinción entre certificado autofirmado y CA autofirmado, y otras preguntas?

Un certificado de CA es un certificado que es propiedad de una CA y está marcado como apto para su uso como CA; a saber, que contiene una extensión Basic Constraints con el indicador "cA" establecido en VERDADERO.

Un certificado autofirmado es un certificado que se firma con la clave privada correspondiente a la clave pública que se encuentra en el propio certificado. Esto significa que el certificado fue emitido por el propietario del certificado, no por otra persona.

Un certificado de CA puede ser autoemitido; este es el caso normal de una CA raíz . Una CA raíz es una CA que existe por sí misma y está destinada a ser de confianza a priori (incluida manualmente en un navegador web o en un almacén de certificados de SO) y no en virtud de ser emitida por otra CA de confianza. .

Crear una CA autofirmada y usarla para firmar el certificado del servidor real (opción 1B) es útil si prevé emitir varios certificados (posiblemente muchos) para muchos servidores. Con su propia CA raíz (eso es lo que significa la opción 1B), solo tendría que insertar el certificado uno manualmente en todos los clientes (su CA raíz autofirmada). Si solo tiene un único certificado de servidor para producir, y predice que las cosas seguirán siendo así, entonces la opción 1A es tan buena como 1B, posiblemente mejor, ya que es más simple.

La opción -des3 es para el cifrado simétrico de la clave de CA. No esta mal. No hay suficiente potencia de cómputo (o, para el caso, potencia en bruto) en la Tierra para interrumpir correctamente el cifrado 3DES realizado. Ir a AES-256 sería inútil, y podría resultar difícil porque la herramienta de línea de comandos OpenSSL no lo admite de forma inmediata (OpenSSL, la biblioteca, incluye una implementación AES-256, pero la línea de comandos Las herramientas no tienen fácil acceso a él cuando se trata del cifrado simétrico de una clave privada).

Las firmas digitales (las que se aplican en los certificados) utilizan, por definición, claves asimétricas . Las claves asimétricas requieren una gran cantidad de estructura matemática interna, y esa estructura puede usarse para debilitarlas, por lo que tienen que ser mucho más grandes que las claves simétricas para lograr un nivel de seguridad decente. Es por eso que una buena clave RSA tendrá que ir a 2048 bits aproximadamente, mientras que una clave simétrica de 128 bits ya es sólida. La línea:

openssl genrsa -des3 -out server.key 4096

genera un nuevo par de claves RSA asimétricas de 4096 bits de tamaño y las almacena en el archivo server.key . Ese almacenamiento está además protegido (encriptado) con 3DES, utilizando una clave simétrica derivada de la contraseña que ingresa en ese punto.

La clave privada incluye una copia de la clave pública. La clave pública (pero, por supuesto, no la clave privada) también formará parte del certificado : primero se copia en una solicitud de certificado (el ".csr" archivo) y luego en el propio certificado.

CA vs. Cert autofirmado

En cualquier instalación de PKI, el certificado autofirmado (CA o entidad final, por ejemplo, un servidor) debe distribuirse a todas las partes confiables. Para su usuario promedio, los sistemas de CA públicos conocidos y altamente confiables se implementan automáticamente. Para infraestructuras más pequeñas, como los entornos corporativos internos, un certificado interno de CA se puede empaquetar automáticamente en navegadores, servidores y otras distribuciones. En todos los casos, si el certificado es autofirmado, se debe confiar explícitamente en él.

Las grandes diferencias son:

• certificado de entidad final autofirmado: si crea más de un certificado, TODOS los certificados que cree deben ser de confianza explícita en cada punto final. Si un certificado está comprometido, la confianza debe eliminarse de cada punto final. Se puede hacer con scripts automatizados, pero es mucho trabajo.

• CA autofirmado - > Entidad final firmada: debe confiar explícitamente en la entidad emisora de certificados, y luego se confiará automáticamente en cada entidad final. Si planea crear múltiples certificados de servidor en un lapso de tiempo, esto reducirá la carga de trabajo. El truco es que necesita una forma de verificar la revocación si existe alguna posibilidad de compromiso del certificado del servidor (que siempre existe). Aquí es donde entra en juego la complejidad: las CRL u OCSP son las formas estándar de comunicación sobre un compromiso, pero eso significa hacer más trabajo, no menos, para crear y distribuir las CRL y (opcionalmente) ejecutar y ejecutar un servidor OCSP. Además, los navegadores deben configurarse para verificar esto, que no es una configuración predeterminada.

Tiene mucho que ver con los riesgos en su sistema y con lo que cree que será el ciclo de vida de la emisión y revocación de su certificado.

DES3 vs. AES-256

De la documentación de openSSL , sus opciones con el comando que ha citado son:

• DES
• DES3
• IDEA

Recomendaría IDEA como el algoritmo más nuevo y la mejor práctica, pero no si alguno de sus sistemas no es compatible. Esto puede ser un verdadero problema: tratar de diagnosticar por qué no puede usar un certificado dado y una clave privada puede ser extremadamente frustrante y las respuestas proporcionadas por la mayoría de los sistemas son confusas y difíciles de entender.

Según esta documentación:

  

Estas opciones cifran la clave privada con el DES, el triple DES o el   La IDEA cifra respectivamente antes de emitirla. Si ninguno de estos   Las opciones se especifican, no se utiliza cifrado. Si se utiliza cifrado a   se solicita la frase de contraseña si no se proporciona a través de -passout   argumento.

Así es como la clave privada se almacena y protege dentro del archivo server.key. No tiene nada que ver con cómo el certificado le permite a su servidor comunicarse con otros sistemas.

En un sistema de CA normal (OpenSSL puede ser un poco primitivo), hay una manera de especificar cómo se puede usar la clave para el cifrado, que puede incluir una configuración SSL válida, como permitir o aplicar una clave de sesión de 256 bits.

Este no es un factor de la clave del certificado (en su ejemplo, es una clave asimétrica RSA de 4096 bits): es un factor de lo que el par de claves representado puede hacer de acuerdo con la CA y su política de seguridad asociada. . Esto normalmente controla cómo se configura una sesión SSL.

Para que quede claro no se crean claves de sesión SSL en la creación de un certificado . Las claves de sesión se crean y negocian en el momento en que un cliente se comunica con un servidor, mucho después de que el certificado se crea, firma e instala.

1. Si una empresa desea generar su propia AC, puede incluirla en las computadoras de su personal, por ejemplo, para confiar en sitios web internos o servidores proxy (en caso de inspección de conexiones SSL).
2. 3 DES no está roto, pero AES: proporciona mayor seguridad que DES y es computacionalmente más eficiente que 3DES. AES ofrece tres fortalezas clave diferentes: 128, 192 y 256 bits llaves. 3DES es esencialmente DES cifrado 3 veces.
3. RSA es un algoritmo costoso y no es realmente adecuado para cifrar todas las conexiones. Entonces, lo que sucede es que, en lugar de transmitir todo lo cifrado con RSA, el servidor crea una clave aleatoria compuesta de 256 bits (puede ver esta clave como una contraseña, solo un grupo de caracteres aleatorios, 256 bits de longitud) y la cifra con La clave RSA y la envía al otro extremo. Desde aquí, ambos utilizan un algoritmo de cifrado simétrico como AES (que es mucho más rápido que RSA para cifrar y descifrar datos) para transmitir datos de forma segura.

En orden:

  

El documento muestra dos formas: (1A) Generar su propio certificado autofirmado. y (1B) Generar su propio certificado / CA y luego usar el CA para firmar su certificado.

     

No entiendo cuál es la diferencia entre los dos. ¿Cuál es el punto de generar su propia CA si ninguno de los navegadores confía en ella (a diferencia de los certificados firmados por Verisign)?

Incluso si su certificado no está firmado por una CA que es confiable por un navegador, se puede usar para cifrar el tráfico entre el cliente y el servidor. Esto significa que obtendrá el secreto que desea gracias al cifrado. Lo que no obtendrá es ese pequeño candado verde en los navegadores de sus visitantes que les dice que la propiedad de su dominio ha sido verificada por una autoridad de certificación. Por lo tanto, no podrán verificar la autenticidad de su sitio (posible MITM) pero la comunicación se cifrará.

Un certificado autofirmado es la raíz de la confianza en todas las jerarquías de certificados. Verisign tiene un certificado autofirmado que es la raíz de la confianza para todos los certificados que firmen (y probablemente se encuentre en un búnker en algún lugar). Si desea poder jugar una autoridad de certificación (es decir, crear más de un certificado y hacer que formen parte de la misma cadena de confianza), debe crear un certificado autofirmado y usarlo para firmar los otros certificados (consulte openssl req y openssl x509 ).

  

¿Se utiliza (1B) para prevenir ataques MITM?

No. Su (1B) está destinado a permitir la creación de múltiples certificados que están todos vinculados a la misma CA, como lo indica el autor en el primer párrafo. Básicamente, este es un ejercicio que le muestra efectivamente qué es una jerarquía de certificados.

  

Si es así, ¿debería usar (1B) sobre (1A)?

Para un solo sitio web, puede salirse con 1A bien, aunque hacer 1B es un buen ejercicio.

  

Me di cuenta de que el documento utiliza cifrado des3. ¿Sería posible usar el cifrado aes-256 a menos que haya una buena razón para usar des3? (También, ¿cómo hago esto?)

Falta algo de la documentación de openssl en las distribuciones de Linux, pero puede sustituir -aes256 en lugar de -des3 para usar el AES de 256 bits. Del mismo modo, las variantes de 192 y 128 bits también están disponibles. Verifique la salida de openssl genrsa --help para la lista de algoritmos compatibles. En cuanto a la selección correcta del algoritmo: mientras no se sepa que el algoritmo esté roto, hay poca diferencia. Tanto AES256 como triple DES (des3) son muy fuertes. Generalmente prefiero AES porque es más eficiente.

  

openssl genrsa -des3 -out server.key 4096   ¿Esta línea significa que está generando una clave simétrica (des3) y luego generando una clave pública (RSA 4096 bit)?

No. Este comando hace que openssl cree una clave privada RSA de 4096 bits que se cifra utilizando el triple DES. Se le pedirá una frase de contraseña y, antes de poder usar esta clave para cualquier propósito, tendrá que descifrarla utilizando la misma frase de contraseña. El objetivo es evitar el uso de la clave en caso de pérdida / robo.

Como parece que está buscando información general aquí, voy a mantener mi respuesta breve pero siéntase libre de leer openssl documention

1. Una Autoridad de Certificación (CA) se usa para firmar otros certificados para crear una red de confianza. Por ejemplo: si obtuvieras un certificado de terceros, recibirías un certificado firmado por otra persona (por ejemplo, verisign, koomodo, etc.). Estas son "CA confiables" que el almacén de claves del navegador de un usuario podrá verificar. El navegador examina su certificado de YYY.com y, si está firmado por un agente de confianza y no se revoca, lo acepta como un buen (bloqueo verde). Si no hay una CA de confianza en la cadena de firmas, no hay forma de saber si el certificado es confiable.

2. Debes poder hacerlo. prueba openssl genrsa -aes256 -out server.key 4096

3. Tendrá que hacer una investigación más profunda para comprender realmente este tema, pero a un nivel muy alto, la clave privada se utiliza para generar su par de claves asimétricas. En el artículo al que hace referencia, la sección "GENERACIÓN DE CLAVE DSA" muestra cómo crear su clave privada y "CREAR CERTIFICADO AUTOMÁTICO DE UNA SOLICITUD DE FIRMA DE CERTIFICADO" muestra el uso de esa tecla para firmar un CSR para que el certificado resultante sea de confianza para su AC

Esta es una revisión REAL rápida y sucia de los conceptos de SSL (espero ser flameado :), por lo que te recomiendo que profundices más si realmente quieres familiarizarte con SSL. Hay una pequeña descripción general de SSL en gavaghan.org que debería ayudar a brindarle una comprensión más completa de la tecnología. Un google rápido de 'SSL tutorial' o similar también debería dar buenos resultados.