Hoy en día, HTTPS es más rápido y más seguro, y más sitios web comerciales usan HTTPS que nunca. Por muy ocupado que esté un desarrollador web o un arquitecto de red, puede ser difícil mantenerse al día con los últimos avances en tecnología de Internet.
En este artículo, analizaré las mejores formas de proteger los sitios web modernos con SSL. Además de garantizar la seguridad de los sitios web corporativos, el SSL moderno también tiene en cuenta el rendimiento. Por lo tanto, este artículo cubrirá algunos métodos de optimización de SSL que pueden ayudar a mejorar el rendimiento del sitio web.
Antes de discutir el llamado mejor enfoque, primero veamos algunos términos de SSL y TLS. Técnicamente, SSL ha sido reemplazado por el protocolo TLS (Seguridad de la capa de transporte), pero la mayoría de las personas aún confunden SSL y TLS con SSL. Este artículo todavía usa esta expresión a menos que haya un número de versión después de SSL.
En segundo lugar, también es importante tener una comprensión básica del protocolo de enlace SSL/TLS antes de sumergirse en la discusión. Este protocolo de enlace se produce cuando el navegador se conecta al servidor a través de HTTPS y es un método acordado por el cliente y el servidor para el cifrado de la sesión. Hay varios tipos diferentes de protocolos de enlace TLS, pero el diagrama de protocolo de enlace RSA muestra las partes relevantes.
Primero, el navegador envía un gran número aleatorio y una lista de conjuntos de cifrado al servidor web, iniciando así el protocolo de enlace TLS. El servidor web elige el conjunto de cifrado principal, que determina el tipo de protocolo de enlace y el mecanismo de cifrado utilizado para esta sesión TLS. Luego, el servidor web envía el conjunto de cifrado al navegador y también devuelve otro gran número aleatorio y el certificado SSL público del servidor al navegador. El navegador necesita saber si un certificado SSL está revocado, por lo que verifica la lista de revocación de certificados de la CA (a menos que se admitan envoltorios OCSP).
Si el certificado sigue siendo válido, el navegador genera una "clave maestra previa" para generar una clave de sesión simétrica. El navegador encripta la "clave maestra previa" con la clave pública del servidor (contenida en el certificado SSL del servidor) y la transmite de vuelta al servidor. Después de que el servidor descifra la "clave maestra previa" con la clave privada, tanto el navegador como el servidor obtienen la clave simétrica, que se utiliza para cifrar el resto de la sesión TLS.
Cada una de las medidas discutidas en este artículo puede hacer que estos pasos sean más seguros o más rápidos. La solicitud de certificado SSL se puede aplicar en Wei Keyun.
Aproveche las características de seguridad de SSL moderno
Hay muchos pasos en el protocolo de enlace TLS, lo que significa que los administradores de seguridad tienen muchas oportunidades para mejorar la seguridad de un sitio web. Aquí primero analizamos HSTS que fuerza las conexiones HTTPS, luego analizamos el estado actual de SHA-1 y SHA-2, cómo proteger los datos de las futuras sesiones de usuario y la importancia de actualizar a la última versión de TLS.
Admite encabezado HSTS
La compatibilidad con el protocolo HSTS es una de las formas más sencillas de proteger mejor los sitios web, las API y las aplicaciones móviles. HSTS es una extensión del protocolo HTTP que obliga a los clientes a utilizar una conexión segura para cada solicitud a un servidor web. Al proporcionar un encabezado Strict Transport Security (STS), un servidor web puede indicar a los navegadores que se conecten a un sitio web a través de HTTPS solo durante un período de tiempo específico.
Luego, el navegador convierte automáticamente todas las solicitudes http en solicitudes https antes de enviar la solicitud del usuario al servidor. HSTS también le dice al navegador que muestre una página de error cuando hay un problema con la seguridad de la conexión (por ejemplo, cuando ya no se confía en el certificado TLS del servidor). Este tipo de error, a diferencia de los errores que los usuarios pueden ignorar intuitivamente, no se puede eludir.
Este tipo de reescritura de enlaces brinda protección contra ciertos tipos de "ataques de degradación", como los ataques de eliminación de SSL, que evitan que el hombre en el medio husmee en las comunicaciones de los usuarios al convertir las solicitudes HTTPS en solicitudes HTTP.
Admite la firma de certificados SHA-2
SHA-2 es la versión de próxima generación de SHA (algoritmo hash seguro). El algoritmo hash es una función unidireccional que produce la huella digital única de un mensaje y ha sido un componente clave desde el inicio de Internet.
Después de que la CA emite el certificado TLS para el sitio web, obtiene toda la información del certificado (nombre de dominio, período legal, clave pública, número de serie, etc.) información para crear una firma y generar una clave de firma privada. Antes de que el navegador pueda confiar en el certificado del servidor, debe codificar la información del certificado y usar la clave pública de la CA para verificar que la huella digital coincida con la firma del certificado.
Si un atacante puede generar la misma huella digital utilizando información de certificado diferente, es posible generar un certificado falso que aún puede verificarse mediante una firma de CA. Entonces, un atacante podría usar este certificado falsificado como intermediario, y el usuario final no podría saber si estaba enviando su información confidencial a alguien en Internet, en lugar de a un servidor web seguro.
La generación de dichas colisiones hash requiere recursos computacionales significativos. A medida que las computadoras se vuelven más rápidas y económicas, es más probable que un atacante pueda falsificar un certificado TLS firmado con SHA-1. La solución es SHA-2.
Todos los sitios web modernos usan certificados TLS firmados con SHA-2 en lugar de SHA-1. Si un sitio web corporativo todavía usa certificados SHA-1, los principales proveedores de navegadores mostrarán un mensaje de advertencia que indica a los visitantes del sitio que están visitando un sitio no seguro. A finales de 2016, los navegadores bloquearán por completo el acceso de los usuarios a dichos sitios. Para actualizar, el sitio web corporativo debe comprar un nuevo certificado SHA-2 de su propia CA e instalarlo en el servidor web.
Si una empresa aún necesita admitir usuarios que no pueden usar SHA-2, considere utilizar un certificado que seleccione la seguridad más alta y que sea compatible con el navegador del usuario.
Cifrado con soporte EDH (Ephemeral Diffie-Hellman) para reenvío
Si el servidor sigue usando la misma clave privada para obtener la clave de sesión TLS simétrica, la clave privada se convierte en un eslabón débil de la cadena. Por ejemplo, si un atacante registra una gran cantidad de comunicación entre el servidor y el usuario, la clave privada puede ser robada del servidor y la comunicación puede descifrarse.
EDH (Ephemeral Diffie-Hellman) o DHE puede hacer que la sesión cifrada de un usuario sea más segura incluso si la clave privada es robada en una fecha posterior. EDH es un mecanismo de intercambio de claves que produce una clave simétrica única para cada sesión, lo que significa que incluso si la clave privada del servidor es robada durante años, un atacante no puede usarla para descifrar las sesiones grabadas.
Solo admite TLS1.2
Los sistemas de cifrado no son estáticos, por lo que un servidor web seguro siempre debe ser totalmente compatible con las últimas y mejores mejoras en la seguridad de Internet. Idealmente, un sitio web corporativo no debe admitir ningún sistema que no sea la última versión de TLS. Las primeras versiones de los protocolos TLS y SSL incluían conjuntos de cifrado obsoletos o algunas implementaciones inseguras, lo que hacía que las comunicaciones cifradas de una empresa fueran vulnerables a los ataques.
Las conexiones TLS dependen de las capacidades del cliente y del servidor. Los administradores de seguridad pueden estar preocupados de que si los sitios web corporativos no son compatibles con versiones anteriores, esto puede afectar la experiencia del cliente, pero, de hecho, la mayoría de los navegadores han sido compatibles con TLS 1.2 durante mucho tiempo.
Para fines de junio de 2016, la actualización a TLS 1.2 será obligatoria para las empresas que deban cumplir con PCI. Entonces, ahora tenemos una razón para implementar una política de solo TLS1.2 para sitios web.
Mantener actualizado el SSL de su servidor tiene implicaciones reales para la seguridad de su sitio web corporativo. SSL3.0 es vulnerable a los ataques de POODLE y también al cifrado RC4 comprometido con problemas de seguridad. TLS 1.0 solucionó este problema, pero descubrió una nueva vulnerabilidad: manejo incorrecto de vectores de inicialización implícitos y errores de relleno, lo que resultó en un CBC encriptado inseguro. TLS1.1 es igual y vulnerable al ataque Lucky 13. TLS 1.2 admite el uso del conjunto de cifrado AES-GCM sin las mismas vulnerabilidades del cifrado en modo CBC.
Aproveche al máximo las optimizaciones modernas de rendimiento de SSL
SSL solía ser mucho más lento que HTTP, por lo que muchos desarrolladores web y administradores de redes prefieren usar "http://". Sin embargo, el desarrollo de la tecnología de Internet ha hecho que SSL sea más eficiente. Al aprovechar las últimas funciones de rendimiento de TLS y las tecnologías SPDY o http/2, los sitios web SSL modernos tienden a ser más rápidos que los sitios web sin cifrar.
Admite encapsulación OCSP
CA y TLS no siempre son confiables. A veces, una CA emite un certificado inesperado, a veces una empresa cambia su política de seguridad de una manera que invalida el certificado y, a veces, un usuario malintencionado roba la clave de un certificado. Sea cual sea el motivo, las CA y los proveedores de navegadores reconocen que necesitan una forma de revocar los certificados que pueden verse comprometidos.
Para que los usuarios de un sitio web confíen en el certificado TLS que les entregó el servidor, deben consultar la Lista de revocación de certificados (CRL) mantenida por la CA para ver si el certificado ha sido revocado. Desafortunadamente, esta verificación de revocación adicional puede retrasar la carga de la página del usuario y el navegador debe esperar hasta que la CA devuelva el estado del certificado TLS. Esta verificación también requiere a menudo búsquedas de DNS y descargas de muchos certificados revocados, lo que resulta en un enorme sacrificio de rendimiento.
El contenedor OCSP es parte de OCSP, que soluciona algunos problemas de rendimiento con la verificación de revocación en tiempo real. Por lo tanto, el servidor web ya no obliga al navegador del usuario a consultar directamente a la CA, sino que el propio servidor consulta a la CA en un momento determinado para recuperar la respuesta OCSP. Esta respuesta es emitida por la CA, demostrando la validez del certificado TLS durante el período de tiempo especificado. El servidor puede eliminar el tiempo de ida y vuelta innecesario al navegador del usuario.
Admite ECC (criptografía de curva elíptica)
ECC es una alternativa contemporánea a RSA. ECC utiliza las propiedades matemáticas de las curvas elípticas para crear funciones unidireccionales, que se convierten en la base de la criptografía de clave pública.
El beneficio de usar ECC es que ECC requiere una clave más corta, por lo que hay poca necesidad de transmitir datos a la computadora del usuario final, lo que acelera el protocolo de enlace TLS inicial. Además, ECC tarda 10 veces menos en firmar que RSA. Cada protocolo de enlace debe estar firmado por la clave privada, por lo que ECC puede reducir la carga en el servidor.
Soporte para restaurar sesión TLS a través de ticket de sesión (Session Ticket)
No hace falta decir que TLS es costoso, pero TLS incluye una forma de evitar apretones de manos innecesarios. La reanudación de la sesión de TLS puede usar la clave simétrica de la sesión anterior para volver a conectar el cliente y el servidor. Esto elimina la necesidad de viajes de ida y vuelta de datos adicionales y el costo de adquirir una nueva clave simétrica. Hay dos mecanismos de recuperación de TLS diferentes: tickets e identificaciones.
Si tanto el navegador como el servidor admiten vales de sesión TLS, el servidor devuelve un vale que contiene la clave simétrica como parte del protocolo de enlace. Este ticket está encriptado con una clave de encriptación conocida solo por el servidor, lo que hace que almacenar la información de la sesión TLS sea un método seguro. Cuando el navegador intenta volver a conectarse al servidor, devuelve un ticket de sesión encriptado. Todos pueden omitir el resto del protocolo de enlace TLS porque ambas partes tienen acceso a la clave de sesión simétrica.
Desafortunadamente, Safari e IE no admiten tickets de sesión. Estos navegadores usan un mecanismo llamado ID de sesión para reanudar las sesiones TLS. La información de la sesión se almacena en el servidor en lugar del cliente, y el cliente devuelve la identificación de la sesión al servidor. Mantener una memoria caché de todos los parámetros de conexión TLS puede ser una carga para el servidor, pero si desea admitir la reanudación de la sesión TLS de manera más amplia, es una buena idea admitir los vales de sesión y los ID de sesión.
Soporta SPDY o HTTP/2
SPDY y HTTP/2 son protocolos de Internet que pueden mejorar en gran medida la velocidad de carga del sitio web. Técnicamente, SSL no requiere ninguno de estos protocolos, pero los principales proveedores de navegadores admiten SPDY o http/2.
HTTP/1.1 impone una conexión TCP para cada solicitud y los navegadores solo pueden abrir una cantidad limitada de conexiones TCP a la vez. Como resultado, el HTML, CSS, JavaScript, recursos multimedia, etc. del sitio web se descargan continuamente. HTTP/2 y SPDY agregaron varias características nuevas llamadas multiplexación que permiten a los navegadores usar una sola conexión TCP para todo el sitio web. A diferencia de HTTP/1.1, la multiplexación permite que el navegador descargue todos los activos de un sitio web en paralelo. Por lo tanto, es mucho más rápido que HTTP/1.1.
La mayoría de las comunicaciones por Internet admiten SPDY o HTTP/2. Si su servidor web no es compatible con este navegador SPDY y HTTP/2 ampliamente compatible, no podrá aprovechar al máximo el valor total de un servidor web habilitado para TLS. Este es un buen ejemplo de cómo SSL moderno realmente hace que los servidores web sean más rápidos, aunque al principio tenga algún costo para el apretón de manos.
Conclusión: todo sobre HTTPS
Después de tener en cuenta los beneficios de seguridad y rendimiento de SSL moderno, ya no hay razón para que un sitio web corporativo no utilice HTTPS para cada solicitud. Esto simplifica el trabajo de los desarrolladores web y administradores de sistemas porque ya no necesitan escribir complejos redireccionamientos de URL para usar HTTP para algunas páginas y HTTPS para otras.
Elegir TLS también genera confianza entre las empresas y los sitios web corporativos. HTTPS garantiza que los visitantes de un sitio web vean lo que deberían ver en un sitio web comercial. Al proporcionar contenido a través de HTTPS, las empresas pueden evitar la situación de que los ISP inserten anuncios en las páginas web corporativas cuando usan HTTP normal.
Cuatro mejores prácticas útiles de SSL cuando se trata de proteger sitios web corporativos son:
1. Admite encabezado HSTS
2. Firma con certificado SHA-2
3. Encriptación de reenvío mediante protocolo de enlace EDH
4. Actualizar a TLS1.2
Además, estas son las cuatro mejores maneras de hacer que su sitio web comercial habilitado para SSL funcione mejor:
1. Admite paquete OCSP
2. Utilizar criptografía de curva elíptica (ECC)
3. Admite recuperación de sesión TLS
4. Admite HTTP/2 y SPDY