que - Comprender SSL

ssl protocol (6)

Mi pregunta es: ¿no puede "B" tomar este certificado, robando la identidad de "A", lo que les permitirá autenticarse como "A" a "C"

También hay una parte privada del certificado que no se transmite (la clave privada). Sin la clave privada, B no puede autenticarse como A. De manera similar, conozco su nombre de usuario de StackOverflow, pero eso no me permite iniciar sesión como usted.

¿Por qué usar hash en el certificado si una parte de él ya está encriptada por la CA?

Al hacerlo de esta manera, cualquiera puede verificar que fue CA quien produjo el hash, y no otra persona. Esto demuestra que el certificado fue producido por la CA y, por lo tanto, la "validación, etc." fue realizado.

Si soy stackoverflow y tengo 3 servidores haciendo lo mismo, permitiendo a los clientes acceder, leer, identificar, etc., tengo que tener un certificado digital diferente para cada uno de los 3 servidores.

Depende del caso particular, pero es probable que tenga certificados idénticos en cada uno.

Tengo tres preguntas con respecto a SSL que no entiendo completamente.

Si lo recibo correctamente, un servidor A envía una solicitud a una CA determinada. Luego, recibe (después de la validación, etc.) un certificado digital compuesto por una clave pública + identidad + una inscripción de esta información usando la clave privada de la CA.
Más adelante, un cliente B quiere abrir una comunicación SSL con A , por lo que A envía B su certificado digital.
Mi pregunta es si B no puede simplemente tomar este certificado, robando así la identidad A , lo que les permitirá autenticarse como A a C , por ejemplo. Entiendo que C descifrará el certificado con la clave pública de la CA, luego cifrará su clave simétrica que solo podrá descifrar la A real.
Sin embargo, no veo dónde entra en juego la autenticación si B puede robar la identidad de A A menos que me esté perdiendo algo.
Segunda pregunta: ¿Por qué usar hash en el certificado si una parte de él ya está encriptada por la CA? ¿No significa esto que nadie puede meterse con un certificado digital (con alta probabilidad) de todos modos?
Si soy stackoverflow y tengo 3 servidores haciendo lo mismo, permitiendo a los clientes acceder, leer, identificar, etc., tengo que tener un certificado digital diferente para cada uno de los 3 servidores.

Muchas gracias.

Pregunta N ° 1

B no puede tomar este certificado [...] que les permitirá autenticarse como A a C

Esta part del diagram más grande trata con esa pregunta.

Principalmente: si solo tienes la clave pública, entonces no puedes establecer una conexión SSL con ningún cliente porque necesitas intercambiar una clave secreta con ellos y esa clave secreta debe ser encriptada usando tu clave pública, que es la razón por la cual el cliente solicita en la primera vez. Se supone que el cliente cifra la clave secreta compartida con su clave pública y se supone que debe descifrarla con su clave privada. Como no tiene la clave privada, no puede descifrar la clave de intercambio secreta, por lo tanto, no puede establecer ninguna comunicación SSL con ningún cliente.

Pregunta N ° 2

¿Por qué usar hash en el certificado si una parte de él ya está encriptada por la CA?

Esto también se responde en el diagram con la pregunta "¿qué es una firma?". Básicamente, estamos procesando todo el certificado para asegurarnos de que no haya sido alterado (integridad de los datos), de que nadie haya cambiado nada en él, y de que lo que usted ve es realmente lo que le entregó la CA. El diagrama muestra cómo hasing lo hace posible.

Pregunta N ° 3

Si soy y tengo 3 servidores [...] tengo que tener un certificado digital diferente para cada uno de los 3 servidores.

Esto no es necesariamente siempre el caso. Considere la situación en la que los tres servidores están en el mismo dominio, entonces solo necesita un certificado, si cada uno de ellos está en su propio subdominio, puede tener un solo certificado de comodín instalado en todos ellos.

Por el contrario, si tiene un servidor que aloja varios dominios, tendrá un solo certificado SSL de múltiples dominios.

En general, sí, si el archivo cert es robado, nada impedirá que alguien lo instale en su servidor y de repente asumirá la identidad del sitio robado. Sin embargo, a menos que el ladrón asuma el control de la configuración DNS del sitio original, las solicitudes de la URL del sitio irán al servidor original y el servidor del ladrón permanecerá inactivo.

Es el equivalente a construir un duplicado exacto de la Estatua de la Libertad en la Antártida con la expectativa de robar los ingresos turísticos de Nueva York. A menos que comiences a hackear todas las guías turísticas y libros de texto de historia para reemplazar a "Nueva York" con la Antártida, todos seguirán yendo a Nueva York a ver la estatua real y el ladrón tendrá un carámbano completamente grande, verde y completo.

Sin embargo, cuando obtiene un certificado de una CA, el certificado está protegido con contraseña y no puede simplemente instalarse en un servidor web. Algunos lugares eliminarán la contraseña para que el servidor web pueda reiniciarse sin intervención. Pero un sitio seguro mantendrá la contraseña en su lugar, lo que significa que cualquier reinicio del servidor matará el sitio hasta que alguien llegue a la consola de administración y entre al PW para descifrar el certificado.

Primera pregunta: tiene razón acerca de lo que obtiene de la CA, pero le falta una parte de lo que necesita antes de enviar su solicitud a la CA. Necesita (1) una solicitud de certificado y (2) la clave privada correspondiente. No envía la clave privada como parte de la solicitud; lo mantienes en secreto en tu servidor. Su certificado firmado incluye una copia de la clave pública correspondiente. Antes de que un cliente crea que B "posee" el certificado, B tiene que demostrarlo utilizando la clave secreta para firmar un desafío enviado por el cliente. B no puede hacer eso sin la clave privada de A.

Segunda pregunta: la criptografía de clave pública típica opera en datos de tamaño fijo (por ejemplo, 2048 bits) y es de alguna manera computacionalmente costosa. Entonces, para firmar digitalmente un documento de tamaño arbitrario, el documento se reduce a un bloque de tamaño fijo que luego se cifra con la clave privada.

Tercera pregunta: puede usar un solo certificado en varios servidores; solo necesita la clave privada correspondiente en todos los servidores. (Y por supuesto, el nombre DNS utilizado para llegar al servidor debe coincidir con el CN en el certificado, o el cliente probablemente se opondrá. Pero tener un nombre DNS se refiere a múltiples servidores es un medio común y simple de equilibrio de carga).

También tengo algunas respuestas.

Q1) Si B roba el certificado de A e intenta hacerse pasar por A a C.

C validará la dirección IP de B y descubrirá que no pertenece a C. Luego abortará la conexión SSL. Por supuesto, incluso si C envía un mensaje cifrado, solo el Real A podrá descifrarlo.

Q2) Un certificado generalmente se representa en texto sin formato con el formato común X.509. Todas las entradas son legibles por cualquier persona. El proceso de hashing se usa para firmar digitalmente un documento. La firma digital de un certificado hace que el usuario final valide que el certificado no haya sido alterado por nadie después de haber sido creado. El hash y el cifrado del contenido mediante la clave privada del emisor se realizan para crear una firma digital.

Una identidad SSL se caracteriza por cuatro partes:

Una clave privada , que no se comparte con nadie.
Una clave pública , que puede compartir con cualquier persona.
La clave pública y privada forman un par coincidente: cualquier cosa que cifre con una se puede descifrar con la otra, pero no puede descifrar algo cifrado con la clave pública sin la clave privada o viceversa. Esto es magia matemática genuina.
Metadatos adjuntos a la clave pública que indican de quién están hablando. Para una clave de servidor, esto identificaría el nombre DNS del servicio que se está asegurando (entre otras cosas). Otros datos aquí incluyen cosas como los usos previstos (usados principalmente para limitar la cantidad de daño que puede hacer una persona con un certificado robado) y una fecha de vencimiento (para limitar el tiempo que se puede usar un certificado robado).
Una firma digital en la combinación de clave pública y metadatos para que no se puedan manipular y para que otra persona sepa cuánto confiar en los metadatos. Hay varias formas de manejar quién hace la firma:
- Firma con la clave privada (de la parte 1, arriba); un certificado autofirmado Cualquiera puede hacer esto pero no transmite mucha confianza (precisamente porque cualquiera puede hacer esto).
- Conseguir que un grupo de personas que confíen entre sí para responder por usted mediante la firma del certificado; una red de confianza (llamada así porque la relación de confianza es transitiva y, a menudo, simétrica a medida que las personas firman los certificados de los demás).
- Conseguir un tercero confiable para hacer la firma; una autoridad de certificación (CA). La identidad de la CA está garantizada por otra CA de nivel superior en una cadena de confianza que regresa a alguna autoridad raíz en la que "todos" confían (es decir, hay una lista integrada en su biblioteca SSL, que es posible actualizar en el momento del despliegue).
No existe una diferencia técnica básica entre los tres tipos de autoridades anteriores, pero la naturaleza de la confianza que la gente pone en ellos es extremadamente variable. ¡Los detalles de por qué esto es así requerirían una respuesta muy larga!

Los elementos 2-4 son lo que comprende el certificado digital.

Cuando el cliente, B, inicia el protocolo SSL con el servidor, A, el certificado digital del servidor se comunica a B como parte del protocolo. La clave privada de A no se envía, pero como B puede descifrar correctamente un mensaje enviado por el otro extremo con la clave pública en el certificado digital, B puede saber que A tiene la clave privada que coincide. B puede mirar los metadatos en el certificado y ver que el otro extremo dice ser A, y puede examinar la firma para ver cuánto confiar en esa afirmación; si los metadatos están firmados por una autoridad que B confía (directa o indirectamente), B puede confiar en que el otro extremo tiene la identidad SSL de A. Si esa identidad es la que esperaban (es decir, querían hablar con A: en la práctica, esto se hace comparando el nombre DNS en el certificado con el nombre que usaron al buscar la dirección del servidor), entonces pueden saben que tienen un canal de comunicaciones seguro: están listos para irse.

Sin embargo, B no puede suplantar a A con esa información: B no obtiene la clave privada de A, por lo que se derrumbaría en la primera etapa de la verificación. Para que un tercero se haga pasar por B, necesitan tener (al menos) dos de:

La clave privada . El propietario de la identidad debe tener cuidado para evitar que esto suceda, pero finalmente está en sus manos.
Una autoridad de confianza que hace declaraciones falsas . Aquí hay debilidades ocasionales: una autoridad autofirmada nunca es muy confiable, una red de confianza se topa con problemas porque la confianza es algo difícil de manejar transitoriamente, y algunas CA son completamente inescrupulosas y otras demasiado inclinadas a no excluir a la escoria, pero principalmente esto funciona bastante bien porque la mayoría de las partes están dispuestas a no causar problemas, a menudo por razones financieras.
Una forma de envenenar DNS para que el objetivo crea que un servidor diferente es el que se está personificando. Sin DNSsec esto es algo desafortunadamente fácil, pero este problema en particular se está reduciendo.

En cuanto a tus otras preguntas ...

¿Por qué usar hash en el certificado si una parte de él ya está encriptada por la CA? ¿No significa esto que nadie puede meterse con un certificado digital (con alta probabilidad) de todos modos?

Si bien las claves son bastante largas, los certificados son más largos (por un lado, incluyen la clave pública de los firmantes de todos modos, que normalmente tiene la misma longitud que la clave que se firma). Hashing es parte del algoritmo general para firmar documentos de todos modos porque nadie quiere restringirse a firmar solo cosas muy cortas. Dado que el algoritmo es obligatorio, tiene sentido usarlo para este propósito.

Si soy y tengo 3 servidores haciendo lo mismo, permitiendo a los clientes acceder, leer, identificar, etc., tengo que tener un certificado digital diferente para cada uno de los 3 servidores.

Si tiene varios servidores que brindan el mismo nombre DNS (hay muchas formas de hacerlo, una de las más sencillas es el servicio DNS de turnos) puede poner la misma identidad en cada uno de ellos. Esto reduce ligeramente la seguridad, pero solo muy levemente; todavía es un servicio que sucede que muchos servidores lo implementan. En teoría, podría darle a cada una una identidad diferente (aunque con el mismo nombre) pero no puedo pensar en ninguna buena razón para hacerlo; es más probable que preocupe a la gente que la alternativa.

También tenga en cuenta que es posible tener un certificado para más de un nombre de servicio a la vez. Hay dos mecanismos para hacer esto (agregar nombres alternativos al certificado o usar un comodín en el nombre en el certificado) pero las CA tienden a cobrar bastante por firmar certificados con ellos.