En el módulo anterior,
hemos visto acerca de la autenticación del usuario con mucho detalle.
Hemos visto cómo el usuario envía sus credenciales a su servidor desde el lado del cliente,
ya sea en el encabezado de
su mensaje de solicitud o en el cuerpo del mensaje de solicitud y luego,
cuando se autentican,
entonces su cliente incluirá la cookie o el
token en el encabezado del mensaje de solicitud que va del cliente al servidor.
Estoy seguro de que algunos de ustedes estaban preocupados por
el hecho de que nos estábamos comunicando en un canal inseguro,
lo que significa que cualquiera sentado en el medio que pueda
escuchar sus mensajes entre el cliente
y el servidor sería fácilmente capaz de capturar
las credenciales y luego hacerse pasar por el cliente genuino.
Por supuesto, en ese punto,
su énfasis estaba más en organizar la
comunicación del cliente y el servidor con la autenticación del cliente en el lado del servidor.
Pero cada vez que necesite usar
la autenticación del usuario, primero, en forma de, por ejemplo,
proporcionar las credenciales para autenticarse y, posteriormente,
autenticarse mediante la inclusión de la cookie o
el token en el encabezado del mensaje de solicitud,
debe hacer esto a través de un canal seguro.
Nunca debe comunicarse a través de un canal inseguro,
lo que significa que no debe usar HTTP y luego incluir
estas credenciales en el encabezado o el cuerpo de los mensajes de solicitud.
En su lugar, debería utilizar una versión segura del protocolo HTTP o HTTPS.
Vamos a hablar brevemente sobre HTTPS en esta conferencia.
En el camino, les daré una introducción de cinco minutos a la criptografía y la seguridad.
Obviamente, la criptografía y la seguridad es un tema muy importante por derecho propio.
Solo voy a presentarte a lo esencial que necesitas
entender para aprender cómo funciona HTTPS en realidad.
Con este fondo, vamos a proceder a entender acerca de la criptografía y luego
al protocolo HTTPS y cómo se configuraría un servidor para usar
el protocolo HTTPS y luego el cliente para ponerse en contacto con el servidor usando el protocolo HTTPS,
por lo tanto, la comunicación entre el cliente y el servidor puede ser se realiza de manera segura
mediante el cifrado de los datos que se envían entre el cliente y el servidor.
Cuando te aventuras en el campo de la criptografía y la seguridad,
a menudo oirás a la gente hablar de la criptografía de claves simétricas.
Ahora, ¿qué implica la criptografía?
Si necesita enviar un mensaje a través de un canal a otro usuario,
entonces querría poder cifrar el mensaje de
tal manera que solo el receptor pueda
descifrar el mensaje y obtener
la información que está tratando de enviar al receptor.
Así que tanto el remitente como el receptor deben entender en establecer entre
los dos cómo este proceso de cifrado y cómo va a funcionar el descifrado.
Para que esto funcione,
cualquier cifrado y descifrado funciona basado en el intercambio de claves secretas.
Por lo
tanto, en la criptografía de claves simétricas, tanto el remitente como el receptor compartirán una clave secreta entre los dos sitios,
y esta clave secreta es conocida solo por el remitente y el receptor.
Entonces, cuando el remitente necesita enviar el mensaje,
entonces el remitente cifrará este mensaje usando un algoritmo de criptografía,
que usa la clave secreta como la otra entrada a este algoritmo.
Y una vez que este mensaje se pasa a través de este algoritmo de criptografía,
entonces se generará un mensaje cifrado.
Ahora, este mensaje encriptado será enviado al canal a través del lado receptor.
Si tiene un usuario malicioso de terceros
sentado en el medio y escucha y captura este mensaje cifrado,
le resultaría difícil descifrar
este mensaje porque para descifrar un mensaje cifrado,
todavía necesita la clave secreta.
Ahora, en el lado receptor,
cuando se recibe el mensaje cifrado,
entonces el receptor se aplicará y un algoritmo de descifrado,
que también toma como entrada,
la misma clave secreta que se usó en el lado del remitente para cifrar el mensaje.
Por lo tanto, al descifrar, el mensaje original será recuperado
y puede ser procesado en el lado receptor.
Ahora, si un tercero malicioso quiere descifrar este mensaje cifrado,
se enfrentará a una batalla cuesta arriba porque
el proceso de cifrado usando la clave secreta girará el mensaje y, a
su vez, puede cifrar el mensaje.
Sin poseer la clave
secreta, será casi imposible descifrar el mensaje cifrado.
Bueno, eso es estiramiento llegar un poco lejos.
Sería excesivamente difícil descifrar el mensaje encriptado.
Si usa técnicas de fuerza bruta, eventualmente,
terminará descifrando el mensaje cifrado.
Pero va a tomar tanto tiempo y requerir mucha potencia de cálculo.
No valdrá la pena el esfuerzo para
que el usuario malicioso de terceros intente decodificar el mensaje cifrado.
Así que esencialmente estás haciendo que sea realmente difícil para alguien
descifrar el mensaje si no poseen la clave secreta.
Ahora, dado que la clave secreta es conocida sólo por el remitente y el receptor, las
dos partes finales, el remitente y el receptor,
pueden comunicarse con la seguridad de
que en el mensaje cifrado desde
el lado del remitente sólo puede ser descifrado por el lado receptor.
Así es como funciona la criptografía de claves simétricas.
El hecho de que tenga la misma clave secreta que se comparte entre
el remitente y el receptor significa que
la inclusión del proceso de descifrado utilizó la misma clave secreta,
por lo tanto, criptografía de clave simétrica.
Por supuesto, con la criptografía de clave simétrica,
uno de los problemas es que tanto el remitente como
el receptor necesitan tener acceso a la misma clave secreta.
Ahora, si el remitente y el receptor se están comunicando a través de un canal inseguro,
va a ser difícil para ambas partes llegar a un entendimiento
sobre la misma clave secreta sin revelarla a otros.
Así que aquí es donde otro algoritmo llamado criptografía de clave pública es muy útil.
¿ Cómo funciona la criptografía de clave pública?
Ahora, en criptografía de clave pública,
la idea es que tienes dos claves diferentes.
Tiene una clave pública y una clave privada.
Ahora, la clave pública se puede distribuir ampliamente a cualquier persona que desee.
Así que cuando alguien quiere enviarte un mensaje,
va a usar tu clave pública para cifrar el mensaje.
Por lo tanto, si un remitente aquí quiere enviar el mensaje al receptor,
entonces el remitente usará la clave pública del receptor para
cifrar el mensaje en el lado del remitente usando el algoritmo de cifrado.
Ahora, una vez que el mensaje cifrado se envía a
través del canal inseguro al lado
del receptor, el receptor utilizará la clave privada
que solo el receptor conoce para descifrar.
Ahora, para que la criptografía de clave pública funcione como vimos,
la clave pública se puede distribuir ampliamente sin ninguna preocupación.
Pero dado que la clave privada solo es conocida por el lado
del receptor, solo el receptor podrá descifrar el mensaje y, de
nuevo, a un intruso de terceros que capte
este mensaje cifrado le resultará excesivamente difícil descifrar el mensaje.
Ahora, por supuesto, en la criptografía de clave
pública, la clave pública y la privada son dos claves diferentes.
Ahora, entonces su siguiente pregunta obvia sería por qué
no simplemente usar criptografía de clave pública para el cifrado.
El problema es que usar la criptografía de clave pública
para el cifrado y el descifrado es un proceso costoso,
por lo que no usamos la criptografía de clave pública para toda su comunicación.
En cambio, la criptografía de clave pública se usará
principalmente para que el remitente y el receptor
acuerden la clave secreta común que ambos van a usar.
Más adelante veremos cómo se
puede utilizar la criptografía de clave pública para establecer la clave secreta común
entre el remitente y el receptor y luego
usar la criptografía de clave simétrica para una comunicación adicional.
Un protocolo que utiliza este enfoque es la
capa de sockets seguros y también los protocolos de seguridad de la capa de transporte,
SSL y TLS en resumen.
Muchas veces al leer documentación, es
posible que escuche hablar de SSL y TLS.
Estos protocolos criptográficos permiten una comunicación segura entre
el remitente y el receptor a través de una red insegura como Internet.
El remitente y el receptor se comunicarán a través de Internet utilizando mensajes cifrados,
que solo el remitente y el receptor pueden descifrar.
Y este enfoque, ya sea SSL o TLS,
utiliza una combinación de criptografía de clave pública junto con criptografía de clave simétrica.
Su proceso exacto de hacer esto,
lo explicaré en la siguiente diapositiva.
Además, usando SSL o TLS,
estamos tratando de mantener dos cosas diferentes.
En primer lugar, estamos tratando de mantener la privacidad de
la comunicación entre el remitente y el receptor para que
ningún tercero malintencionado pueda extraer el mensaje del mensaje cifrado.
En segundo lugar, también estamos tratando de mantener la integridad,
lo que significa que cuando el remitente envía un mensaje,
el receptor podrá estar seguro de que el mensaje no ha sido manipulado.
Así que tanto la seguridad como el mantenimiento de la integridad son muy importantes en este caso.
Así que tanto la privacidad como la integridad tienen que ser mantenidas por
este protocolo de comunicación seguro que construimos
para el intercambio entre el remitente y el receptor.
Vamos a hablar brevemente sobre cómo realmente funcionan SSL o TLS.
Esto se hace a través de un proceso de apretón de manos que he ilustrado en este diagrama aquí.
Cuando un cliente desea comunicarse con el servidor,
el cliente envía un mensaje al servidor,
especificando que el cliente desea comunicarse con el servidor de forma segura.
En este punto, el servidor devolverá el certificado al cliente,
que contiene una clave pública,
que ha sido certificada por
la entidad emisora de certificados como perteneciente a ese servidor en particular. De esta
manera, cuando el cliente reciba
esta clave pública más la certificación por parte de la entidad emisora de certificados,
el cliente podrá verificar las credenciales del servidor.
Por lo tanto, el cliente necesita establecer que realmente está hablando con el servidor,
con el que tiene la intención de comunicarse.
Entonces, en este punto,
cuando el cliente verifica las credenciales del servidor,
el cliente ahora tiene acceso a la clave pública del servidor.
Una vez que el cliente se apodera de la clave pública del servidor,
entonces el cliente generará lo que se denomina secreto pre-master.
Este secreto pre-master es algo que tanto el cliente
como el servidor usarán para generar lo que se denomina clave de sesión.
Por lo tanto, el cliente genera un secreto pre-master,
el cliente luego cifra ese secreto usando la clave pública del servidor
y luego envía el secreto al servidor.
Ahora, recuerde que una vez que el secreto se cifra usando la clave pública,
nadie más que el servidor podrá
extraer la información del mensaje cifrado.
Por lo tanto, cuando el servidor recibe este mensaje cifrado,
el servidor extrae el secreto pre-master de este mensaje.
Ahora, tanto el cliente como el servidor poseen el mismo secreto pre-master.
En este punto, tanto el cliente como el servidor usarán
el mismo conjunto de pasos comenzando con el secreto del pre-maestro,
y con el mismo conjunto de valores,
que generará una clave llamada como clave de sesión.
Ahora, cuando la clave de sesión se genera tanto en el lado de los clientes como en el lado del servidor,
será exactamente la misma clave de sesión,
porque ambas seguirán exactamente el mismo proceso para generar la clave de sesión.
Entonces, en este punto,
tanto el cliente como el servidor,
ahora poseen una clave secreta que es la misma en ambos sitios.
Por lo tanto, toda comunicación subsiguiente entre el servidor y el cliente,
puede continuar utilizando cifrado simétrico.
Por lo tanto, cuando el cliente necesita comunicarse con el servidor,
el cliente cifrará los datos usando la clave de sesión secreta
y luego enviará sus datos.
Del mismo modo, cuando el servidor necesita comunicarse con el cliente,
el servidor obviamente usará
la misma clave de sesión para cifrar los datos y luego enviarlos al cliente.
Ahora, dado que el cliente posee la misma clave de sesión,
el cliente podrá descifrar el mensaje y extraer el mensaje no cifrado.
Mediante este procedimiento,
el cliente y el servidor han asegurado que la comunicación entre ellos sea privada.
Además, nos las arreglamos para asegurarnos de que ningún tercero malintencionado pueda
interceptar el mensaje y provocar cambios en el mensaje.
Por lo tanto, la integridad del mensaje también se mantiene,
y la privacidad de la comunicación entre
el cliente y el servidor también se mantiene.
Por lo tanto, toda esta discusión que les he presentado en las últimas diapositivas,
es en pocas palabras,
cómo la comunicación segura entre el cliente y el servidor se puede garantizar
usando la criptografía de clave simétrica y la criptografía de clave pública.
Ahora, obviamente, hay mucho más en esto de lo que he explicado aquí,
pero esta comprensión de cómo funciona la criptografía es
suficiente para que entiendas cómo funciona todo el proceso.
Ahora, si usted está interesado en aprender más sobre esto,
una buena fuente para aprender acerca de los Protocolos de Criptografía es un muy buen libro de
Jim Crozon Keith Ross llamado Computer Networks.
Este libro tiene un capítulo muy fácil de entender
sobre criptografía y seguridad como se aplica a la comunicación de red.
Ahora que hemos establecido el proceso
para poder comunicarse de forma segura entre un cliente y un servidor,
veamos cómo el propio Internet aprovecha esto,
para la comunicación entre un cliente y el servidor usando HTTP.
Ahora, aquí es donde el protocolo HTTPS entra en la imagen.
Como usted ya entiende acerca de Internet,
Internet es una arquitectura en capas,
donde la IP y el TCP forman la red,
y la capa de transporte que se ejecuta en la parte superior de la red subyacente.
Ahora, encima de la capa de transporte,
tiene la capa de socket seguro o el forro de seguridad de la capa de transporte como
una capa delgada en la parte superior de TCP que
garantiza una comunicación segura entre el cliente y el servidor.
Y encima de esto HTTP puede ejecutarse.
Por lo tanto, HTTP implica esencialmente HTTP más el uso de cifrado,
descifrado soportado a través de SSL y TLS.
Obviamente, incluso para el protocolo HTTPS,
hay muchos más detalles.
Pero desde la perspectiva de la implementación del lado del servidor,
lo que hemos entendido aquí es suficiente para entender cómo
configurar un servidor para utilizar la comunicación segura entre el cliente y el servidor.
Ahora, por supuesto, la primera pregunta que se le ocurrirá es,
que el servidor necesita una clave pública y una clave privada.
Para una criptografía de clave pública,
¿cómo genera esto el servidor?
Si está ejecutando un servidor de producción real en
su entorno y proporciona servicio para que los usuarios accedan a su servidor,
entonces obviamente necesita pasar por el proceso de certificación.
Aquí es donde se acercará a una entidad emisora de certificados, por ejemplo,
corporaciones como VeriSign y Thawte Corporation
que son Autoridades Públicas de Certificación.
Hay algunos más en todo el mundo.
Por lo tanto, se acercará a ellos,
y estas Autoridades de Certificación entonces
autenticarán sus credenciales, se asegurarán de que usted es quien afirma ser,
y luego verificarán sus credenciales,
y luego en ese punto,
le emitirán una clave pública y una clave privada para su uso en el sitio del servidor.
Por lo tanto, una vez que emitan la clave
pública y la clave privada, la clave pública será certificada por la Autoridad de Certificación,
y luego la clave pública también llevará,
además, el certificado.
Por lo tanto, este es el certificado que enviará al sitio del cliente.
Dado que los clientes pueden establecer
la autenticidad de estas Autoridades de Certificación,
si mira cualquier navegador, notará que la mayoría de los navegadores tendrán
los certificados de todas estas Autoridades de Certificación establecidas
ya incorporados en ellos.
Por lo tanto, podrán establecer sus credenciales,
o mejor dicho, podrán establecer que la clave privada le pertenece,
obteniendo su certificado y luego comprobando o verificando
su certificado sabiendo que ha sido firmado por una
de estas certificaciones establecidas Autoridades.
Tras este proceso, el cliente podrá establecer su autenticidad.
Ahora, en este curso,
solo queremos entender cómo funciona cada HTTPS,
y también queremos tener una forma sencilla de
configurar el servidor con una clave pública y la clave privada.
Dado que estamos haciendo esto como un ejercicio para entender HTTPS,
podemos utilizar una herramienta llamada SSL abierta que ya está disponible en
nuestros equipos para generar lo que se denomina certificado autofirmado.
Las claves autofirmadas no son aceptables en el trabajo externo.
Pero como sabemos que lo estamos usando solo para nuestros fines de prueba,
podemos usar certificados autofirmados,
simplemente para entender el proceso
de comunicación segura entre el cliente y el servidor.
Entonces, ¿cómo usamos SSL abierto?
Hasta ahora usando SSL abierto puedes generar claves,
usando tres comandos que te muestro aquí.
Ejecuta estos tres comandos en esa secuencia,
como se especifica aquí y que le ayudará a generar
una clave privada y un certificado que puede poner a disposición desde
el servidor HTTPS para que los clientes descarguen y
así obtener su clave pública para una comunicación segura.
Así que esta es la operación que vamos a hacer en nuestro ejercicio que sigue
a esta conferencia para establecer y emitir el servicio DPS. Así que los tres pasos que hacemos es
, primero, generaremos la clave privada usando el primer comando.
Después de eso generaremos un cert.csr que luego será utilizado
para generar un certificado que
puede ser distribuido al lado del cliente por el tercer comando que se muestra allí.
Por lo tanto, estos pasos le permitirán generar una clave privada y
también un certificado correspondiente que se puede emitir al cliente.
Una vez más, para enfatizar, si está ejecutando un servidor de producción,
entonces necesita obtener una clave pública, un par de claves privadas,
de una de las Autoridades de Certificación como VeriSign y Thawte Corporation.
¿ Cómo funciona el nodo en sí mismo para ayudarnos a configurar el HTTPS?
Ahora es aquí donde estoy revisando brevemente el código que
usaremos en el ejercicio que sigue para configurar nuestros servidores. El
nodo en sí tiene el HTTPS como un módulo central dentro del nodo.
Por lo tanto, configuraremos HTTPS requiriendo este módulo central.
También usaremos el módulo principal del sistema de archivos porque
la clave privada y el certificado que generamos se almacenarán en nuestro lado del servidor,
y serán requeridos por
su aplicación express para configurar su servidor seguro.
Así que aquí vamos a utilizar el sistema de archivos con
el método ReadFileSync para leer en la clave privada
y el certificado de los archivos que
generamos utilizando los pasos que hemos visto en la ranura anterior.
Por lo tanto, una vez que estos dos valores estén listos,
se configuran las opciones para su servidor HTTPS y luego puede configurar
su servidor seguro para proporcionar comunicación basada en HTTPS desde el sitio del servidor.
Ahora que tiene una comprensión rápida de cómo funciona su HTTPS
y cómo aprovecha el uso de criptografía de clave pública
y criptografía de clave simétrica para
garantizar una comunicación segura entre el cliente y el servidor.
Pasemos al ejercicio para configurar realmente
nuestro servidor express que hemos estado construyendo hasta ahora para usar el protocolo HTTPS.