el proceso de encriptación SSL y su seguridad

  

1. Si hay un proxy interceptor entre el servidor web y el cliente, principalmente el proxy utiliza sus propios certificados firmados en los que el cliente puede o no puede confiar. Entonces, ¿por qué no hacer proxy simplemente tomar el certificado del servidor y enviarlo al cliente para que el cliente confíe en él? Además, si la clave privada solo la tiene el servidor, ¿por qué un intermediario otorga su propio certificado y descifra el mensaje?
  

Si el proxy interceptor utiliza certificados autofirmados (o firmados por su propia CA) generados sobre la marcha, el certificado pasado al cliente no será confiable, ya que no tiene una cadena de certificados válida. Si el cliente confía en los certificados o en la CA utilizada (lo que suele ocurrir en las redes internas), el usuario crédulo puede detectar todo el tráfico sin sospechas. Sin embargo, puede detectar la interceptación mirando el certificado (cadena) en su software.

Si el proxy no usa su propio certificado sino el certificado del servidor, no puede descifrar el tráfico. La clave pública en el certificado siempre corresponde a una clave privada específica, que no es conocida por otras.

El certificado del servidor contiene una firma digital de la CA (principalmente un certificado intermedio), que es un valor de hash firmado. La firma se genera con su clave privada y se puede verificar con la clave pública utilizando el siguiente certificado en el llavero. Esto se puede repetir varias veces, hasta que se otorgue un certificado, que no tiene padre y el cliente confía en él (Root-certificate)

  

2. El hash de firma generado por la clave privada se puede descifrar con una clave pública. ¿Alguien no puede descifrar eso además del cliente y puede ver la firma?
  

La firma no contiene ninguna información confidencial. Por lo general, la firma se basa en un valor hash de un archivo, mensaje o (parte de) un certificado. Todos los que tengan la clave pública pueden verificar la firma y comparar los valores de hash. Si coinciden, la firma es válida, de lo contrario no.

Consulte también ¿Cuál es el valor real de una huella digital de certificado?

  

3. ¿El cliente ya tiene la clave pública con la que inicia el mensaje cifrado o primero pregunta al servidor?
  

A menos que el cliente utilice fijación de certificados , no tiene información sobre el certificado de servidores y la clave pública. El servidor envía el certificado al comienzo de una sesión TLS.

Criptografía de clave pública

Primero debe comprender el principio de criptografía de clave pública. Tanto el servidor como el cliente tienen su propia clave pública y clave (secreta / privada).

La clave pública se puede usar para dos cosas.

• Cifrar datos a receta .
• Verifique los datos recibidos del remitente u otros datos firmados, como certificados firmados.

La clave privada también se puede usar para dos cosas.

• Descifra los datos recibidos del remitente.
• Firmar datos en receptor u otros datos, como certificados firmados.

Cuando realice el envío de datos a una receta , se seguirán los siguientes pasos:

1. El remitente firma los datos con su clave privada.
2. El remitente encripta los datos con recetas clave pública
3. El receptor descifra los datos con su clave privada.
4. El receptor verifica la firma de remitentes con remitentes clave pública.

Cadena de certificados

Un certificado es un «documento digital» que verifica la propiedad de la clave pública, el certificado se firma de la misma manera que otros datos en la criptografía de clave pública. Y los certificados pueden iniciar sesión con una clave privada que pertenece a otro certificado firmado por un tercer certificado, esto se denomina cadena de certificados

Tomemos un ejemplo, el emisor de certificados envía un certificado a un host web. El certificado que pertenece al emisor de certificados está firmado por una entidad emisora de certificados . Se completarán los siguientes pasos.

1. La autoridad de certificación crea un par de claves públicas con el certificado de pertenencia. (Certificado raíz)
2. La autoridad de certificación firma su propio certificado con su clave privada. (Autofirmado)
3. El emisor de certificados crea un par de claves públicas con el certificado de pertenencia.
4. El certificado de autoridad firma emisores de certificados con su clave privada.
5. El webhost crea un par de claves públicas con el certificado de pertenencia.
6. El emisor de certificados firma el certificado de webhosts con su clave privada.

Esto se denomina cadena de certificados , si el certificado de la autoridad de certificados es un certificado de confianza, el certificado de webhost es de confianza. Esta cadena se puede expandir hasta el infinito.

Seguridad de la capa de transporte

  

1. Si hay un proxy interceptor entre el servidor web y el cliente, principalmente el proxy utiliza sus propios certificados firmados en los que el cliente puede o no puede confiar. Entonces, ¿por qué no hacer proxy simplemente tomar el certificado del servidor y enviarlo al cliente para que el cliente confíe en él? Además, si la clave privada solo la tiene el servidor, ¿por qué un intermediario otorga su propio certificado y descifra el mensaje?
  

Debido a que hay una clave pública que pertenece al certificado enviado por el servidor , el cliente cifrará los datos utilizando la clave pública del servidor , y middle-man no puede descifrar los datos enviados por client ya que middle-man no tiene la clave privada del servidor .

  

2. El hash de firma generado por la clave privada se puede descifrar con una clave pública. ¿Alguien no puede descifrar eso además del cliente y puede ver la firma?
  

La firma no está cifrada, por lo que no puede descifrarla. Pero puede verificarlo usando la clave pública del remitente , y todos los que tengan la clave pública del remitente pueden verificar la firma.

  

3. ¿El cliente ya tiene la clave pública con la que inicia el mensaje cifrado o primero pregunta al servidor?
  

Normalmente, la clave pública y el certificado se intercambian bajo el protocolo de enlace de la sesión TLS. Pero es posible generar previamente un certificado y otorgarle al servidor ese certificado antes del protocolo de enlace TLS. Por ejemplo, esto se usa en el servidor OpenSSH.

  

Si hay un proxy de intercepción entre el servidor web y el   cliente, en su mayoría el proxy utiliza sus propios certificados firmados que el   El cliente puede o no puede confiar. Entonces ¿por qué no apoderarse simplemente tomar la   certificado del servidor y reenvíelo al cliente para que el cliente   Confía en ello. Además, si la clave privada solo está en poder del servidor, entonces ¿cómo?   ¿un intermediario da su propio certificado y descifra el mensaje?

Si el proxy tomó el certificado del servidor, no podrá descifrar el envío del secreto del maestro del maestro, ya que está cifrado con la clave pública del servidor.

Si un intermediario otorga su propio certificado, el cliente cifrará el secreto del premaster con la clave pública del proxy, no el servidor.

Puede pensar que un proxy interceptor es tanto un servidor como un cliente. Así que en lugar de

Client --> Server

Es

Client --> Proxy Server --> Proxy Client -- > Server

por lo que habrá dos conexiones separadas y dos túneles SSL / TLS separados.

  

El hash de la firma generado por la clave privada se puede descifrar con   una clave pública Alguien no puede descifrar ese otro que el cliente y puede   ver la firma?

No estoy seguro de lo que quieres decir con esto. No es descifrado o cifrado, es una firma. Un cliente puede verificar que algo fue firmado por una clave privada con la clave pública correspondiente, pero nada más puede firmar nada sin la clave privada.

  

¿El cliente ya tiene la clave pública con la que inicia el   ¿Mensaje cifrado o primero pregunta al servidor?

El servidor envía la cadena de certificados en su mensaje server hello . La hoja del certificado contiene la clave pública. El cliente ya tiene certificados raíz, por lo que sabe en qué confiar (cualquier cadena que conduzca a una raíz confiable).

Consulte Los primeros milisegundos de una conexión HTTPS para una buena guía de imprimación.

El intermediario tendría que "falsificar" el certificado del servidor creando un certificado con el mismo nombre de host pero que tiene un par de llaves controlado por el intermediario.

Esto se debe a que si el intermediario simplemente pasa el certificado del servidor real al cliente, el cliente y el servidor establecerán un intercambio seguro de claves y un canal cifrado que el intermediario no podrá escuchar. Si piensa en esto, SSL no tendría ningún valor si no fuera así, ya que Internet es una red descentralizada y siempre hay múltiples intermediarios entre el cliente y el servidor.

Entonces, en un proxy de interceptación https, el intermediario tomará los detalles del certificado del servidor y creará un nuevo certificado con el mismo nombre de host pero que tiene las claves que controla el intermediario para que el intermediario pueda descifrar la comunicación entre él y el cliente. y servidor. Sin embargo, en la mayoría de los casos esto solo no será suficiente. Como medida de seguridad, los navegadores advertirán sobre cualquier certificado autofirmado o firmado por raíces en las que no confíen. Para suplantar correctamente el servidor real a un cliente, el certificado raíz del intermediario debería instalarse en el almacén raíz de confianza del cliente.