00.https básico

marca de agua, tamaño_16, texto_QDUxQ1RP5Y2a5a6i, color_FFFFFF, t_100, g_se, x_10, y_10, shadow_90, type_ZmFuZ3poZW5naGVpdGk =


Tabla de contenido


Glosario

El
algoritmo comúnmente utilizado para el cifrado y descifrado simétrico es AES. El proceso es el siguiente:
A y B se comunican, y ambas partes utilizan la misma clave (como 123456) para cifrar y descifrar datos.
A usa 123456 para cifrar los datos "Hola B" primero, y luego los transmite a B. Luego, B usa 123456 para descifrar los datos recibidos y obtener el texto original "Hola B"
. El propósito del cifrado y descifrado simétrico es asegurar el confidencialidad del mensaje.

El
algoritmo más utilizado para el cifrado y descifrado asimétrico es RSA. El proceso es el siguiente para
generar un par de claves públicas y privadas. La clave privada la tienes tú mismo y la tienes oculta en la entrepierna. La clave pública se puede enviar a cualquier persona, como un pequeño anuncio.

A tiene la clave pública de B y B tiene la clave privada. A primero usa la clave pública de B para cifrar el mensaje "Hola B" y luego lo envía a B.
Después de recibir el mensaje , B usa la clave privada oculta en la entrepierna para descifrarlo. "Hola B"

¿Qué pasa si B quiere enviar un mensaje a A?

Usa la clave privada escondida en la entrepierna para encriptar "Hola A" y envíalo a A. Después de recibir el mensaje, A usa la clave pública de B para descifrar y obtener "Hola A" Parece que no hay problema, ¿verdad?

Después de una cuidadosa consideración, cualquiera puede obtener la clave pública de B. De esta manera, el mensaje cifrado por B con la clave privada puede ser descifrado por todos.

Por lo tanto, el uso correcto del cifrado y descifrado asimétrico es `` cifrado de clave pública y descifrado de clave privada para lograr el cifrado y descifrado '', `` cifrado de clave privada y descifrado de clave pública para lograr firma digital y firma digital ''.

El propósito del cifrado y descifrado asimétrico

  • Uno es garantizar la confidencialidad del mensaje,
  • El segundo es garantizar que la identidad de la fuente del mensaje sea confirmada por tres partes (el papel de la firma digital)

Acuerdo clave

Un algoritmo que suena más mágico al principio es que A y B pueden calcular el mismo número por sí mismos mientras intercambian parte de los datos públicos.

Da un ejemplo muy simple

A y B primero se comunican y eligen el mismo número 100 (que se puede revelar), y luego A elige un número como 3 (escondido en la entrepierna).

B también eligió en silencio un número como el 9 en su corazón (escondido en la entrepierna),

A multiplica 3 por 100 para obtener 300 (se puede revelar), B multiplica 9 por 100 para obtener 900 (se puede revelar),

Entonces AB intercambia 300 y 900 entre sí. A partir de ahora, A tiene tres números de 100, 3, 900
y B tiene tres números de 100, 9, 300

¡Optimista! A multiplica 3 por 900 para obtener 2700, B multiplica 9 por 300 para obtener 2700, 2700 se puede utilizar como clave para la comunicación de cifrado y descifrado,

Y 2700 no se difundieron en la red durante todo el proceso.

Hash unidireccional

Esto debería ser fácil de entender. De hecho, es hash, que es común como MD5 o SHA1, SHA2, SHA3, etc. El hash unidireccional es para garantizar la integridad del mensaje, lo que significa groseramente asegurarse de que el mensaje no haya sido manipulado.

firma digital

Se puede implementar RSA en cifrado y descifrado asimétrico, generalmente para garantizar la confirmación tripartita de la fuente del mensaje.
Es decir, esta firma digital se utiliza para confirmar la identidad del remitente .
Esta tecnología es muy poderosa, TA ofrece garantías para los siguientes problemas

B usa la clave privada para cifrar y genera una firma digital, y A usa la clave pública (B's) para realizar el descifrado inverso de la firma digital Si tiene éxito, debe indicar que los datos provienen de B;

B quiere enviar "Hola, baba ..." a A. Debajo del contenido, use msg para referirse a 
    B, primero use la función hash para actuar sobre el contenido que se va a transmitir msg, genere un resumen 
    y luego B use el suyo clave privada sobre la que actuar En el resumen, generar la firma digital firma 
    B, adjuntar la firma a la carta y enviarla a A. Es decir, el contenido enviado es aproximadamente msg + firma 
    
A para recibir el contenido enviado por B. msg + firma 
    saca la firma, descifra la firma con la clave pública de B y obtiene Digest, el descifrado es exitoso, lo que indica que de hecho es A enviado por B para 
    sacar msg, y usa la misma función hash para actuar sobre msg para obtener digest1 . Si digest1 == disgest, la información no ha sido modificada 
.------------- ----------------------- --------------------------- ----------------------- 
C usa la computadora de A y reemplaza la clave pública existente de B de A con su propia clave pública (de C) 
y luego C puede fingir ser B y escribir en 
A. Si A encuentra que está mal, esta es la autoridad de certificación que CA intervendrá

Si una tercera persona C usa su clave privada para generar una firma digital, entonces C secuestra la red entre B y A, y C finge ser B y envía su firma digital a A, entonces A usa la clave pública de B para descifrar la firma digital , Informará un error!

Las
CA de certificados digitales emitidas a los solicitantes entienden aproximadamente que el propósito de los certificados digitales es "asegurar a todos que la clave pública de A es realmente la clave pública de A". El contenido del certificado digital incluye: el contenido de la clave pública, el valor hash unidireccional del contenido de la clave pública, el método utilizado para calcular el hash unidireccional, la firma digital del valor hash unidireccional del contenido clave, la fecha de emisión y caducidad del certificado digital Hora y muchas otras cosas ... De hecho, es lo que pasa en su navegador cuando visita sitios web HTTPS.

Certificate.png

Agencia de CA

La organización que emitió el certificado digital

Cifrado asimétrico

El cifrado y descifrado asimétrico probablemente significa que el servidor tiene un par de claves públicas y privadas, donde la clave pública está abierta a cualquier persona, y la clave privada debe estar oculta en la entrepierna y no debe filtrarse.

Y su método de uso también es muy sencillo:

  • Los datos cifrados por la clave privada pueden ser descifrados por la clave pública
  • Los datos cifrados por la clave pública pueden ser descifrados por la clave privada
  • La clave pública y la clave privada están en pares. No use sombreros en pares aleatorios.

En términos generales, el uso formal es: cifrado de clave pública y descifrado de clave privada.
Porque las escenas de negocios son todas claves públicas que vuelan por el cielo como pequeños anuncios en postes telefónicos, que cualquiera puede obtener. Entonces, ¿cree
que el proceso de "cifrado de clave privada y descifrado de clave pública" es una especie de escultura de arena? Junto con un proceso de interacción específico, puede sentirlo:

El navegador obtiene la clave pública del servidor. El 

navegador utiliza la clave pública para cifrar los datos "una flecha que perfora la nube" y luego los envía al servidor. El 

servidor recibe los datos "una flecha que perfora la nube", y luego lo descifra con la clave privada escondida en la entrepierna

En este proceso, dado que la persona que espía no tiene la clave privada, TA Mao no puede verla. Bueno, hasta ahora, parece que no hay problema, y ​​luego seguimos interactuando:

El servidor está listo para responder al navegador. Él usa la clave privada escondida en la entrepierna para encriptar el "Meeting a Thousand Soldiers", y luego lo regresa al navegador. El 

navegador usa la clave pública para descifrarlo.

Este proceso es más divertido. La clave pública es pública. Cualquiera puede desbloquear el "Encuentro de miles de ejércitos". Esto es demasiado ridículo ... De hecho, se mencionó al principio del artículo, cifrado asimétrico y descifrado. el uso es

"Cifrado de clave pública y descifrado de clave privada para cifrado y descifrado", "Cifrado de clave privada y descifrado de clave pública para firma digital y verificación digital"

¿Qué pasa si no nos importan los datos devueltos por el servidor al cliente en absoluto? Suponiendo que lo que el servidor devuelve al cliente está bien, el cifrado no tiene ningún significado.

¿Esta bien? Pero no, porque todavía hay una bomba de rey. Entre los muchos voyerismos, hay un tipo de voyeurismo que puede convertirse sin problemas en "el intermediario entre el cliente y el servidor" (aquí no se deje atrapar por los detalles de cómo convertirse en intermediario). En este momento, la comunicación entre el cliente y el servidor se convierte en tal

Este tipo de *** es el legendario "secuestro de intermediario" ***. Puede ver que los datos encriptados asimétricamente en este momento son puramente transparentes en el medio.

Frente al cliente, el intermediario es el servidor; frente al servidor, el intermediario es el cliente. Todas las cosas complicadas en el cliente y el servidor se eliminan.

Es una broma, así que obtuve GG

Instituciones y certificados de CA

Entonces vemos que en el esquema de cifrado y descifrado asimétrico, la raíz del problema está directamente en el primer paso
: la clave pública obtenida en sí es falsa. La pregunta ahora se centra en cómo asegurarse de que la "clave pública" de la primera comunicación no se falsifique . En este momento, ha surgido una organización bien establecida: CA, emitirán un certificado para su clave pública. El certificado informa a todos en el mundo que la clave pública está bien, comúnmente conocida como autoridad de certificación.

Qué significa esta institución, es decir: somos una institución objetiva, independiente y de terceros reconocida por humanos en todo el mundo. Nadie es más profesional en la gestión de certificados que nosotros, nadie entiende la gestión de certificados mejor que nosotros, y nosotros entender mejor que nadie Garantizar la autenticidad del certificado.

Por tanto, entre los tres protagonistas de los clientes anteriores, los intermediarios y los servidores, hay otro: las CAs. Ahora se ha convertido en una guerra a cuatro bandas, ¡un gran hombre! La escena fue muy caótica por un tiempo, y quedó como sigue. La arreglaré y la sentirás:

  • Clientela
  • Personas en el medio: clave pública falsa y clave privada falsa
  • Servidores: verdadera clave pública y verdadera clave privada
  • CA: clave pública de CA y clave privada de CA

Aquí el proceso se vuelve así

  1. El servidor A genera un par de su propia clave pública y clave privada, y luego envía la clave pública y su información básica a las CA. La información básica aquí es mi nombre, dónde vivo, número de teléfono, información del nombre de dominio, etc.

  2. Luego hay un proceso crucial, es decir, ¿cómo verifican las CA que la clave pública proviene del servidor A? En general, hay muchos métodos de autenticación involucrados aquí. Por
    ejemplo , cuando usamos letsencrypt, uno de los métodos de autenticación es probar a través de DNS, algunos incluso a través de la autenticación telefónica, e incluso a través de la autenticación cara a cara + ID. Hay una especial Estándar empresarial de autenticación CPS. Puede averiguar si está interesado. En definitiva, no es necesario limitarse a los detalles, podemos confiar incondicionalmente en que este proceso es 100% correcto. Este paso evita que las CA reciban claves públicas que no sean intermediarias y garantiza que deben recibir claves públicas de los servidores.

  3. Las propias CA también han generado un par de clave pública de CA y clave privada de CA. Las CA primero realizan un hash unidireccional de su clave pública (en realidad, un hash). El
    segundo paso es usar su par de claves privadas de CA. la forma en que el valor hash generado en el primer paso se firma digitalmente (recuerde el orden en este proceso, pero no necesita quedarse atascado en los detalles de la firma digital y el hash unidireccional aquí) para formar un certificado digital y entregárselo al servidor A (PS: CA en este proceso) Se cobrará solo arroz).
    El contenido del certificado digital incluye: el texto sin formato de la clave pública del servidor A, el valor del texto sin formato de la clave pública del servidor A después del hash unidireccional, el algoritmo específico del hash unidireccional y la firma digital de el valor hash de un solo elemento (reservado aquí) Una pregunta: ¿Qué pasa si el certificado digital obtenido por el servidor A está falsificado?)

  4. La clave pública de todas las CA del mundo se integrará en el sistema operativo del cliente A. Sí, no necesita preocuparse por ello. De todos modos, el fabricante de su sistema operativo ha organizado este proceso para usted, por lo que no Necesito quedar atrapado en los detalles aquí. ¡Este paso asegura que los clientes obtengan las claves públicas de CA y que no sean falsificadas por intermediarios!

  5. El cliente A inicia una solicitud al servidor A y el servidor A envía el certificado digital emitido por las CA al TA al cliente A. En este momento, ya sabemos que el cliente A ya tiene: las claves públicas de las CA, que se emiten al servidor A Certificado digital. Este paso no importa incluso si es un certificado digital falso enviado por una persona en el medio. Veamos primero el paso 6.

  6. Comience aquí con mucha energía, observe el proceso:
    primero, el cliente A obtiene el algoritmo específico de hash unidireccional del certificado digital y la clave pública y la firma digital del servidor A, y
    luego el cliente A usa las claves públicas de CA Realiza el descifrado "inverso" de la firma digital. Si el descifrado falla aquí, significa que hay un problema.
    Si el descifrado se realiza correctamente sin problemas, se obtendrá el valor hash de la clave pública del servidor A y también se conocerá el algoritmo hash, por lo que el cliente A utilizará el mismo algoritmo para aplicar hash a la clave pública del servidor A unidireccional , y luego se compara el valor hash unidireccional de la clave pública del servidor A en el certificado digital. Si no es el mismo, significa que la clave pública no es la clave pública del servidor A, lo que significa que hay un problema. Si el valor hash calculado por el cliente es el mismo que el valor hash en el certificado digital, significa que no hay ningún problema.
    Por supuesto, también incluirá la verificación del período de validez, etc. Deberías haber visto lo que sucede después de que caduca el certificado HTTPS, ¿verdad?

Volvamos a la pregunta retenida en el tercer paso: ¿Qué pasa si el certificado digital obtenido por el servidor A es falso? En realidad, este problema ya no existe, porque en el paso 6, cuando el cliente A utiliza la clave pública de la CA para descifrar la firma digital a la inversa, es el proceso de verificación de la autenticidad del certificado digital.

Después de pasar por los seis procesos anteriores, el problema al principio finalmente se resuelve: HTTPS garantiza al cliente que la clave pública es la clave pública del servidor, no la clave pública falsificada por los mirones. Así es como HTTPS resuelve el secuestro por el intermediario. Lo esencial.

Bueno, ahora que se puede garantizar que la clave pública está bien, significa que el cliente y el servidor pueden comunicarse, pero todavía tenemos un problema que no se ha resuelto: el cliente usa la clave pública del servidor para cifrar los datos y enviarlos. No hay problema en esta dirección, pero hay un problema con el cifrado en la dirección en que el servidor regresa al cliente, porque la clave privada del servidor está cifrada, ¡pero todos tienen la clave pública! ¿Cómo hacer?

Entonces, aquí, HTTPS usa las tecnologías de "acuerdo de clave" y "cifrado y descifrado simétrico" (no hay necesidad de quedarse atascado en los detalles del "acuerdo de clave"). Cifre y descifre la clave, y luego el cliente y el servidor usan esto clave para cifrar y descifrar los datos utilizando la tecnología de "cifrado y descifrado simétrico".

HTTPS resuelve tres problemas

  • Confidencialidad del mensaje: el mensaje en sí está encriptado.
  • Integridad del mensaje: el mensaje en sí no ha sido modificado por el intermediario
  • Confirmación del remitente del mensaje: el mensaje debe ir siempre entre el servidor y el cliente, y no hay un tercero intermediario para la transferencia.

Una entrevista principal: HTTPS: nadie conoce HTTPS mejor que yo

https final

Supongo que te gusta

Origin blog.51cto.com/huangkui/2677729
Recomendado
Clasificación