Capítulo 7. HTTPS para la seguridad web
HTTP tiene principalmente estas deficiencias, los ejemplos son los siguientes.
La comunicación utiliza texto plano (no cifrado) y el contenido puede ser escuchado a escondidas.
La identidad de la parte comunicante no está verificada, por lo que puede estar enmascarada.
No se puede probar la integridad del mensaje, por lo que puede haber sido manipulado.
Estos problemas no surgen sólo con HTTP, sino también con otros protocolos no cifrados. Además de eso, HTTP en sí tiene muchas desventajas. Además, existen deficiencias en la aplicación real de ciertos servidores web específicos y navegadores web específicos (también conocidas como vulnerabilidades o agujeros de seguridad), además, las aplicaciones web desarrolladas en lenguajes de programación como Java y PHP también pueden tener agujeros de seguridad. .
Si quiere preguntar por qué es una desventaja no cifrar la comunicación, es porque, según el mecanismo de funcionamiento de la familia de protocolos TCP/IP, el contenido de la comunicación se puede espiar en todas las líneas de comunicación. La llamada Internet está compuesta de redes que pueden conectarse a todo el mundo. No importa en qué parte del mundo se comunique el servidor con el cliente, algunos equipos de red, cables ópticos, computadoras, etc. en esta línea de comunicación no pueden ser propiedad personal, por lo que no se descarta que haya un comportamiento de espionaje malicioso en un determinado enlace. Incluso se pueden ver las comunicaciones cifradas, al igual que las comunicaciones no cifradas. Simplemente significa que si la comunicación está cifrada, puede resultar imposible para las personas descifrar el significado de la información del mensaje, pero la información del mensaje cifrado en sí se seguirá viendo.
Espiar las comunicaciones del mismo segmento no es difícil. Simplemente recopile los paquetes de datos (tramas) que fluyen por Internet. El análisis de los paquetes de datos recopilados se puede entregar a aquellas herramientas de captura de paquetes (Packet Capture) o sniffer (Sniffer).
Wireshark es una herramienta de captura de paquetes ampliamente utilizada. Puede obtener el contenido de la solicitud y respuesta del protocolo HTTP y analizarlo. Se pueden realizar una serie de cosas como enviar una solicitud utilizando el método GET, devolver una respuesta 200 OK y ver el contenido completo del mensaje de respuesta HTTP.
Procesamiento de cifrado para evitar escuchas ilegales
Entre las diversas contramedidas que todo el mundo está estudiando para evitar escuchas ilegales y proteger la información, la tecnología de codificación es la más popular. Puede haber varios objetos cifrados.
Cifrado de las comunicaciones Un método consiste en cifrar las comunicaciones. No existe un mecanismo de cifrado en el protocolo HTTP, pero se puede utilizar en combinación con SSL (Secure Socket Layer, Secure Socket Layer) o TLS (Transport Layer Security, Security Layer Transport Protocol) para cifrar el contenido de la comunicación HTTP.
Después de establecer una línea de comunicación segura con SSL, se puede realizar la comunicación HTTP en esta línea. HTTP utilizado en combinación con SSL se denomina HTTPS (HTTPSecure, Protocolo de seguridad de transferencia de hipertexto) o HTTP sobre SSL.
Cifrado de contenido
También existe una forma de cifrar el contenido mismo que interviene en la comunicación. Dado que no existe ningún mecanismo de cifrado en el protocolo HTTP, el contenido transmitido por el propio protocolo HTTP está cifrado. Es decir, el contenido del mensaje HTTP está cifrado. En este caso, el cliente debe cifrar el mensaje HTTP antes de enviar la solicitud.
De hecho, para lograr un cifrado de contenido eficaz, la premisa es que tanto el cliente como el servidor deben disponer de mecanismos de cifrado y descifrado. Utilizado principalmente en servicios web. Hay que tener en cuenta una cosa, ya que este método es diferente de SSL o TLS para cifrar toda la línea de comunicación, por lo que el contenido aún corre el riesgo de ser manipulado. Lo explicaremos más adelante.
La implementación del protocolo HTTP en sí es muy simple: no importa quién envíe la solicitud, devolverá una respuesta, por lo que si no se confirma la parte de la comunicación, existirán los siguientes peligros ocultos. No hay forma de determinar si el servidor web al que se envió la solicitud fue el que devolvió la respuesta como realmente se pretendía. Posiblemente un servidor web enmascarado. No hay forma de determinar si el cliente al que se devolvió la respuesta fue el que recibió la respuesta como realmente se pretendía. Posiblemente un cliente enmascarado. No se puede determinar si la otra parte a la que se comunica tiene derechos de acceso. Debido a que la información importante se guarda en algunos servidores web, sólo se desea el permiso para enviar a usuarios específicos a comunicarse.
Es imposible determinar de dónde y por quién provino la solicitud. Incluso se aceptan solicitudes sin sentido. Los ataques DoS (Denial of Service, ataques de denegación de servicio) bajo solicitudes masivas no se pueden prevenir.
Identificación del certificado del oponente
Si bien no es posible identificar a la parte comunicante utilizando el protocolo HTTP, sí es posible si se utiliza SSL. SSL no solo proporciona cifrado, sino que también utiliza un medio conocido como certificado que
puede usarse para identificar a una parte. Los certificados son emitidos por organizaciones de terceros confiables para demostrar que los servidores y los clientes realmente existen. Además, la falsificación de certificados es extremadamente difícil desde un punto de vista técnico. Por lo tanto, siempre que se pueda confirmar el certificado que posee la parte comunicante (servidor o cliente), se puede juzgar la verdadera intención de la parte comunicante.
Mediante el uso de un certificado, para demostrar que el comunicante es el servidor esperado. Esto también reduce el riesgo de filtración de información personal para el usuario individual. Además, el cliente puede completar la confirmación de su identidad personal manteniendo el certificado, y también puede utilizarlo en el proceso de autenticación del sitio Web.
La llamada integridad se refiere a la exactitud de la información. No demostrar su integridad generalmente significa que es imposible determinar si la información es exacta.
El contenido recibido puede ser incorrecto.
Dado que el protocolo HTTP no puede probar la integridad del mensaje de comunicación, no hay forma de que el contenido de la solicitud o respuesta sea manipulado durante el período posterior al envío de la solicitud o respuesta hasta su recepción. por la otra parte Aprendido. En otras palabras, no hay forma de estar seguro de que la solicitud/respuesta enviada y la solicitud/respuesta recibida sean las mismas en ambos sentidos.
Por ejemplo, al descargar contenido de un determinado sitio web, es imposible determinar si el archivo descargado por el cliente es coherente con el archivo almacenado en el servidor. Es posible que el contenido del archivo haya sido alterado con otro contenido durante la transmisión. Incluso si el contenido cambia, el cliente receptor no se dará cuenta. De esta manera, un ataque en el que la solicitud o respuesta es interceptada por un atacante y el contenido es manipulado durante la transmisión se denomina ataque Man-in-the-Middle (MITM).
Cómo evitar la manipulación
Aunque existe un método para determinar la integridad del mensaje utilizando el protocolo HTTP, de hecho no es conveniente ni confiable. Los métodos más utilizados son los métodos de verificación del valor hash, como MD5 y SHA-1, y los métodos de firma digital utilizados para confirmar archivos.
Los sitios web que brindan servicios de descarga de archivos también proporcionarán las correspondientes firmas digitales creadas con PGP (Pretty Good Privacy) y valores hash generados por algoritmos MD5. PGP es una firma digital que se utiliza para probar la creación de un archivo y MD5 es un valor hash generado por una función unidireccional. No importa qué método se utilice, el usuario que manipula el cliente debe verificar y verificar personalmente si el archivo descargado es el archivo en el servidor original. El navegador no puede buscar automáticamente al usuario. Desafortunadamente, con estos métodos, todavía es imposible garantizar que el resultado de la confirmación sea correcto. Debido a que PGP y MD5 están reescritos, el usuario no tiene forma de darse cuenta. Para prevenir eficazmente estas desventajas, es necesario utilizar HTTPS. SSL proporciona funciones de resumen y procesamiento de autenticación y cifrado. Es muy difícil garantizar la integridad solo con HTTP, por lo que se utiliza en combinación con otros protocolos para lograr este objetivo. En la siguiente sección presentamos el contenido relacionado de HTTPS.
Si utiliza texto plano sin cifrar durante la comunicación del protocolo HTTP, como al ingresar un número de tarjeta de crédito en una página web, si se intercepta la línea de comunicación, el número de la tarjeta de crédito quedará expuesto. Además, para HTTP, ya sea un servidor o un cliente, no hay forma de confirmar la parte de la comunicación. Porque es muy probable que en realidad no se esté comunicando con la parte de la comunicación esperada originalmente. Y también es necesario considerar la posibilidad de que el mensaje recibido haya sido manipulado durante la comunicación. Para resolver los problemas mencionados anteriormente de manera uniforme, es necesario agregar a HTTP mecanismos como el procesamiento de cifrado y la autenticación. A HTTP lo llamamos con mecanismos añadidos de cifrado y autenticación HTTPS (HTTP Secure).
La comunicación HTTPS se utiliza a menudo en páginas de inicio de sesión web, pantallas de pago de compras, etc. Cuando se comunique mediante HTTPS, utilice https:// en lugar de http://. Además, cuando un navegador accede a un sitio web donde la comunicación HTTPS está habilitada, aparecerá una marca de candado en la barra de direcciones del navegador. El método de visualización de HTTPS puede variar según el navegador.
HTTPS no es un protocolo nuevo en la capa de aplicación. Solo la parte de la interfaz de comunicación HTTP se reemplaza por los protocolos SSL (Secure Socket Layer) y TLS (Transport Layer Security). Normalmente, HTTP se comunica directamente con TCP. Cuando se utiliza SSL, evoluciona para comunicarse primero con SSL y luego con SSL y TCP. En resumen, el llamado HTTPS es en realidad HTTP envuelto en el caparazón del protocolo SSL.
Con la adopción de SSL, HTTP tiene las funciones de cifrado, certificados y protección de integridad de HTTPS. SSL es un protocolo independiente de HTTP, por lo que con el protocolo SSL se pueden utilizar no solo el protocolo HTTP, sino también otros protocolos como SMTP y Telnet que se ejecutan en la capa de aplicación. Se puede decir que SSL es la tecnología de seguridad de red más utilizada en el mundo en la actualidad.
Antes de explicar SSL, primero comprendamos el método de cifrado. SSL utiliza un método de cifrado llamado criptografía de clave pública. En los métodos de cifrado modernos, el algoritmo de cifrado es público, pero la clave se mantiene en secreto. De esta forma se mantiene la seguridad del método de cifrado. Tanto el cifrado como el descifrado utilizan claves. La contraseña no se puede descifrar sin la clave y, a la inversa, cualquiera que tenga la clave puede descifrarla. Si un atacante obtiene la clave, el cifrado no tiene sentido.
El dilema del cifrado de clave compartida
El método de utilizar la misma clave para cifrar y descifrar se denomina cifrado de clave compartida (sistema de cifrado de clave común), también conocido como cifrado de clave simétrica.
Al cifrar con una clave compartida, la clave también debe enviarse a la otra parte. ¿Cómo se puede entregar de forma segura? Cuando la clave se reenvía a través de Internet, si se intercepta la comunicación, la clave puede caer en manos del atacante y se pierde el significado del cifrado. Además, intente guardar la clave recibida de forma segura.
El cifrado de clave pública mediante dos claves
El cifrado de clave pública resuelve bien la dificultad del cifrado de clave compartida. El cifrado de clave pública utiliza un par de claves asimétricas. Una se llama clave privada y la otra se llama clave pública. Como su nombre lo indica, nadie más puede conocer la clave privada, mientras que la clave pública puede liberarse a voluntad y cualquiera puede obtenerla.
Al utilizar el método de cifrado de clave pública, la parte que envía el texto cifrado utiliza la clave pública de la otra parte para cifrar, y la otra parte utiliza su propia clave privada para descifrar la información cifrada después de recibirla. De esta manera, no es necesario enviar la clave privada utilizada para el descifrado y no hay necesidad de preocuparse de que un atacante pueda espiar y robar la clave. Además, es muy difícil restaurar el texto original de la información basándose en el texto cifrado y la clave pública, porque el proceso de descifrado consiste en evaluar el logaritmo discreto, lo cual no es fácil de hacer. Dando un paso atrás, si se puede factorizar rápidamente un número entero muy grande, entonces todavía hay esperanzas de descifrar la contraseña. Pero esto no es realista con la tecnología actual.
HTTPS utiliza un mecanismo de cifrado híbrido
HTTPS utiliza un mecanismo de cifrado híbrido que utiliza tanto cifrado de clave compartida como cifrado de clave pública. Si las claves se pueden intercambiar de forma segura, es posible considerar la comunicación utilizando únicamente cifrado de clave pública. Sin embargo, el cifrado de clave pública es más lento de procesar que el cifrado de clave compartida. Por lo tanto, debemos aprovechar al máximo sus respectivas ventajas y combinar múltiples métodos de comunicación. El método de cifrado de clave pública se utiliza en el enlace de intercambio de claves y el método de cifrado de clave compartida se utiliza en la fase posterior de establecimiento de comunicación e intercambio de mensajes.
Desafortunadamente, todavía existen algunos problemas con el cifrado de clave pública. Es decir, es imposible demostrar que la clave pública en sí es una clave pública genuina. Por ejemplo, cuando se prepara para establecer comunicación bajo cifrado de clave pública con un determinado servidor, cómo demostrar que la clave pública recibida es la clave pública emitida por el servidor originalmente esperado. Quizás durante la transmisión de la clave pública, la clave pública real haya sido reemplazada por un atacante. Para resolver los problemas anteriores, se pueden utilizar certificados de clave pública emitidos por autoridades de certificación de certificados digitales (CA, Autoridad de certificación) y agencias relacionadas. La autoridad de certificación de certificados digitales está en la posición de un tercero de confianza tanto para el cliente como para el servidor. Verisign (VeriSign) es una de las agencias de certificación de certificados digitales más conocidas. Presentemos el proceso comercial de la autoridad de certificación de certificados digitales. En primer lugar, el operador del servidor solicita una clave pública a la autoridad de certificación de certificados digitales. Después de identificar la identidad del solicitante, la autoridad de certificación de certificados digitales firmará digitalmente la clave pública aplicada, luego distribuirá la clave pública firmada, colocará la clave pública en el certificado de clave pública y la vinculará a Together. El servidor enviará este certificado de clave pública emitido por la autoridad de certificación de certificados digitales al cliente para una comunicación cifrada con clave pública. Los certificados de clave pública también pueden denominarse certificados digitales o directamente certificados. El cliente que recibe el certificado puede utilizar la clave pública de la autoridad certificadora de certificados digitales para verificar la firma digital de ese certificado, una vez superada la verificación el cliente puede confirmar dos cosas: 1. Es una autoridad certificadora de certificados digitales real y efectiva. . En segundo lugar, la clave pública del servidor es confiable. Aquí la clave pública de la autoridad de certificación debe transferirse de forma segura al cliente. Cuando se utiliza el método de comunicación, cómo transferirlo de forma segura es algo muy difícil, por lo que cuando la mayoría de los desarrolladores de navegadores lanzan una versión, incorporarán de antemano la clave pública de la autoridad de certificación de uso común.
Una función del certificado es demostrar si el servidor como parte de la comunicación está estandarizado y la otra función es confirmar si la empresa que opera detrás del servidor de la otra parte realmente existe. El certificado con esta característica es el certificado EV SSL (Extended Validation SSLCertificate). Los certificados EV SSL se emiten según las pautas de certificación estándar internacionales. Estipula estrictamente la política de verificación de la autenticidad de la entidad operativa, para que el sitio web certificado pueda obtener un mayor grado de reconocimiento. El color de fondo de la barra de direcciones del navegador del sitio web que posee el certificado EV SSL es verde, lo que se puede distinguir visualmente de un vistazo. Además, en el lado izquierdo de la barra de direcciones, se muestran el nombre de la organización registrada en el certificado SSL y el nombre de la autoridad certificadora que emitió el certificado.
La intención original del mecanismo anterior es evitar que los usuarios sean atacados por phishing (Phishing), pero todavía hay un signo de interrogación en términos de efecto. Es posible que muchos usuarios no conozcan el certificado EV SSL, por lo que no le prestan mucha atención.
Los certificados de cliente también están disponibles en HTTPS. La autenticación del cliente con certificados de cliente demuestra que el servidor siempre se está comunicando con el cliente esperado y su función es exactamente la misma que la de los certificados de servidor. Sin embargo, los certificados de cliente todavía tienen varios problemas. Uno de los puntos problemáticos es la adquisición y emisión de certificados. Para obtener un certificado, el usuario debe instalar él mismo el certificado del cliente. Sin embargo, dado que el certificado de cliente se compra por una tarifa y cada certificado corresponde a cada usuario, significa que se debe pagar una tarifa igual al número de usuarios. Además, permitir que usuarios con diferentes niveles de conocimiento instalen certificados por sí mismos está lleno de desafíos. El status quo es que las autoridades certificadoras altamente seguras pueden emitir certificados de clientes, pero sólo para negocios con fines especiales. Por ejemplo, aquellos servicios que puedan soportar el pago de certificados de clientes. Por ejemplo, la banca en línea de un banco utiliza certificados de cliente. Al iniciar sesión en la banca en línea, no solo se requiere que el usuario confirme la entrada de ID y contraseña, sino que también se requiere el certificado de cliente del usuario para confirmar si el usuario accede a la banca en línea desde una terminal específica.
Otro problema con el certificado de cliente es que, después de todo, el certificado de cliente solo se puede utilizar para probar la existencia real del cliente, pero no para probar la autenticidad del propio usuario. Es decir, siempre que tenga derecho a utilizar la computadora con el certificado de cliente instalado, significa que tiene derecho a utilizar el certificado de cliente al mismo tiempo.
La razón por la cual es viable intervenir la autoridad certificadora en el mecanismo SSL es porque se parte de la premisa de que su crédito es absolutamente confiable. Sin embargo, en julio de 2011, una autoridad de certificación de los Países Bajos llamada DigiNotar fue pirateada ilegalmente y emitió certificados falsos para sitios web como google.com y twitter.com. Este incidente sacude fundamentalmente la credibilidad de SSL. Debido a que el certificado falso tiene una firma digital de una autoridad de certificación formal, el navegador determinará que el certificado es legítimo. Cuando se utiliza un certificado falso como disfraz de servidor, el usuario no puede detectarlo en absoluto. Aunque existe un mecanismo de lista de revocación de certificados (Lista de revocación de certificados, CRL) que puede invalidar el certificado y una contramedida para eliminar la Autoridad de certificación raíz (Autoridad de certificación raíz, RCA) del cliente, pasará algún tiempo antes de que entre en vigencia. , y en este período No se sabe cuántos intereses de los usuarios sufrirán pérdidas dentro de un determinado período de tiempo.
Si utiliza el programa de código abierto OpenSSL, todos pueden crear su propia autoridad de certificación para emitir certificados de servidor por sí mismos. Pero ese certificado de servidor no está disponible como certificado en Internet y no parece ayudar. Una autoridad de certificación creada de forma independiente se denomina autoridad de autocertificación, y un certificado "inútil" emitido por una autoridad de autocertificación también se denomina en broma certificado autofirmado. Cuando un navegador accede al servidor, muestra mensajes de advertencia como "No se pudo confirmar la seguridad de la conexión" o "Hay un problema con el certificado de seguridad de este sitio web".
Un certificado de servidor emitido por una autoridad de autocertificación no funciona porque no elimina la posibilidad de enmascaramiento. El efecto que puede producir una agencia de autocertificación es, como máximo, el grado en que declara "Yo soy ○○" al mundo exterior. Incluso si se utiliza un certificado autofirmado, después del cifrado SSL, es posible que ocasionalmente vea un mensaje indicando que la comunicación se encuentra en un estado seguro, pero eso también es problemático. Porque aunque la comunicación esté cifrada no se puede descartar que se esté manteniendo comunicación con un servidor falso que ha sido disfrazado. Sólo cuando una tercera organización de confianza interviene en la certificación se puede utilizar la clave pública emitida por la autoridad de certificación implantada en el navegador para demostrar la autenticidad del servidor. Los certificados de CA intermedia pueden volverse autocertificados. Los certificados de CA confiables están preinstalados en la mayoría de los navegadores, pero los certificados de CA intermedia también están preinstalados en una pequeña cantidad de navegadores. Para el certificado de servidor emitido por la autoridad de certificación intermedia, algunos navegadores lo tratarán como un certificado formal y otros lo tratarán como un certificado autofirmado.
Para comprender mejor HTTPS, observemos los pasos de comunicación de HTTPS.
Paso 1: El cliente inicia la comunicación SSL enviando un mensaje de saludo del cliente. El mensaje contiene la versión especificada de SSL admitida por el cliente y la lista de Cipher Suite (algoritmo de cifrado utilizado, longitud de la clave, etc.).
Paso 2: Cuando el servidor pueda realizar comunicación SSL, responderá con un mensaje de saludo del servidor. Al igual que el cliente, la versión SSL y los componentes de cifrado se incluyen en el mensaje. El contenido del componente cifrado del servidor se filtra del componente cifrado del cliente recibido.
Paso 3: Luego, el servidor envía un mensaje de Certificado. El mensaje contiene el certificado de clave pública.
Paso 4: Finalmente, el servidor envía un mensaje Server Hello Done para notificar al cliente y la fase inicial de la negociación del protocolo de enlace SSL finaliza.
Paso 5: Una vez finalizado el primer protocolo de enlace SSL, el cliente responde con un mensaje de Intercambio de claves de cliente. El mensaje contiene una cadena de contraseña aleatoria llamada Pre-mastersecret que se utiliza en el cifrado de comunicaciones. Este mensaje ha sido cifrado con la clave pública del paso 3.
Paso 6: Luego, el cliente continúa enviando el mensaje Cambiar especificación de cifrado. Este mensaje avisará al servidor y la comunicación posterior a este mensaje se cifrará con la clave secreta previa al maestro.
Paso 7: el cliente envía un mensaje Finalizado. Este mensaje contiene el valor de verificación general de todos los mensajes conectados hasta el momento. El éxito de esta negociación de protocolo de enlace depende de si el servidor puede descifrar correctamente el mensaje como criterio.
Paso 8: El servidor también envía un mensaje Cambiar especificación de cifrado.
Paso 9: El servidor también envía un mensaje Finalizado.
Paso 10: Una vez finalizado el intercambio de mensajes entre el servidor y el cliente, se establece la conexión SSL. Por supuesto, la comunicación estará protegida por SSL. A partir de aquí se inicia la comunicación del protocolo de capa de aplicación, es decir, se envía la solicitud HTTP.
Paso 11: comunicación del protocolo de capa de aplicación, es decir, envío de respuesta HTTP.
Paso 12: Finalmente desconectado por el cliente. Al desconectarse, envíe el mensaje close_notify. Se han realizado algunas omisiones en la figura anterior. Después de este paso, se envía un mensaje TCP FIN para cerrar la comunicación con TCP.
En el proceso anterior, cuando la capa de aplicación envía datos, se adjuntará un resumen de mensaje llamado MAC (Código de autenticación de mensaje). MAC puede detectar si el mensaje ha sido manipulado, protegiendo así la integridad del mensaje.
HTTPS utiliza dos protocolos, SSL (Secure Socket Layer) y TLS (Transport Layer Security). La tecnología SSL fue defendida por primera vez por el desarrollador de navegadores Netscape Communications Corporation y ha desarrollado versiones anteriores a SSL3.0. En la actualidad, el dominio ha pasado a manos del IETF (InternetEngineering Task Force, Internet Engineering Task Force). El IETF toma SSL3.0 como punto de referencia y luego desarrolló TLS1.0, TLS1.1 y TLS1.2. TSL es un protocolo desarrollado sobre la base de SSL, que a veces se denomina colectivamente SSL. Las versiones principales actuales son SSL3.0 y TLS1.0. Dado que se descubrió que el protocolo SSL1.0 tenía problemas al comienzo de su diseño, en realidad no se puso en uso. También se descubrió que SSL2.0 era problemático, por lo que muchos navegadores abolieron directamente esta versión del protocolo.
HTTPS también tiene algunos problemas, es decir, cuando se usa SSL, su velocidad de procesamiento será más lenta.
Hay dos tipos de SSL lento. Uno se refiere a la comunicación lenta. La otra es que la velocidad de procesamiento se ralentiza debido al consumo masivo de recursos como CPU y memoria. La carga de la red puede ser de 2 a 100 veces más lenta que usando HTTP. Además de conectarse con TCP y enviar solicitudes y respuestas HTTP, se debe realizar comunicación SSL, por lo que el tráfico de procesamiento general aumentará inevitablemente. Otro punto es que SSL debe estar cifrado. Tanto el servidor como el cliente deben realizar operaciones de cifrado y descifrado. Por lo tanto, como resultado, consumirá más recursos de hardware del servidor y del cliente que HTTP, lo que generará una mayor carga. No existe una solución fundamental para la desaceleración; utilizamos hardware (servidor dedicado), como aceleradores SSL, para mejorar el problema. El hardware está dedicado a la comunicación SSL y, en comparación con el software, puede aumentar varias veces la velocidad informática de SSL. Utilice el acelerador SSL solo para el procesamiento SSL para compartir la carga. ¿Por qué no usar siempre HTTPS? Dado que HTTPS es tan seguro y confiable, ¿por qué no todos los sitios web usan HTTPS todo el tiempo? Una de las razones de esto es que la comunicación cifrada consume más recursos de CPU y memoria que la comunicación de texto sin formato. Si cada comunicación está cifrada, consumirá muchos recursos y, cuando se difunde en una computadora, la cantidad de solicitudes que se pueden procesar definitivamente disminuirá en consecuencia.
Por lo tanto, la comunicación HTTP se utiliza para información no confidencial y la comunicación cifrada HTTPS se utiliza solo cuando se incluyen datos confidenciales, como información personal. Especialmente cuando esos sitios web muy visitados están cifrados, no se puede subestimar la carga que soportan. Al cifrar, no se cifra todo el contenido, sino sólo cuando se requiere ocultar información, para ahorrar recursos.
Además, una de las razones es ahorrar el coste de la compra de certificados. Se requieren certificados para la comunicación HTTPS. El certificado utilizado debe adquirirse de una autoridad de certificación (CA). Los precios de los certificados pueden variar ligeramente según el organismo de certificación. Por lo general, una autorización de un año requiere decenas de miles de yenes (ahora 10.000 yenes equivalen a unos 600 RMB). Aquellos servicios y algunos sitios web personales que no son rentables para comprar certificados solo pueden optar por utilizar HTTP como método de comunicación.
Capítulo 8 Autenticación para confirmar la identidad de los usuarios que acceden
Ciertas páginas web sólo quieren ser navegadas por personas específicas, o simplemente sólo quieren ser visibles para la propia persona. Para lograr este objetivo, la función de autenticación es indispensable. Aprendamos juntos sobre el mecanismo de autenticación.
El ordenador por sí solo no puede determinar la identidad del usuario sentado frente al monitor. Además, es imposible confirmar quién está al otro lado de la red. Se puede ver que para saber quién accede al servidor, el cliente de la otra parte debe informarse. Sin embargo, incluso si la otra parte que accede al servidor afirma ser ueno, es imposible hablar sobre si la identidad es verdadera. Para confirmar si el propio ueno realmente tiene la autoridad para acceder al sistema, es necesario comprobar "la información que sólo conoce el propio solicitante de registro" y la "información que sólo está disponible para el propio solicitante de registro"
. La información verificada generalmente se refiere a lo siguiente.
Contraseña: Una cadena de información que sólo tú conocerás.
Token dinámico: solo la contraseña de un solo uso que se muestra en el dispositivo que posee la persona.
Certificado digital: Información en poder únicamente de la persona (terminal).
Autenticación biométrica: información biométrica como huellas dactilares e iris.
Tarjeta IC, etc.: Sólo información en poder de la propia persona.
Sin embargo, incluso si la otra parte es un usuario falso, siempre que pueda pasar la verificación del usuario, la computadora adoptará de forma predeterminada el comportamiento del usuario. Por lo tanto, la contraseña para controlar la información confidencial nunca debe ser obtenida por otros, y mucho menos descifrada fácilmente.
Métodos de autenticación utilizados por HTTP
Los métodos de autenticación utilizados por HTTP/1.1 son los siguientes.
Autenticación BÁSICA (autenticación básica)
Autenticación DIGEST (autenticación resumida)
Autenticación de cliente SSL
Autenticación FormBase (autenticación basada en formularios)
Además, existe la autenticación unificada de Windows (autenticación Keberos, autenticación NTLM), pero este libro no la explicará.
La autenticación BÁSICA (autenticación básica) es un método de autenticación definido desde HTTP/1.0. Incluso ahora, algunos sitios web todavía utilizan este método de autenticación. Es un método de autenticación entre el servidor web y el cliente de comunicación. Pasos de autenticación de la autenticación BÁSICA
Paso 1: Cuando el recurso solicitado requiere autenticación BÁSICA, el servidor devolverá una respuesta con el campo de encabezado WWW-Authenticate junto con el código de estado 401Autorización requerida. Este campo contiene el método de autenticación (BÁSICO) y la cadena de dominio de seguridad Request-URI (reino).
Paso 2: El cliente que recibe el código de estado 401 debe enviar la identificación de usuario y la contraseña al servidor para poder pasar la autenticación BÁSICA. El contenido de la cadena enviada se compone de ID de usuario y contraseña, que se conectan mediante dos puntos (:) y luego se procesan mediante codificación Base64. Suponiendo que el ID de usuario es invitado y la contraseña es invitado, la concatenación formará una cadena como invitado:invitado. Luego, después de la codificación Base64, el resultado final es Z3Vlc3Q6Z3Vlc3Q=. Después de escribir esta cadena en el campo del encabezado Autorización, envíe la solicitud. Cuando el agente de usuario es un navegador, el usuario solo necesita ingresar el ID de usuario y la contraseña, y luego el navegador completará automáticamente la conversión a la codificación Base64.
Paso 3: Después de recibir la solicitud, incluido el campo de encabezado Autorización, el servidor verificará la exactitud de la información de autenticación. Si se pasa la verificación, se devuelve una respuesta que contiene el recurso Request-URI. Aunque la autenticación BÁSICA adopta el método de codificación Base64, no está cifrada. No requiere ninguna información adicional para decodificarlo. En otras palabras, dado que el texto plano se decodifica para ser el ID de usuario y la contraseña, durante el proceso de autenticación BÁSICA en líneas de comunicación no cifradas como HTTP, si alguien escucha a escondidas, la posibilidad de ser robado es extremadamente alta. Además, cuando desea volver a realizar la autenticación BÁSICA, los navegadores generales no pueden implementar la operación de cierre de sesión de autenticación, lo que también es uno de los problemas. La autenticación BÁSICA no es lo suficientemente conveniente y flexible de usar y no cumple con el nivel de seguridad esperado por la mayoría de los sitios web, por lo que no se usa comúnmente.
Para compensar la debilidad de la autenticación BÁSICA, existe la autenticación DIGEST desde HTTP/1.1. La autenticación DIGEST también utiliza el método de desafío/respuesta (desafío/respuesta), pero no envía contraseñas de texto sin formato directamente como la autenticación BÁSICA. El llamado método de desafío-respuesta significa que una parte primero enviará una solicitud de autenticación a la otra parte y luego utilizará el código de desafío recibido de la otra parte para calcular y generar un código de respuesta. Finalmente, devuelva el código de respuesta a la otra parte para su autenticación. Debido a que lo que se envía a la otra parte es solo el resumen de la respuesta y el resultado del cálculo generado por el código de desafío, en comparación con la autenticación BÁSICA, la posibilidad de fuga de contraseña se reduce. Pasos de certificación para la certificación DIGEST
Paso 1: Al solicitar un recurso que requiere autenticación, el servidor devolverá una respuesta con el campo de encabezado WWW-Authenticate junto con el código de estado 401 Autorización requerida. Este campo contiene el código de desafío temporal (número aleatorio, nonce) requerido para la autenticación de desafío-respuesta. El primer campo WWW-Authenticate debe contener la información de dominio y nonce. El cliente se autentica enviando estos dos valores al servidor. El nonce es una cadena aleatoria arbitraria que se genera cada vez que se devuelve una respuesta 401. Generalmente se recomienda que la cadena esté compuesta por números hexadecimales codificados en Base64, pero el contenido real depende de la implementación específica del servidor.
Paso 2: El cliente que recibe el código de estado 401 devuelve una respuesta que incluye el campo de encabezado Información de autorización que es necesaria para la autenticación DIGEST. El campo de encabezado Autorización debe contener información de campo de nombre de usuario, dominio, nonce, uri y respuesta. Entre ellos, domain y nonce son los campos de la respuesta recibida anteriormente del servidor. nombre de usuario es el nombre de usuario que se puede autenticar dentro del rango limitado del ámbito. uri (digest-uri) es el valor de Request-URI, pero considerando que el valor de Request-URI puede modificarse después de ser reenviado por el proxy, se copiará y guardará una copia en uri con anticipación. La respuesta también se puede llamar Request-Digest, que almacena la cadena de contraseña después de la operación MD5 para formar un código de respuesta. Para otras entidades en la respuesta, consulte el campo del encabezado de la solicitud Autorización en el Capítulo 6. Además, las reglas de cálculo relacionadas con Request-Digest son más complicadas y es posible que los lectores interesados deseen estudiar RFC2617 en profundidad.
Paso 3: El servidor que recibe la solicitud, incluido el campo de encabezado Autorización, confirmará la exactitud de la información de autenticación. Después de pasar la autenticación, se devuelve una respuesta que contiene el recurso Request-URI. Y en este momento, se escribirá información relevante sobre la autenticación exitosa en el campo del encabezado Información de autenticación. La autenticación DIGEST proporciona un mayor nivel de seguridad que la autenticación BÁSICA, pero sigue siendo débil en comparación con la autenticación del cliente HTTPS. La autenticación DIGEST proporciona un mecanismo de protección contra la escucha de contraseñas, pero no existe ningún mecanismo de protección contra el enmascaramiento de usuarios. La certificación DIGEST, al igual que la certificación BASIC, no es tan conveniente y flexible de usar, y aún no alcanza el alto nivel de seguridad que buscan la mayoría de los sitios web. Por tanto, su ámbito de aplicación también es limitado.
Desde la perspectiva del método de autenticación mediante el ID de usuario y la contraseña, siempre que el contenido de ambos sea correcto, es el acto de la persona el que puede autenticarse. Pero si se roban los ID de usuario y las contraseñas, es muy probable que un tercero pueda suplantarlos. El uso de la autenticación de cliente SSL puede evitar esta situación. La autenticación de cliente SSL es una forma de completar la autenticación mediante certificados de cliente HTTPS. Con la autenticación del certificado de cliente (explicada en el capítulo HTTPS), el servidor puede confirmar si el acceso proviene de un cliente que ha iniciado sesión.
8.4.1 Pasos de autenticación de la autenticación de cliente SSL
Para lograr el propósito de la autenticación de cliente SSL, el certificado del cliente debe distribuirse al cliente con anticipación y el cliente debe instalar este certificado.
Paso 1: Después de recibir una solicitud para autenticar recursos, el servidor enviará un mensaje CertificateRequest, solicitando al cliente que proporcione un certificado de cliente.
Paso 2: Después de que el usuario seleccione el certificado de cliente que se enviará, el cliente enviará la información del certificado de cliente al servidor en forma de mensaje de Certificado de cliente.
Paso 3: después de que el servidor verifica el certificado del cliente, puede recibir la clave pública del cliente en el certificado y luego iniciar la comunicación cifrada HTTPS.
En la mayoría de los casos, la autenticación de cliente SSL no depende únicamente de certificados para completar la autenticación y generalmente se usa en combinación con la autenticación basada en formularios (que se explica más adelante) para formar una autenticación de dos factores (autenticación de dos factores). La llamada autenticación de dos factores se refiere a un método de autenticación que no solo requiere la contraseña como un factor en el proceso de autenticación, sino que también requiere que el solicitante proporcione otra información que posee como otro factor, que se utiliza en combinación con él. En otras palabras, el certificado de cliente SSL del primer factor de autenticación se utiliza para autenticar la computadora cliente y la contraseña del segundo factor de autenticación se utiliza para confirmar que es el propio usuario. Después de pasar la autenticación de dos factores, se puede confirmar que el propio usuario está utilizando la computadora correcta para acceder al servidor.
Tarifas necesarias para la autenticación de cliente SSL
Se requiere un certificado de cliente para utilizar la autenticación de cliente SSL. El certificado de cliente debe pagar una determinada tarifa para poder utilizarlo. El costo mencionado aquí se refiere al costo de comprar el certificado del cliente a la autoridad de certificación y al costo incurrido por el operador del servidor para garantizar el funcionamiento seguro de la autoridad de certificación creada por él mismo. El costo de emisión de certificados de cliente por parte de cada autoridad de certificación es diferente, y el costo anual es de decenas de miles a cientos de miles de yenes cuando se asigna equitativamente a un certificado. Los operadores de servidores también pueden crear sus propios organismos de certificación
, pero incurrirán en los costos correspondientes para mantener operaciones seguras.
Los métodos de autenticación basados en formularios no están definidos en el protocolo HTTP. El cliente enviará la información de inicio de sesión (Credencial) a la aplicación web en el servidor y se autenticará de acuerdo con el resultado de la verificación de la información de inicio de sesión. Dependiendo de la instalación real de la aplicación web, la interfaz de usuario y el método de autenticación proporcionados también son diferentes. En la mayoría de los casos, después de ingresar la información de inicio de sesión, como la identificación de usuario (generalmente una cadena de caracteres arbitraria o una dirección de correo electrónico) y la contraseña que inició sesión previamente, se envía a la aplicación web y, según el resultado de la autenticación, se determina si la autenticación es exitosa.
Debido a la conveniencia de uso y problemas de seguridad, la autenticación BÁSICA y la autenticación DIGEST proporcionadas por el estándar del protocolo HTTP apenas se utilizan. Además, aunque la autenticación de cliente SSL tiene un alto nivel de seguridad, aún no se ha utilizado ampliamente debido a problemas como los costos de introducción y mantenimiento. Por ejemplo, para los protocolos SSH y FTP, la autenticación entre el servidor y el cliente cumple con la especificación estándar y cumple con los requisitos funcionales más básicos del nivel de uso de seguridad, por lo que la autenticación de estos protocolos se puede utilizar directamente. Pero para la función de autenticación del sitio web, no existe una especificación estándar que pueda satisfacer su nivel de uso de seguridad, por lo que se debe utilizar el método de autenticación basado en formularios implementado por cada aplicación web. La autenticación de formularios, que no tiene una especificación estándar común, se implementará de manera diferente en cada sitio web. Si se trata de una autenticación de formulario implementada teniendo plenamente en cuenta el rendimiento de la seguridad, puede tener un alto nivel de seguridad. Sin embargo, no es raro ver sitios web que tienen problemas en la implementación de la autenticación de formularios.
La especificación estándar basada en la autenticación de formularios aún no se ha finalizado y las cookies se utilizan generalmente para administrar la sesión. La autenticación basada en formularios en sí se autentica haciendo coincidir el ID de usuario y la contraseña enviados por el cliente con la información de inicio de sesión anterior a través de la aplicación web del lado del servidor. Sin embargo, dado que HTTP es un protocolo sin estado, el estado de los usuarios previamente autenticados no se puede guardar en el nivel del protocolo. Es decir, la gestión del estado no se puede realizar, por lo que incluso cuando el usuario continúe accediendo la próxima vez, no se le podrá distinguir de otros usuarios. Por lo tanto, usaremos cookies para administrar la sesión y compensar la función de administración de estado que no existe en el protocolo HTTP.
Paso 1: el cliente coloca la información de inicio de sesión, como el ID de usuario y la contraseña, en la parte de entidad del mensaje y, por lo general, envía la solicitud al servidor mediante el método POST. En este caso, la comunicación HTTPS se utiliza para mostrar la pantalla del formulario HTML y transmitir datos de entrada del usuario.
Paso 2: El servidor emitirá un ID de sesión para identificar al usuario. La autenticación se realiza verificando la información de inicio de sesión enviada desde el cliente y luego el estado de autenticación del usuario se vincula al ID de sesión y se registra en el servidor. Al devolver una respuesta al cliente, el ID de sesión (por ejemplo, PHPSESSID=028a8c...) se escribirá en el campo del encabezado Set-Cookie. Puede considerar el ID de sesión como un número equivalente que se utiliza para distinguir a diferentes usuarios. Sin embargo, si un tercero roba el ID de sesión, la otra parte puede hacerse pasar por su identidad para realizar operaciones maliciosas. Por lo tanto, se debe evitar que el ID de sesión sea robado o adivinado. Para lograr esto, el ID de sesión debe usar una cadena impredecible y el servidor también necesita administrar el período de validez para garantizar su seguridad. Además, para reducir las pérdidas causadas por los ataques de secuencias de comandos entre sitios (XSS), se recomienda agregar el atributo httponly a la cookie con anticipación.
Paso 3: Después de que el cliente reciba el ID de sesión enviado desde el servidor, lo guardará localmente como una cookie. La próxima vez que se envíe una solicitud al servidor, el navegador enviará automáticamente la cookie, por lo que el ID de sesión también se enviará al servidor. El servidor puede identificar al usuario y su estado de autenticación verificando el ID de sesión recibido. Además de los ejemplos de aplicación descritos anteriormente, existen otros casos en los que se aplican diferentes métodos. Además, no sólo no existe un método estandarizado para la información de inicio de sesión y el proceso de autenticación basado en la autenticación de formulario, sino que tampoco existe una estandarización sobre cómo el servidor debe guardar la información de inicio de sesión, como la contraseña enviada por el usuario. Por lo general, un método de almacenamiento seguro es agregar primero información adicional a la contraseña agregando sal (sal) 1 y luego usar una función hash (hash) para calcular el valor hash y guardarlo. Pero también vemos a menudo la práctica de guardar directamente las contraseñas en texto plano, y esta práctica tiene el riesgo de provocar la divulgación de contraseñas.