En 2023, proteger su sitio web con SSL /TLS el certificado ya no es opcional, incluso para empresas que no tratan directamente con información confidencial de clientes en la web. Los motores de búsqueda como Google utilizan la seguridad del sitio como una señal de clasificación de SEO, y los navegadores web populares como Chrome alertan a los usuarios sobre sitios web que no utilizan HTTPS:
Sin embargo, la perspectiva de configurar sus servidores web y aplicaciones para usar SSL /TLS El protocolo correctamente puede resultar abrumador, ya que hay muchas opciones arcanas de configuración y diseño que tomar. Esta guía proporciona una descripción general rápida de los puntos principales a tener en cuenta al configurar SSL /TLS para su sitio web, centrándose tanto en la seguridad como en el rendimiento. Todavía hay mucho que cubrir solo con lo básico, por lo que lo hemos dividido en una serie de pasos.
SSL.com proporciona una amplia variedad de SSL/TLS certificados de servidor. Asegure su sitio web hoy con un certificado SSL de SSL.com y genera confianza con tus visitantes!
Elija una autoridad de certificación confiable (CA)
Sus certificados son tan confiables como la CA que los emite. Todas las CA de confianza pública están sujetas a rigurosas auditorías de terceros para mantener su posición en los principales sistemas operativos y programas de certificados raíz del navegador, pero algunas son mejores para mantener ese estado que otras. Busque una CA que (como SSL.com):
- Realiza la mayor parte de su negocio en el campo de la confianza pública PKI. Estas empresas tienen más que perder si salen a la luz prácticas de seguridad deficientes y mucho que ganar si se mantienen al día con los estándares de la industria en evolución.
- Responde de manera eficiente y efectiva a los descubrimientos de vulnerabilidades que afectan la seguridad y privacidad del usuario, como la industria número de serie entropía edición de principios de 2019. Búsqueda en foros de la industria como mozilla.dev.seguridad.policy puede darle una buena idea sobre cómo una CA en particular reacciona a la adversidad.
- Ofrece productos y servicios útiles, como certificados de validación extendida (EV), emisión de certificados masiva / automatizada a través de un intuitivo API o el Protocolo ACME, servicios sencillos de supervisión y gestión del ciclo de vida de los certificados, y SOPORTE para la integración con una extensa lista de soluciones de terceros.
- Tiene una reputación de excelente servicio al cliente y soporte técnico. Mantener el sitio web de su empresa seguro el 100% del tiempo es importante, y necesita poder llamar a un verdadero experto por teléfono cuando las cosas van mal.
Autorización de Autoridad de Certificación (CAA)
Autorización de Autoridad de Certificación (CAA) es un estándar para proteger sitios web mediante la designación de CA específicas que pueden emitir certificados para un nombre de dominio. Una vez que haya elegido una CA, debe considerar configurar registros CAA para autorizarlo.
Genere y asegure sus claves privadas
El SSL /TLS protocolo utiliza una par de llaves para autenticar identidades y encriptar información enviada por Internet. Uno de estos (el Llave pública) está destinado a una amplia distribución, y el otro (el llave privada) debe mantenerse de la forma más segura posible. Estas claves se crean juntas cuando genera un Solicitud de firma de certificado (CSR). Aquí hay algunos consejos para tener en cuenta con respecto a sus claves privadas:
- Use claves privadas fuertes: Las claves más grandes son más difíciles de descifrar, pero requieren más sobrecarga informática. Actualmente, se recomienda al menos una clave RSA de 2048 bits o una clave ECDSA de 256 bits, y la mayoría de los sitios web pueden lograr una buena seguridad al tiempo que optimizan el rendimiento y la experiencia del usuario con estos valores.
Nota: para obtener una descripción general de estos dos algoritmos, consulte el artículo de SSL.com, Comparando ECDSA vs RSA. - Proteja sus claves privadas:
- Genere sus propias claves privadas en un entorno seguro y confiable (preferiblemente en el servidor donde se implementarán o un dispositivo compatible con FIPS o Common Criteria). Nunca permitir que una CA (o cualquier otra persona) genere claves privadas en su nombre. Una CA pública de buena reputación, como SSL.com, nunca ofrecerá generar o manejar sus claves privadas a menos que se generen en un token de hardware seguro o HSM y no sean exportables.
- Solo dé acceso a claves privadas según sea necesario. Generar nuevas claves y revocar todos los certificados para las claves antiguas cuando los empleados con acceso a clave privada abandonen la empresa.
- Renueve los certificados con la mayor frecuencia posible (al menos una vez al año sería bueno), preferiblemente utilizando una clave privada recién generada cada vez. Herramientas de automatización como Protocolo ACME son útiles para programar renovaciones frecuentes de certificados.
- Si una clave privada ha sido (o podría haber sido) comprometida, revocar todos los certificados para esta clave, genere un nuevo par de claves y emita un nuevo certificado para el nuevo par de claves.
Configure su servidor
En la superficie, instalar un SSL /TLS certificado puede parecer una operación sencilla; sin embargo, todavía hay muchas decisiones de configuración que deben tomarse para garantizar que su servidor web sea rápido y seguro, y que los usuarios finales tengan una experiencia fluida libre de errores y advertencias del navegador. A continuación, se muestran algunos consejos de configuración que le ayudarán a encaminarse al configurar SSL /TLS en sus servidores:
- Asegúrese de que todos los nombres de host estén cubiertos: ¿Su certificado cubre el nombre de dominio de su sitio con y sin el
www
¿prefijo? Hay un Nombre alternativo del sujeto (SAN) para cada nombre de dominio que el certificado pretende proteger? - Instalar cadenas de certificados completas: SSL de entidad final /TLS los certificados generalmente están firmados por certificados intermedios en lugar de la clave raíz de una CA. Asegúrese de que los certificados intermedios estén instalados en su servidor web para proporcionar a los navegadores una completa ruta de certificación y evitar advertencias y errores de confianza para los usuarios finales. Su CA podrá proporcionarle los intermediarios necesarios; Los clientes de SSL.com pueden utilizar nuestro Descarga de certificado intermedio página para recuperar paquetes intermedios para muchas plataformas de servidor.
- Usar SSL actual /TLS Protocolos (TLS 1.2 o 1.3): A finales de 2018, todos los principales proveedores de navegadores anunciaron planes para desaprobar TLS 1.0 y 1.1 para el primer semestre de 2020. Google TLS v1.0 y v1.1 en Chrome 72 (lanzado el 30 de enero de 2919). Las versiones de Chrome 84 (lanzadas el 14 de julio de 2020) y superiores presentan una advertencia intersticial para estos protocolos, y se programó la compatibilidad completamente eliminado en mayo de 2021. Compatibilidad generalizada con el navegador de SSL /TLS las versiones, como SSL v3, ya no existen. Mientras TLS 1.2 es actualmente la versión más utilizada de SSL /TLS protocolo, TLS 1.3 (la última versión) es ya soportado en las versiones actuales de la mayoría de los principales navegadores web.
- Use una lista corta de suites de cifrado seguro: Elija solo conjuntos de cifrado que ofrezcan encriptación de al menos 128 bits, o más fuertes cuando sea posible. El Instituto Nacional de Estándares y Tecnología (NIST) también recomienda que todos TLS las implementaciones se alejan de los conjuntos de cifrado que contienen el cifrado DES (o sus variantes) a los que utilizan AES. Finalmente, el uso de solo un pequeño subconjunto de conjuntos de cifrado potencialmente aceptables minimiza la superficie de ataque de vulnerabilidades aún no descubiertas. El apéndice de SSL.com Guía para TLS Cumplimiento de Normas proporciona configuraciones de ejemplo para las plataformas de servidor web más populares, utilizando TLS 1.2.
Nota: El uso de cifras inseguras y obsoletas (como RC4) puede causar errores de seguridad del navegador, comoERR_SSL_VERSION_OR_CIPHER_MISMATCH
en Google Chrome - Utilice el secreto directo (FS): También conocido como perfecto secreto hacia adelante (PFS), FS asegura que una clave privada comprometida no comprometerá también claves de sesión anteriores. Para habilitar FS:
- Configurar TLS 1.2 para utilizar el algoritmo de intercambio de claves Diffie-Hellman de curva elíptica (EDCHE) (con DHE como respaldo), y evite el intercambio de claves RSA por completo si es posible.
- Usa TLS 1.3. TLS 1.3 proporciona secreto para todos TLS sesiones a través de la Efímero Diffie-Hellman (EDH o DHE) protocolo de intercambio de claves.
- permitir TLS Reanudación de sesión: De manera similar al uso de keepalives para mantener conexiones TCP persistentes, TLS La reanudación de la sesión permite que su servidor web realice un seguimiento de SSL /TLS sesiones y reanudarlas, evitando la sobrecarga computacional de la negociación de clave de sesión.
- Considere grapar OCSP: Grapado OCSP permite que los servidores web entreguen información de revocación en caché directamente al cliente, lo que significa que un navegador no tendrá que ponerse en contacto con un servidor OCSP para comprobar si se ha revocado el certificado de un sitio web. Al eliminar esta solicitud, el grapado OCSP ofrece un aumento real del rendimiento. Para obtener más información, lea nuestro artículo, Optimización de carga de página: grapado OCSP.
Utilice las mejores prácticas para el diseño de aplicaciones web
Diseñar sus aplicaciones web teniendo en cuenta la seguridad es tan importante como configurar correctamente su servidor. Estos son los puntos más importantes para asegurarse de que sus usuarios no estén expuestos a hombre en el medio ataques, y que su aplicación obtenga los beneficios de SEO que vienen con las buenas prácticas de seguridad:
- Eliminar contenido mixto: Los archivos JavaScript, las imágenes y los archivos CSS deben all ser accedido con SSL /TLS. Como se describe en el artículo de SSL.com, HTTPS en todas partessirviendo contenido mixto ya no es una forma aceptable de aumentar el rendimiento del sitio web y puede generar advertencias de seguridad del navegador y problemas de SEO.
- Use cookies seguras: Configurando el
Secure
La marca en las cookies impondrá la transmisión a través de canales seguros (por ejemplo, HTTPS). También puede evitar que JavaScript del lado del cliente acceda a las cookies a través deHttpOnly
marcar y restringir el uso de cookies entre sitios con elSameSite
bandera. - Evaluar código de terceros: Asegúrese de comprender los riesgos potenciales de utilizar bibliotecas de terceros en su sitio web, como la posibilidad de introducir inadvertidamente vulnerabilidades o código malicioso. Siempre verifique la confiabilidad de terceros lo mejor que pueda y vincule a todos los códigos de terceros con HTTPS. Finalmente, asegúrese de que valga la pena correr el riesgo de beneficiarse de cualquier elemento de terceros en su sitio web.
Verifique su trabajo con herramientas de diagnóstico
Después de configurar SSL /TLS en su servidor y sitio web o haciendo cualquier cambio de configuración, es importante asegurarse de que todo esté configurado correctamente y su sistema sea seguro. Hay numerosas herramientas de diagnóstico disponibles para verificar el SSL /TLS. Por ejemplo, SSL Shopper's Verificador SSL le permitirá saber si su certificado está instalado correctamente, cuándo caducará y mostrará el certificado cadena de confianza.
Hay otras herramientas y aplicaciones en línea disponibles que rastrearán su sitio buscando problemas de seguridad como contenido mixto. También puede verificar el contenido mixto con un navegador web utilizando sus herramientas de desarrollador integradas:
Independientemente de las herramientas que elija, también es importante establecer un horario para verificar su SSL /TLS instalacion y configuracion. Su CA también puede ayudarlo con esto; por ejemplo, para comodidad de nuestros clientes, SSL.com proporciona avisos automáticos de vencimiento inminente del certificado.
Implementar seguridad de transporte estricta de HTTP (HSTS)
HTTP Strict Transport Security (HSTS) es un mecanismo de política de seguridad que ayuda a proteger los sitios web contra ataques de degradación de protocolo y secuestro de cookies. Permite que los servidores web declaren que los navegadores web (u otros agentes de usuario compatibles) solo deben interactuar con él mediante conexiones HTTPS seguras, y nunca a través del protocolo HTTP no seguro. El servidor comunica esta política al agente de usuario a través de un campo de encabezado de respuesta HTTP llamado "Strict-Transport-Security".
Para implementar Seguridad de transporte estricta de HTTP (HSTS), debe agregar un encabezado de respuesta especial a la configuración de su servidor web.
Aquí tienes una guía paso a paso:
- Asegúrese de que su sitio sea compatible con HTTPS: Antes de habilitar HSTS, su sitio debe tener una Certificado SSL y ser capaz de servir contenido a través de HTTPS. Si su sitio aún no está configurado para HTTPS, deberá obtener un certificado SSL y configura tu servidor para usarlo.
El encabezado siempre establece Strict-Transport-Security "max-age=31536000; includeSubDomains"
Esta línea le dice al navegador que siempre use HTTPS para su sitio durante el próximo año (31,536,000 XNUMX XNUMX segundos), incluidos todos los subdominios.
- Prueba tu configuración: Después de agregar el encabezado HSTS, debe probar su sitio para asegurarse de que funciona correctamente. Puede hacerlo visitando su sitio y utilizando las herramientas de desarrollo de su navegador para verificar los encabezados de respuesta. Debería ver el encabezado Strict-Transport-Security con el valor que estableció.
- Considere agregar su sitio a la lista de precarga de HSTS: La lista de precarga de HSTS es una lista de sitios que están codificados en los navegadores como habilitados para HSTS. Esto proporciona un nivel adicional de protección, ya que garantiza que la primera conexión a su sitio sea segura, incluso antes de que se reciba el encabezado HSTS. Puede enviar su sitio a la lista de precarga de HSTS en hstspreload.org.
Caso de uso: Un sitio web de noticias quiere asegurarse de que sus usuarios siempre se conecten a él de forma segura, incluso si accidentalmente escriben "http" en lugar de "https" en la URL. El sitio web utiliza HSTS agregando el encabezado Strict-Transport-Security a la configuración de su servidor, estableciendo una edad máxima larga e incluyendo todos los subdominios. Esto le dice a los agentes de usuario que siempre se conecten a él usando HTTPS, protegiendo a los usuarios de los ataques que intentan degradar la conexión a HTTP y robar sus cookies. El sitio web también se envía a la lista de precarga de HSTS para una protección adicional.
Implementar la fijación de clave pública HTTP (HPKP)
HTTP Public Key Pinning (HPKP) era una función de seguridad que permitía a un servidor web asociar una clave pública criptográfica específica consigo mismo para evitar ataques de hombre en el medio (MITM) con certificados falsificados.
Aquí hay una breve descripción de cómo se usó:
- Generar información de fijación: El primer paso para implementar HPKP fue generar la información de fijación. Esto implicó crear un hash criptográfico de la clave pública del certificado o la clave pública del certificado intermedio o raíz.
- Configurar el servidor web: El siguiente paso fue configurar el servidor web para incluir el PIN de clave pública HTTP encabezado en las respuestas. Este encabezado incluía los hash de las claves públicas (los "pines"), un tiempo de vida (cuánto tiempo el navegador debería recordar la información) y, opcionalmente, un URI de informe (donde el navegador enviaría informes de fallas de validación de pines).
- Manejar fallas en la validación de pines: si un navegador compatible con HPKP recibiera una cadena de certificados que no incluyera al menos una de las claves públicas ancladas, consideraría que la conexión no es de confianza. Si se especificó un URI de informe, el navegador también enviaría un informe del error a ese URI.
Sin embargo, debido al riesgo de uso indebido y la posibilidad de causar una denegación de servicio, la mayoría de los navegadores han dejado de usar HPKP y ya no es una práctica recomendada. La configuración incorrecta de HPKP podría conducir a una situación en la que un sitio web se vuelva inaccesible.
Caso de uso: En el pasado, una empresa de tecnología usó HPKP para anclar sus claves públicas a sus servidores. Esto aseguró que si una Autoridad de certificación (CA) se viera comprometida y se emitiera un certificado por error para su dominio, los navegadores no confiarían en él a menos que también tuviera una clave pública que coincidiera con una de las claves ancladas. Sin embargo, tenían que tener mucho cuidado para evitar perder el acceso a las claves ancladas, lo que haría que su sitio web fuera inaccesible. También tenían que asegurarse de contar con un proceso para rotar los pines antes de que expiraran, para evitar que su sitio fuera inaccesible para los usuarios con información de pines almacenada en caché.
SSL.com proporciona una amplia variedad de SSL/TLS certificados de servidor. Asegure su sitio web hoy con un certificado SSL de SSL.com y genera confianza con tus visitantes!
Usa TLS SCSV alternativo para evitar ataques de degradación de protocolo
TLS SCSV alternativo (Valor de conjunto de cifrado de señalización) es un mecanismo que se introdujo para evitar ataques de degradación de protocolo. Estos ataques ocurren cuando un atacante interfiere con el proceso de configuración de la conexión y engaña al cliente y al servidor para que usen una versión menos segura del protocolo que la que ambos realmente admiten.
Así es como puede implementar TLS SCSV alternativo:
- Actualice el SSL de su servidor/TLS Biblioteca: El primer paso es asegurarse de que el servidor SSL/TLS soportes de biblioteca TLS SCSV alternativo. Esta función se introdujo en OpenSSL 1.0.1j, 1.0.0o y 0.9.8zc. Si está utilizando un SSL diferente/TLS biblioteca, consulta su documentación o contacta con sus desarrolladores.
- Configure su servidor: Una vez que su servidor SSL/TLS soportes de biblioteca TLS Fallback SCSV, es posible que deba configurar su servidor para usarlo. Los pasos exactos dependerán del software de su servidor. Por ejemplo, en Apache, es posible que deba agregar o modificar una línea en su archivo de configuración como esta:
Protocolo SSL Todo -SSLv2 -SSLv3
Esta línea le dice al servidor que use todas las versiones del protocolo excepto SSLv2 y SSLv3. Si el cliente y el servidor son compatibles TLS 1.2, pero el cliente intenta usar TLS 1.1 (quizás debido a la interferencia de un atacante), el servidor reconocerá esto como un intento de respaldo y rechazará la conexión.
- Pruebe su servidor: Después de configurar su servidor, debe probarlo para asegurarse de que está implementando correctamente TLS SCSV alternativo. Existen varias herramientas en línea que pueden ayudarlo con esto, como SSL Labs Server Test.
Caso de uso: Una corporación global utiliza TLS Fallback SCSV para proteger sus comunicaciones internas. Esto asegura que si un atacante intenta forzar una degradación del protocolo, el servidor lo reconocerá y rechazará la conexión, protegiendo los datos confidenciales de la corporación. El equipo de TI de la corporación actualiza periódicamente el SSL/TLS bibliotecas y configuraciones para asegurarse de que están usando las funciones de seguridad más recientes, y usan herramientas en línea para probar sus servidores y confirmar que están implementando correctamente TLS SCSV alternativo.
Evite problemas de contenido mixto
El contenido mixto es un riesgo de seguridad que ocurre cuando una página web cargada a través de una conexión HTTPS segura incluye recursos, como imágenes, videos, hojas de estilo o secuencias de comandos, que se cargan a través de una conexión HTTP no segura. Los navegadores pueden bloquear este contenido mixto o mostrar una advertencia al usuario, lo que puede dañar la percepción del usuario sobre la seguridad del sitio.
Así es como puede evitar problemas de contenido mixto:
- Usar HTTPS para todos los recursos: La forma más sencilla de evitar el contenido mixto es asegurarse de que todos los recursos de su sitio se carguen a través de HTTPS. Esto incluye imágenes, scripts, hojas de estilo, iframes, solicitudes AJAX y cualquier otro recurso que utilice su sitio.
- Actualice el código de su sitio: si el código de su sitio incluye direcciones URL HTTP codificadas para recursos, deberá actualizarlas para usar HTTPS en su lugar. Si el recurso está alojado en un servidor que no admite HTTPS, es posible que deba alojar el recurso en su propio servidor o encontrar un recurso alternativo que pueda cargarse a través de HTTPS.
- Configure su servidor para enviar un encabezado de política de seguridad de contenido: El encabezado HTTP Content-Security-Policy (CSP) le permite controlar qué recursos puede cargar su sitio. Al establecer un encabezado CSP que solo permita recursos HTTPS, puede asegurarse de que su sitio no incluya accidentalmente contenido mixto.
Caso de uso: una revista en línea garantiza que todo el contenido, incluidas las imágenes y los guiones, se cargue a través de HTTPS. Esto evita que los atacantes manipulen estos recursos y potencialmente inyecten contenido malicioso. Los desarrolladores web de la revista revisan regularmente el código del sitio para asegurarse de que todos los recursos se carguen a través de HTTPS y configuran su servidor para enviar un encabezado estricto de política de seguridad de contenido. También usan herramientas en línea para escanear su sitio en busca de problemas de contenido mixto y corregir cualquier problema que encuentren.
Utilice la indicación de nombre de servidor (SNI) para alojar múltiples sitios
Indicación de nombre del servidor (SNI) es una extensión de la TLS protocolo que permite que un servidor presente múltiples certificados en la misma dirección IP y número de puerto. Esto es especialmente útil para los proveedores de alojamiento web que necesitan alojar varios sitios web seguros, cada uno con su propio certificado SSL, en el mismo servidor.
Así es como puede usar SNI:
- Asegúrese de que el software de su servidor sea compatible con SNI: El primer paso es asegurarse de que el software de su servidor sea compatible con SNI. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten SNI.
- Configure su servidor: El siguiente paso es configurar su servidor para usar SNI. Por lo general, esto implica agregar un bloque de configuración independiente para cada sitio que desee alojar en el servidor y especificar el Certificado SSL a utilizar para cada sitio. Los pasos exactos dependerán del software de su servidor.
- Pruebe su configuración: Después de configurar su servidor, debe probarlo para asegurarse de que está usando SNI correctamente. Puede hacer esto visitando cada sitio que está alojando en el servidor y verificando que se esté utilizando el certificado SSL correcto.
Caso de uso: un proveedor de alojamiento utiliza SNI para servir varios sitios web desde la misma dirección IP. Esto les permite usar eficientemente su espacio de direcciones IP y simplificar la configuración de su red. Configuran su servidor para usar un certificado SSL diferente para cada sitio y prueban regularmente su configuración para asegurarse de que se usa el certificado correcto para cada sitio. Esto garantiza que cada sitio tenga una conexión segura y confiable, aunque todos estén siendo atendidos desde la misma dirección IP.
Optimice el rendimiento con la reanudación de la sesión
La reanudación de la sesión es una característica del TLS protocolo que permite que un cliente y un servidor utilicen las mismas claves de cifrado en varias sesiones, lo que reduce la sobrecarga de establecer una nueva conexión segura cada vez. Esto puede mejorar significativamente el rendimiento, especialmente para aplicaciones en las que el cliente se desconecta y se vuelve a conectar con frecuencia.
Así es como puede usar la reanudación de la sesión:
- Asegúrese de que el software de su servidor admita la reanudación de la sesión: El primer paso es asegurarse de que el software de su servidor admita la reanudación de la sesión. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten esta función.
- Configure su servidor: El siguiente paso es configurar su servidor para usar la reanudación de sesión. Por lo general, esto implica habilitar la memoria caché de la sesión y establecer un valor de tiempo de espera para la memoria caché. Los pasos exactos dependerán del software de su servidor.
- Pruebe su configuración: Después de configurar su servidor, debe probarlo para asegurarse de que está utilizando correctamente la reanudación de la sesión. Puede hacer esto estableciendo un TLS conexión a su servidor, desconectando y luego volviendo a conectar. Si la reanudación de la sesión funciona correctamente, la segunda conexión debería ser más rápida de establecer que la primera.
Caso de uso: una aplicación móvil utiliza la reanudación de la sesión para mantener conexiones rápidas y seguras. Esto es particularmente útil cuando la aplicación se usa en áreas con cobertura de red irregular, ya que permite que la aplicación restablezca rápidamente una conexión segura después de un corte. Los desarrolladores de la aplicación configuran su servidor para usar la reanudación de la sesión y prueban la función periódicamente para asegurarse de que funciona correctamente. Esto garantiza que la aplicación pueda proporcionar una experiencia rápida y fluida para los usuarios, incluso en condiciones de red desafiantes.
Garantice la validez del certificado con grapado OCSP
El grapado del Protocolo de estado de certificado en línea (OCSP) es un método para mejorar el rendimiento de SSL/TLS manteniendo la seguridad de la conexión. Permite que el servidor obtenga el estado actual de sus propios certificados de la Autoridad de certificación (CA) y luego entregue ese estado a los clientes durante el TLS apretón de manos.
Así es como puede implementar el grapado OCSP:
- Asegúrese de que el software de su servidor sea compatible con el grapado OCSP: El primer paso es asegurarse de que el software de su servidor sea compatible con el grapado OCSP. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten esta función.
- Configure su servidor: El siguiente paso es configurar su servidor para usar grapado OCSP. Por lo general, esto implica habilitar la función en el SSL/TLS configuración y especificando una ubicación para que el servidor almacene las respuestas OCSP. Los pasos exactos dependerán del software de su servidor.
- Pruebe su configuración: Después de configurar su servidor, debe probarlo para asegurarse de que esté utilizando correctamente el grapado OCSP. Puede hacer esto estableciendo un TLS conexión a su servidor y comprobar que el servidor incluye una respuesta OCSP en el TLS apretón de manos.
Caso de uso: un minorista en línea utiliza grapado OCSP para verificar rápidamente el estado de su certificado SSL. Esto garantiza que los clientes siempre tengan una conexión segura y puedan confiar en que sus datos están seguros. El equipo de TI del minorista configura su servidor para usar el engrapado OCSP y prueban la función con regularidad para asegurarse de que funciona correctamente. Esto ayuda a mantener la confianza de sus clientes y proteger sus datos confidenciales.
Deshabilitar TLS Compresión para mitigar el ataque CRIME
TLS La compresión es una función que puede mejorar el rendimiento de SSL/TLS al reducir la cantidad de datos que deben enviarse a través de la red. Sin embargo, también puede hacer que la conexión sea vulnerable al ataque CRIME (Compression Ratio Info-leak Made Easy), que puede permitir a un atacante inferir el contenido del tráfico cifrado.
Así es como puede deshabilitar TLS compresión:
- Asegúrese de que el software de su servidor admita la desactivación TLS Compresión: El primer paso es asegurarse de que el software de su servidor admita la desactivación TLS compresión. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten esta función.
- Configure su servidor: El siguiente paso es configurar su servidor para deshabilitar TLS compresión. Los pasos exactos dependerán del software de su servidor. Por ejemplo, en Apache, puede agregar una línea como esta a su archivo de configuración:
Compresión SSL desactivada
Esta línea le dice al servidor que no use compresión para SSL/TLS conexiones.
- Pruebe su configuración: Después de configurar su servidor, debe probarlo para asegurarse de que se está deshabilitando correctamente TLS compresión. Puede hacer esto estableciendo un TLS conexión a su servidor y verificando que la conexión no esté usando compresión.
Caso de uso: Una entidad financiera desactiva TLS compresión en sus servidores para protegerse contra el ataque CRIME. Esto ayuda a garantizar la confidencialidad de los datos financieros confidenciales, como números de cuenta y detalles de transacciones. El equipo de TI de la institución configura sus servidores para deshabilitar TLS compresión, y regularmente prueban los servidores para asegurarse de que están implementando correctamente esta medida de seguridad. Esto ayuda a proteger a los clientes de la institución y mantener su confianza.
Implementar TLS Entradas de sesión correctamente
TLS los boletos de sesión son una característica del TLS protocolo que puede mejorar el rendimiento al permitir que un cliente y un servidor reanuden una sesión anterior sin necesidad de realizar un protocolo de enlace completo. Sin embargo, deben implementarse correctamente para evitar posibles problemas de seguridad.
Así es como puede implementar correctamente TLS boletos de sesión:
- Asegúrese de que su software de servidor sea compatible TLS Entradas de sesión: El primer paso es asegurarse de que el software de su servidor admita TLS boletos de sesión. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten esta función.
- Configure su servidor: El siguiente paso es configurar su servidor para usar TLS boletos de sesión. Por lo general, esto implica habilitar la función en el SSL/TLS configuración. Los pasos exactos dependerán del software de su servidor.
- Usar claves de ticket de sesión únicas: Para evitar posibles problemas de seguridad, cada servidor debe usar una clave de ticket de sesión única. Si usa un balanceador de carga, debe configurarlo para distribuir clientes según su ticket de sesión, en lugar de permitir que los clientes usen un ticket de sesión emitido por un servidor para establecer una sesión con otro servidor.
- Rotar las claves de los tickets de sesión con regularidad: Para mejorar aún más la seguridad, debe rotar periódicamente las claves de sus entradas de sesión. Esto a menudo se puede automatizar utilizando el software de su servidor o un sistema de administración de claves separado.
Caso de uso: una gran empresa de tecnología con varios servidores se asegura de que cada servidor utilice una clave de ticket de sesión única. Esto evita que un atacante pueda usar un vale de sesión de un servidor para hacerse pasar por un usuario en otro servidor. El equipo de TI de la empresa configura sus servidores para usar TLS boletos de sesión, y configuraron un sistema para rotar regularmente las claves de los boletos de sesión. También configuran su equilibrador de carga para distribuir clientes en función de su ticket de sesión, lo que mejora aún más la seguridad de su sistema.
Habilitar renegociación segura
La renegociación segura es una característica de SSL/TLS protocolos que permiten al cliente o servidor solicitar una nueva TLS apretón de manos en medio de una sesión. Esto puede ser útil por varios motivos, como actualizar las claves de cifrado o cambiar el nivel de cifrado. Sin embargo, si no se maneja de forma segura, un atacante puede explotarlo para inyectar texto sin formato en la comunicación cifrada.
Así es como puede habilitar la renegociación segura:
- Asegúrese de que el software de su servidor admita la renegociación segura: El primer paso es asegurarse de que el software de su servidor sea compatible con la renegociación segura. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten esta función.
- Configure su servidor: El siguiente paso es configurar su servidor para usar la renegociación segura. Por lo general, esto implica habilitar la función en el SSL/TLS configuración. Los pasos exactos dependerán del software de su servidor.
- Pruebe su configuración: Después de configurar su servidor, debe probarlo para asegurarse de que esté utilizando correctamente la renegociación segura. Puede hacer esto estableciendo un TLS conexión a su servidor y luego intentar renegociar la conexión.
Caso de uso: Una plataforma de redes sociales permite la renegociación segura para proteger los datos de los usuarios. Esto evita que un atacante pueda inyectar contenido malicioso en la comunicación cifrada entre el usuario y el servidor. El equipo de TI de la plataforma configura sus servidores para utilizar la renegociación segura y prueban periódicamente los servidores para asegurarse de que están implementando correctamente esta medida de seguridad. Esto ayuda a proteger a los usuarios de la plataforma y mantener su confianza.
Deshabilite la renegociación iniciada por el cliente para evitar ataques DoS
La renegociación iniciada por el cliente es una función de SSL/TLS protocolos que permite al cliente solicitar una nueva TLS apretón de manos en medio de una sesión. Sin embargo, si un atacante puede obligar a un servidor a renegociar sesiones continuamente, puede consumir recursos excesivos y potencialmente conducir a un ataque de denegación de servicio (DoS).
Así es como puede deshabilitar la renegociación iniciada por el cliente:
- Asegúrese de que el software de su servidor admita la desactivación de la renegociación iniciada por el cliente: El primer paso es asegurarse de que el software de su servidor admita la desactivación de la renegociación iniciada por el cliente. La mayoría de los servidores web modernos, incluidos Apache, Nginx e IIS, admiten esta función.
- Configure su servidor: El siguiente paso es configurar su servidor para deshabilitar la renegociación iniciada por el cliente. Por lo general, esto implica agregar una directiva al SSL/TLS configuración. Los pasos exactos dependerán del software de su servidor.
- Pruebe su configuración: Después de configurar su servidor, debe probarlo para asegurarse de que está deshabilitando correctamente la renegociación iniciada por el cliente. Puede hacer esto estableciendo un TLS conexión a su servidor y luego intentar renegociar la conexión. Si el servidor rechaza correctamente la solicitud de renegociación, entonces está configurado correctamente.
Caso de uso: una plataforma de juegos en línea desactiva la renegociación iniciada por el cliente para protegerse contra posibles ataques DoS. Esto ayuda a garantizar que la plataforma permanezca disponible para que los usuarios la disfruten, incluso frente a posibles ataques. El equipo de TI de la plataforma configura sus servidores para deshabilitar la renegociación iniciada por el cliente y prueba periódicamente los servidores para asegurarse de que están implementando correctamente esta medida de seguridad. Esto ayuda a proteger a los usuarios de la plataforma y mantener su confianza.
Manténgase alerta ante nuevas vulnerabilidades
La seguridad web es un objetivo en constante movimiento, y siempre debe estar atento al próximo ataque y aplicar rápidamente parches de seguridad en su servidor. Esto significa leer y mantenerse en contacto con lo que se avecina en lo que respecta a la seguridad de la información, así como estar al tanto de las actualizaciones de software, especialmente las críticas. Sitio web de SSL.com (donde está leyendo esto ahora mismo) es una excelente fuente para mantenerse actualizado sobre SSL /TLS y seguridad de la información.
Pero que pasa…?
Si desea saber más sobre cualquiera de los temas cubiertos en esta guía y aprender sobre nuevos problemas y tecnologías a medida que surgen, puede comenzar navegando y buscando en SSL.com. Biblioteca de Conocimiento, que mantenemos actualizado semanalmente con novedades en el campo de SSL /TLS y PKI. También puede comunicarse con nuestro personal de soporte en cualquier momento por correo electrónico a Support@SSL.com, por teléfono al 1-877-SSL-Secure o haciendo clic en el enlace de chat en la parte inferior derecha de esta página.
SSL.com proporciona una amplia variedad de SSL /TLS certificados de servidor para sitios web HTTPS.
Obtenga asesoramiento de expertos sobre certificados SSL.
Complete el formulario para una consulta.