SSL / TLS 101 para principiantes

Una mirada en profundidad al cifrado que protege nuestras conexiones a Internet

Si bien Netscape inventó originalmente SSL a mediados de los 90, no fue obligatorio que todos los sitios web instalaran un certificado SSL / TLS hasta el verano de 2018, cuando Google comenzó a marcar sitios sin cifrar ".No es seguro."

Si bien Google, con su motor de búsqueda, navegador Chrome y sistema operativo Android, puede redefinir Internet de manera unilateral, no estaba solo en este mandato. Apple, Microsoft, Mozilla y las demás partes interesadas importantes de la industria tecnológica han tomado una decisión concertada para exigir certificados SSL / TLS y HTTPS.

La razón es simple: sin SSL / TLS y sin la capacidad de conectarse de forma segura a través de HTTPS, toda la comunicación entre los sitios web y sus visitantes se intercambiaría en texto plano y un tercero la leería fácilmente.

La única desventaja de este reciente impulso por el cifrado universal es que ha obligado a una afluencia de nuevos clientes a un mercado desconocido, uno que hace muy poco para ser menos confuso para el propietario promedio de un sitio web o negocio.

Este artículo servirá como una guía completa de todo lo relacionado con SSL / TLS, sentaremos las bases repasando conceptos básicos como el cifrado, HTTPS y la naturaleza de las conexiones a Internet.

Con suerte, al final, se sentirá seguro al seleccionar, adquisitivoe implementar un certificado TLS, y recuerde que si tiene alguna pregunta, puede dejarla en los comentarios a continuación.

Foundational Elements

Comencemos discutiendo el concepto que reside en el corazón de todo esto: el cifrado.

El cifrado, en su iteración más sencilla, es poco más que la codificación de datos, utilizando un cifrado o clave predeterminados, de modo que nadie lo pueda leer excepto otra parte con la misma clave privada.

A lo largo de la historia, el cifrado de clave privada ha sido el modelo más utilizado. En el cifrado de clave privada, ambas partes deben poseer o al menos intercambiar una clave privada que se pueda utilizar para cifrar y descifrar información.

Al principio, la mayoría de los cifrados que sustentaban estos criptosistemas eran primitivos y se basaban en sustituciones simples o reemplazaban palabras comunes por caracteres. Pero con el tiempo los cifrados se volvieron más influenciados por las matemáticas y aumentaron en complejidad.

Por ejemplo, a mediados del siglo XVII en Francia, el criptógrafo del rey Luis XIV creó un cifrado que estaba tan bien diseñado que no se rompió hasta 1600 años después y solo entonces parcialmente. Hasta el día de hoy, hay cientos de años de registros en los archivos franceses que quizás nunca se descifren.

Pero mientras que históricamente el cifrado ha sido un medio para ser encubierto o clandestino, el advenimiento de Internet ha hecho que el concepto sea más común. Internet es ubicua y maneja una variedad de funciones críticas. Todos los días, miles de millones de personas lo utilizan para acceder y enviar información confidencial, administrar sus finanzas, realizar transacciones con empresas, lo que sea.

El problema es que Internet no fue diseñado en su totalidad para adaptarse a lo que se ha convertido. Al principio, en los días en que la academia y el gobierno de los EE. UU. desarrollaban por primera vez protocolos de red, Internet solo se veía como un mecanismo para el libre intercambio de información entre el gobierno y las instituciones académicas. En ese momento, la actividad comercial era ilegal en línea. eCommerce no era una palabra que se hubiera inventado todavía. Y el sitio web era más geográfico noción.

Entonces, cuando HTTP o el Protocolo de transferencia de hipertexto se introdujeron por primera vez en 1991, el hecho de que las conexiones que formaba intercambiaran datos en texto plano no fue un problema descalificador.

Las cosas son muy diferentes hoy. La información que se intercambia en línea no es investigación académica o información disponible gratuitamente, es información de identificación personal y datos confidenciales que pueden costar dinero a las personas o incluso, en algunas regiones, sus vidas. Esto requirió un enfoque más seguro.

La respuesta fue el cifrado.

Un problema de intercambio de llaves

Un problema que históricamente ha plagado incluso a los mejores criptosistemas continúa persistiendo hasta el día de hoy.

Lo que discutimos anteriormente, y lo que tradicionalmente ha sido el estándar para el cifrado, es el cifrado de clave privada. Esto también se denomina encriptación simétrica o encriptación bidireccional, con claves privadas que manejan las funciones de encriptación y desencriptación necesarias para comunicarse.

Para que funcione el cifrado de clave privada, la clave privada debe transferirse entre las partes, o ambas partes deben poseer su propia copia. De cualquier manera, la seguridad de la clave privada era fundamental para la integridad del criptosistema y, como sin duda puede suponer, el intercambio de claves es un problema tan antiguo como el cifrado mismo.

Luego, en la década de 1970, técnicamente en dos momentos diferentes, un océano entero aparte, se conceptualizó y dio vida a una nueva forma de cifrado: el cifrado de clave pública.

Mientras que el cifrado de clave privada es una función bidireccional, simétrica, con la clave privada capaz de cifrar y descifrar datos, el cifrado de clave pública es asimétrico; de una sola mano. En lugar de una única clave privada, existe un par de claves pública-privada. La clave pública maneja el cifrado y, como su nombre lo indica, está disponible públicamente, mientras que la clave privada, que maneja el descifrado, se mantiene en secreto por su propietario. Con la clave pública, se puede cifrar un dato y enviarlo al propietario de la clave, donde solo él podrá descifrarlo.

Genial, pero ¿de qué sirve eso?

Bueno, el cifrado unidireccional no es ideal para cifrar las conexiones de Internet, es un poco difícil comunicarse cuando una parte solo puede cifrar y la otra solo puede descifrar. No, para cifrar una conexión a Internet, necesitaría utilizar un cifrado de clave privada simétrica.

Pero, ¿cómo se intercambian las llaves? ¿Especialmente en línea?

Cifrado de clave pública.

Y eso, destilado hasta su esencia misma, es de lo que se trata SSL / TLS: intercambio seguro de claves.

Aquí es donde uniremos todos estos conceptos. Si desea que su comunicación con un sitio web sea privada, debe conectarse de forma segura. Si desea conectarse de forma segura con ese sitio web, debe intercambiar claves privadas simétricas para poder usarlas para comunicarse. SSL / TLS (y PKI en general) es solo un mecanismo elegante para crear e intercambiar esa clave de sesión.

Con SSL / TLS, puede autenticar el servidor u organización con la que está a punto de conectarse y asegurarse de intercambiar de forma segura las claves privadas que utilizará para cifrar su comunicación con la parte destinataria.

Desafortunadamente, SSL / TLS y PKI tienen una gran cantidad de terminología y partes móviles que pueden confundir fácilmente a las personas, pero esos desmienten el hecho de que cuando eliminas todas las matemáticas y la jerga técnica, esta es solo una elegante solución tecnológica moderna para una época. -viejo problema: intercambio de claves.

Ahora repasemos algunos términos clave

Antes de continuar, repasemos un par de otros términos clave. Ya presentamos HTTP, el protocolo de transferencia de hipertexto, que ha sido la columna vertebral de Internet durante décadas. Pero como comentamos, Internet se convirtió en algo muy diferente de lo que era cuando HTTP se publicó por primera vez en 1991.

Se necesitaba un protocolo más seguro. Por lo tanto, HTTPS.

HTTPS, que a veces se denomina HTTP sobre TLS, utiliza encriptación para hacer que los datos que se intercambian durante una conexión sean ilegibles para cualquiera que no sea la parte destinataria. Esto es especialmente importante cuando se considera la naturaleza de una conexión a Internet moderna.

Mientras que en los primeros días de Internet una conexión era razonablemente directa, ahora las conexiones se enrutan a través de docenas de dispositivos en su camino hacia su destino final. Si alguna vez ha querido una demostración práctica de esto, abra el símbolo del sistema en su sistema operativo e ingrese el comando "tracert geekflare.com".

Lo que verá es la ruta que recorrió su conexión de camino a su destino. Hasta 30 saltos. Eso significa que sus datos pasan a través de cada uno de esos dispositivos antes de llegar a cualquier sitio web o aplicación a la que se esté conectando. Y si alguien tiene un rastreador de paquetes o algún oyente instalado en cualquiera de esos dispositivos, puede robar cualquier dato transmitido e incluso manipular la conexión en algunos casos.

A esto se le llama ataque man-in-the-middle (MITM).

Si desea aprender sobre el ataque MITM, entonces mira este curso en línea.

Hay mucha más superficie que cubrir con las conexiones modernas a Internet de lo que la gran mayoría de la gente cree, por lo que tener los datos cifrados durante la transmisión es fundamental. No tiene idea de quién podría estar escuchando, o de lo trivialmente fácil que es hacerlo.

Una conexión HTTP se realiza a través del puerto 80. Para nuestros propósitos, puede pensar en los puertos como construcciones que indican un servicio o protocolo de red. Un sitio web estándar que se sirve a través de HTTP usa el puerto 80. HTTPS generalmente usa el puerto 443. Cuando un sitio web instala un certificado, puede redirigir sus páginas HTTP a HTTPS y los navegadores de los usuarios intentarán conectarse de forma segura a través del puerto 443, pendiente de autenticación.

Desafortunadamente, los términos SSL / TLS, HTTPS, PKI y cifrado se utilizan mucho, a veces incluso se usan indistintamente, por lo que para aclarar cualquier confusión persistente, aquí hay una guía rápida:

• SSL - Secure Sockets Layer, el protocolo de cifrado original utilizado con HTTPS
• TLS - Transport Layer Security, el protocolo de cifrado más reciente que reemplazó a SSL
• HTTPS - La versión segura de HTTP, que se utiliza para crear conexiones con sitios web.
• PKI - Infraestructura de clave pública, se refiere a todo el modelo de confianza que facilita el cifrado de clave pública

SSL / TLS funciona en conjunto para habilitar las conexiones HTTPS. Y PKI se refiere a todo cuando se aleja.

¿Entendido? No te preocupes, lo harás.

Building a Public Key Infrastructure

Ahora que hemos sentado las bases, alejemos y veamos la arquitectura empleada por el modelo de confianza en el corazón de SSL / TLS.

Cuando llega a un sitio web, lo primero que hace su navegador es verificar la autenticidad del certificado SSL / TLS que presenta el sitio. Llegaremos a lo que sucede después de que la autenticación se lleve a cabo en un par de secciones, pero comenzaremos discutiendo el modelo de confianza que hace que todo esto sea posible.

Entonces, comenzaremos planteando la pregunta: ¿Cómo sabe mi computadora si debe confiar en un certificado SSL / TLS determinado?

Para responder a eso, necesitaremos discutir PKI y los diversos elementos que la hacen funcionar. Comenzaremos con las Autoridades de certificación y los programas raíz.

Autoridades de Certificación

Una autoridad de certificación es una organización que cumple con un conjunto de estándares predeterminados a cambio de la capacidad de emitir certificados digitales confiables.

Hay docenas de CA, tanto gratuitos y comercial, que puede emitir certificados de confianza.

Todos deben cumplir con un conjunto de estándares que se ha debatido y legislado a través del CA / Browser Forum, que actúa como el organismo regulador de la industria TLS. Estos estándares describen cosas como:

• Salvaguardias técnicas que deben estar en su lugar
• Mejores prácticas para realizar la validación
• Mejores prácticas de emisión
• Procedimientos de revocación y plazos
• Requisitos de registro de certificados

Estas pautas han sido establecidas por los navegadores, junto con las CA. Los navegadores juegan un papel único en el ecosistema TLS.

Nadie puede acceder a ninguna parte de Internet sin su navegador web. Como tal, es el navegador el que recibirá y validará el certificado TLS digital y luego intercambiará claves con el servidor. Entonces, dado su papel primordial, tienen una influencia considerable.

Y es importante tener en cuenta que los navegadores se han diseñado para ser lo más escépticos posible. No confiar en nada. Esta es la mejor manera de mantener seguros a sus usuarios. Por lo tanto, si un navegador va a confiar en un certificado digital, que potencialmente puede ser mal utilizado en detrimento del usuario, necesita ciertas garantías de que quien emitió este certificado hizo su debida diligencia.

Este es el papel y la responsabilidad de las Autoridades de certificación. Y los navegadores tampoco toleran los errores. Hay un cementerio literal de antiguos CA que han entrado en conflicto con los navegadores y han sido abandonados.

Cuando una autoridad de certificación ha demostrado que cumple con los requisitos básicos de CAB Forum y ha pasado todas las auditorías y revisiones necesarias, puede solicitar a los distintos programas raíz que agreguen sus certificados raíz.

Programas raíz

Un programa raíz (los principales los ejecutan Apple, Microsoft, Google y Mozilla) es el aparato que supervisa y facilita los almacenes raíz (a veces llamados almacenes de confianza), que son colecciones de certificados de CA raíz que residen en el sistema de un usuario. Una vez más, estas raíces son increíblemente valiosas e increíblemente peligrosas; después de todo, pueden emitir certificados digitales confiables, por lo que la seguridad es de suma importancia.

Es por eso que las CA casi nunca emiten directamente desde los propios certificados de CA raíz. En su lugar, generan certificados raíz intermedios y los utilizan para emitir certificados de usuario final o de hoja. También pueden entregar esas raíces a las sub-CA, que son autoridades de certificación que no tienen sus raíces dedicadas pero que aún pueden emitir certificados con firma cruzada de sus intermediarios.

Entonces, juntemos todo esto. Cuando un sitio web desea que se emita un certificado TLS, genera algo llamado Solicitud de firma de certificado (CSR) en el servidor en el que está alojado. En esta solicitud se incluyen todos los detalles que el sitio web desea que se incluyan en el certificado. Como verá más adelante, la cantidad de información puede variar desde detalles comerciales completos hasta una identidad de servidor simple, pero una vez que se completa la CSR, se envía a la Autoridad de Certificación para su emisión.

Antes de emitir el certificado, la CA tendrá que realizar la diligencia debida exigida por la CA / Browser Forum y validar que la información contenida en el CSR sea precisa. Una vez que se ha verificado, firma el certificado con su clave privada y lo envía al propietario del sitio web para su instalación.

Encadenamiento de certificados

Una vez que se ha instalado el certificado TLS, cada vez que alguien visita el sitio, el servidor que lo aloja presentará el certificado al navegador del usuario. El navegador va a mirar la firma digital en el certificado, la que fue realizada por la autoridad certificadora de confianza, lo que da fe de que toda la información contenida en el certificado es precisa.

Aquí es donde entra en juego el término encadenamiento de certificados.

El navegador leerá la firma digital y subirá un enlace en la cadena; luego, verificará la firma digital en el certificado intermedio cuya clave privada se usó para firmar el certificado hoja. Continuará siguiendo firmas hasta que la cadena de certificados termine en una de las raíces confiables en su tienda raíz, o hasta que la cadena termine sin llegar a una raíz, en cuyo caso aparecerá un error del navegador y la conexión fallará.

Es por eso que no puede emitir y autofirmar sus certificados.

Los navegadores solo confiarán en los certificados SSL / TLS que pueden volver a encadenar a su tienda raíz (lo que significa que fueron emitidos por una entidad de confianza). Las Autoridades de Certificación deben cumplir con estándares específicos para mantener su confiabilidad, e incluso entonces los navegadores son reacios a confiar en ellos.

Los navegadores no tienen tales garantías sobre los certificados autofirmados, por lo que solo deben implementarse en redes internas, detrás de firewalls y en entornos de prueba.

SSL/TLS Certificate Types and Functionality

Antes de ver SSL / TLS en movimiento, hablemos de los certificados y las diversas iteraciones que están disponibles. Los certificados TLS son los que facilitan el protocolo TLS y ayudan a dictar los términos de las conexiones HTTPS cifradas que realiza un sitio web.

Anteriormente mencionamos que la instalación de un certificado TLS le permite configurar su sitio web para realizar conexiones HTTPS a través del puerto 443. También actúa como una especie de tarjeta de identificación para el sitio o servidor con el que está interactuando. Volviendo a la idea de que, en esencia, SSL / TLS y PKI son formas exquisitas de intercambio seguro de claves, el certificado SSL / TLS ayuda a notificar al navegador a quién le está enviando la clave de sesión, a quién pertenece la otra parte. la conexión es.

Y cuando desglosa las diversas iteraciones de certificados SSL / TLS, eso es algo pertinente a tener en cuenta. Los certificados varían en cuanto a funcionalidad y nivel de validación. O para decirlo de otra manera, varían según:

• Cuantas identidades afirmar
• En qué puntos finales afirmar la identidad

Responder a estas dos preguntas le dará una indicación bastante clara de qué tipo de certificado necesita.

Cuántas identidades afirmar

Hay tres niveles diferentes de validación disponibles con los certificados SSL / TLS, y varían en función de la cantidad de información de identidad que su sitio web quiera afirmar.

• Certificados SSL de validación de dominio: afirmar la identidad del servidor
• Certificados SSL de validación de la organización: afirmar la identidad parcial de la organización
• Certificados SSL de validación extendida: afirman la identidad completa de la organización

Los certificados SSL de validación de dominio son, con mucho, los más populares debido a su precio y la velocidad con la que se pueden emitir. Los certificados DV SSL / TLS requieren una simple verificación de control de dominio, que se puede lograr de varias formas diferentes, pero tan pronto como sea, se puede emitir el certificado. También puede obtener algunas versiones de 30 y 90 días de estos de forma gratuita, lo que sin duda ha aumentado su cuota de mercado.

La desventaja es que los certificados SSL DV afirman una identidad mínima. Y dado que casi la mitad de todos los sitios web de phishing ahora tienen un certificado SSL DV instalado, no necesariamente compran mucho en términos de confianza.

Los certificados SSL de validación de organización son el tipo original de certificado SSL / TLS. También son el único tipo de certificado SSL que puede asegurar una dirección IP luego de una decisión de 2016 del CAB Forum de invalidar todos los certificados SSL de la intranet. La validación de la organización requiere un examen empresarial ligero y, por lo general, se puede emitir en uno o dos días, a veces más rápido. Los certificados OV SSL afirman cierta información organizativa, pero un usuario de Internet debería hacer clic en el icono del candado y buscarlo. Hoy en día, se ven muchos certificados SSL OV implementados en grandes empresas y redes corporativas, para conexiones realizadas detrás de firewalls, por ejemplo.

Debido a que ni los certificados SSL DV ni OV afirman una identidad suficiente para satisfacer a la mayoría de los navegadores, reciben un trato neutral.

Los certificados SSL de validación extendida son, con mucho, los más controvertidos, ya que algunos en la comunidad tecnológica sienten que se necesita hacer más para fortalecer la validación de la que dependen. Pero, EV SSL afirma la máxima identidad. Para completar la validación extendida, la Autoridad de Certificación somete a la organización a un riguroso proceso de investigación que puede llevar más de una semana en algunos casos.

Pero el beneficio es innegable: debido a que afirma una identidad suficiente, un sitio web con un certificado SSL con EV recibe un tratamiento de navegador único, incluido que su nombre se muestre en la barra de direcciones del navegador.

No hay otra forma de lograr esto, y no se puede fingir: la barra de direcciones EV es uno de los indicadores visuales más potentes que tenemos hoy.

What endpoints to assert Identity on

La otra forma en que varían los certificados SSL / TLS es la funcionalidad. Los sitios web han evolucionado bastante desde los primeros días de Internet con varias empresas que implementan sitios de diferentes maneras. Algunos tienen varios dominios para diferentes verticales de empresas; otros usan subdominios para múltiples funciones y aplicaciones web. Algunos usan ambos.

No importa cuál sea el contexto, existe un certificado SSL / TLS que puede ayudar a protegerlo.

solo dominio

El sitio web principal y el certificado SSL estándar son solo un único dominio. La mayoría de los certificados SSL/TLS modernos protegerán tanto la WWW y no WWW versiones de ese dominio, pero está limitado a un solo dominio. Puede compare los certificados SSL aquí.

Multi dominio

Certificados multidominio o Los certificados de comunicación unificada (en el caso de los servidores de Microsoft Exchange y Office Communications) también existen para dar a las organizaciones la capacidad de cifrar varios dominios con un solo certificado. Esto puede ser un entractive ya que ahorra dinero y simplifica mucho la gestión de los certificados (vencimientos/renovaciones).

Uso de certificados UCC y multidominio SAN, el campo Nombre alternativo del sujeto en el CSR, para agregar dominios adicionales al certificado. La mayoría de las CA permiten hasta 250 SAN diferentes en un solo certificado. Y la mayoría de los certificados multidominio vienen con 2-4 SAN de cortesía y el resto está disponible para su compra según sea necesario.

Certificados SSL comodín

Certificados SSL comodín son un tipo de certificado extremadamente útil porque pueden cifrar un número ilimitado de subdominios en el mismo nivel de la URL. Por ejemplo, si tiene un sitio web que utiliza subdominios como:

• app.sitioweb.com
• portal.sitioweb.com
• usuario.website.com

Puede cifrarlos a todos con el mismo certificado Wildcard utilizando un asterisco en el campo FQDN de su CSR: * .website.com

Ahora, cualquier subdominio, incluso los que aún no ha agregado, se puede proteger con ese certificado.

Sin embargo, hay dos desventajas de los certificados Wildcard. La primera es que al usar la misma clave pública en algunos puntos finales, es más vulnerable a ciertas vulnerabilidades como los ataques Bleichenbacher.

La otra es que no existe la opción EV Wildcard. Debido a la naturaleza abierta de la funcionalidad Wildcard, los navegadores no están de acuerdo con delegarles ese nivel de confianza. Si desea la barra de direcciones EV en sus subdominios, deberá cifrarlos individualmente o usar un certificado EV Multi-Domain.

Comodín multi-dominio

Una adición relativamente nueva al ecosistema SSL / TLS, el comodín multidominio puede cifrar hasta 250 dominios diferentes, pero también puede usar un asterisco en los campos de SAN, lo que también le permite cifrar 250 dominios diferentes Y todos los que lo acompañan primero. -subdominios de nivel.

Otro caso de uso para el comodín multidominio es como un comodín de varios niveles, donde puede cifrar subdominios en varios niveles de la URL (un comodín estándar solo puede cifrarlos en un nivel).

Debido a la funcionalidad de comodín, los comodines multidominio tampoco están disponibles en EV.

SSL/TLS in Motion

Ahora que hemos cubierto todos los conceptos importantes que componen SSL / TLS y PKI, pongámoslo todo junto y veámoslo en movimiento.

Validación y Emisión

Comencemos desde el principio con un sitio web que compra un certificado SSL / TLS de una CA o revendedor. Después de la compra, el contacto de la organización que maneja la adquisición del certificado crea una Solicitud de firma de certificado en el servidor donde se instalará el certificado (el servidor que aloja el sitio web).

Junto con la CSR, el servidor también generará un par de claves pública / privada y guardará la clave privada localmente. Cuando la CA recibe la CSR y la clave pública, realiza los pasos de validación necesarios para garantizar que la información contenida en el certificado sea precisa. Generalmente, para los certificados de autenticación empresarial (no DV), esto implica buscar la información de registro de una organización y los registros públicos en bases de datos gubernamentales.

Una vez que se ha completado la validación, la CA usa una de las claves privadas de uno de sus certificados emisores, generalmente una raíz intermedia, y firma el certificado antes de devolverlo al propietario del sitio.

Ahora, el propietario del sitio web puede tomar el certificado SSL / TLS recién emitido, instalarlo en su servidor y configurar el sitio web para realizar conexiones HTTPS en el puerto 443 (utilizando redireccionamientos 301 para enviar tráfico desde las páginas HTTP preexistentes a sus nuevas contrapartes HTTPS) .

Autenticación y protocolo de enlace SSL

Ahora que el certificado SSL / TLS está instalado y el sitio web se ha configurado para HTTPS, veamos cómo facilitará las conexiones cifradas con los visitantes del sitio.

Al llegar al sitio web, el servidor presentará el certificado SSL / TLS al navegador del usuario. A continuación, el navegador del usuario realiza una serie de comprobaciones.

Primero, va a autenticar el certificado viendo su firma digital y siguiendo la cadena de certificados. También se asegurará de que el certificado no haya caducado y comprobará los registros de Transparencia de certificados (CT) y las Listas de revocación de certificados (CRL). Siempre que la cadena vuelva a una de las raíces en el almacén de confianza del sistema y sea válida, el navegador confiará en el certificado.

Ahora es el momento del apretón de manos.

El protocolo de enlace SSL / TLS es la serie de pasos en los que el cliente (usuario) y el servidor (sitio web) negocian los parámetros de su conexión segura, generan y luego intercambian claves de sesión simétricas.

Primero, se decidirán por un conjunto de cifrado. Una suite de cifrado es el grupo de algoritmos y cifrados que se utilizarán para la conexión. El certificado SSL / TLS proporciona una lista de conjuntos de cifrado que admite el servidor. Generalmente, un conjunto de cifrado incluye un algoritmo de cifrado de clave pública, un algoritmo de generación de claves, un algoritmo de autenticación de mensajes y un algoritmo de cifrado simétrico o masivo, aunque eso se ha perfeccionado en TLS 1.3.

Una vez que se le presente la lista de cifrados admitidos, el cliente elegirá uno aceptable y se lo comunicará al servidor. A partir de ahí, el cliente generará una clave de sesión simétrica, la cifrará con la clave pública y luego la enviará al servidor, que posee la clave privada necesaria para descifrar la clave de sesión.

Una vez que ambas partes tengan una copia de la clave de sesión, puede comenzar la comunicación.

Y eso es SSL / TLS.

Puede ver cómo todos los conceptos que analizamos anteriormente interactúan entre sí para crear un sistema sofisticado pero elegante para asegurar las conexiones a Internet. Utilizamos criptografía de clave pública para intercambiar las claves de sesión de forma segura con las que nos comunicaremos. Se puede confiar en los certificados que afirman la identidad del servidor o de la organización debido a la infraestructura que tenemos entre las distintas CA, navegadores y programas raíz.

Y la comunicación se produce como resultado de un cifrado simétrico de clave privada que es descendiente de los criptosistemas clásicos de la antigüedad.

Hay muchas partes móviles, pero cuando disminuyes la velocidad y las entiendes todas individualmente, es mucho más fácil ver cómo funcionan todas juntas.

Antes de ir, terminemos con algunos movimientos relacionados con SSL / TLS que puede realizar después de la instalación / configuración para aprovechar al máximo su inversión.

After SSL/TLS – Getting the most out of your implementation

Simplemente tener un certificado instalado y tener su sitio web configurado correctamente no significa que su sitio web sea seguro. TLS es solo un componente de una estrategia de defensa cibernética más amplia y holística. Pero un componente importante, no obstante. Veamos algunas cosas que puede hacer para asegurarse de aprovechar al máximo la implementación.

Deshabilitar el soporte del servidor para protocolos antiguos

Volviendo a la conversación que tuvimos anteriormente sobre las suites de cifrado, parte de la configuración de su servidor es decidir qué suites de cifrado y versiones de SSL / TLS admitir. Es imperativo que desactive la compatibilidad con versiones anteriores de SSL / TLS, así como algoritmos específicos para prevenir la vulnerabilidad a varios exploits conocidos.

SSL 2.0 y SSL 3.0 tienen más de 20 años. La mejor práctica fue desaprobar el soporte para ellos hace años, pero hasta el día de hoy, alrededor del 7% de los 100,000 principales de Alexa todavía los permiten. Esto es peligroso porque lo expone a ataques de eliminación y degradación de SSL como POODLE.

TLS 1.0 y TLS 1.1 también están en tiempo prestado.

Las principales empresas de tecnología, Apple, Microsoft, Google y Mozilla, hicieron un anuncio conjunto este otoño de que desaprobarán el soporte para TLS 1.0 y 1.1 a principios de 2020.

Las versiones del protocolo son susceptibles a vulnerabilidades como POODLE, FREAK, BEAST y CRIME (todos estos son acrónimos). TLS 1.2 ha estado disponible durante diez años y debería ser el estándar. TLS 1.3 se finalizó el verano pasado y la adopción se ha estado moviendo a un ritmo constante desde entonces.

Además, existen algoritmos específicos que tampoco deben utilizarse. DES, por ejemplo, se puede romper en cuestión de horas. RC4 es más vulnerable más de lo que se creía y ya ha sido prohibido por los Estándares de seguridad de datos de la industria de tarjetas de pago. Y finalmente, dadas las noticias de exploits recientes, ya no es recomendable usar RSA para el intercambio de claves.

Algoritmos / cifrados sugeridos:

• Intercambio de claves: curva elíptica Diffie-Helman (ECDH)
• Autenticación: algoritmo de firma digital de curva elíptica (ECDSA)
• Cifrado simétrico / masivo: AES 256 en modo de contador Galois (AES256-GCM)
• Algoritmo MAC: SHA-2 (SHA384)

SSL siempre activo

En el pasado, los sitios web a veces solo migraban las páginas web que recopilaban información a HTTPS, mientras prestaban servicio al resto del sitio a través de HTTP. Esta es una mala práctica.

Además del hecho de que Google marcará esas páginas como "No seguras", también está exponiendo potencialmente a los visitantes de su sitio al riesgo al hacer que sus navegadores salten de un lado a otro entre páginas cifradas y HTTP.

Debería configurar todo su sitio web para HTTPS. Esto se llama SSL siempre activo. Después de todo, no es como si estuviera pagando por página, su certificado SSL / TLS puede encriptar todo su sitio. Así que hazlo así.

Configurar un registro de autorización de la autoridad de certificación (CAA)

Uno de los riesgos más importantes que plantean los certificados digitales, en general, es la emisión incorrecta. Si una parte que no sea usted obtiene un certificado SSL / TLS para SU sitio web, pueden hacerse pasar por usted y causar todo tipo de problemas.

Los registros CAA ayudan a mitigar este riesgo al restringir qué Autoridades de certificación pueden emitir certificados digitales para su sitio web. Las Autoridades de Certificación son requeridas por CA / Browser Forum para verificar los registros de CAA antes de emitir cualquier certificado. Si la CA no tiene la autorización para emitir para ese sitio, no puede. Hacerlo se consideraría una emisión errónea y provocaría la ira de la comunidad de navegadores.

Agregar un registro CAA es relativamente fácil, es un registro DNS simple que se puede agregar a través de la interfaz de la mayoría de las plataformas de alojamiento. Puede restringir las CA que pueden emitir para su dominio, así como si también se pueden emitir certificados Wildcard para él.

Agregue su sitio web a la lista de precarga de HSTS

HTTP Strict Transport Security, o HSTS, es un encabezado HTTP que obliga a los navegadores a realizar conexiones HTTPS con un sitio determinado. De esta manera, incluso si el usuario web intenta ir a la versión HTTP de la página, solo terminará visitando la versión HTTPS. Eso es importante porque cierra la ventana a varios exploits conocidos, como ataques de degradación y secuestro de cookies.

Desafortunadamente, un pequeño vector de ataque permanece con HSTS, por lo que debe agregar su sitio web a la lista de precarga. Por lo general, cuando un visitante llega a su sitio web, su navegador descargará el encabezado HTTP y luego lo cumplirá durante el tiempo que se haya establecido la política para que dure. Pero en esa primera visita, antes de que se reciba el encabezado, todavía hay una pequeña apertura para un atacante.

Google ejecuta la lista de registro de precarga de HSTS y algunos de los principales navegadores utilizan algunas variaciones. Esos navegadores solo saben cómo conectarse a través de HTTPS a cualquier sitio web que esté en la lista, incluso si nunca antes se ha visitado allí. Es posible que su sitio tarde una o dos semanas en aparecer en la lista debido al hecho de que las actualizaciones de la lista se eliminan junto con los programas de lanzamiento de los navegadores.

Puede consultar la siguiente guía de implementación.

¿Cómo implementar SSL en Apache Tomcat?

¿Cómo implementar un certificado ZeroSSL en Apache y Nginx?

¿Cómo implementar SSL en WordPress en alojamiento compartido, nube?

SSL/TLS FAQ

¿Qué es un certificado X.509?

X.509 se refiere al tipo de certificado digital que se utiliza con SSL / TLS y otros tipos de PKI. X.509 es un estándar de cifrado de clave pública. Ocasionalmente, verá que las empresas utilizan el certificado X.509 en lugar de "certificado digital" o "certificado PKI".

¿Por qué caducan los certificados SSL / TLS?

Hay dos razones para esto.

La primera es que Internet cambia continuamente, los sitios web aparecen y los sitios web desaparecen. Y dado lo sensibles que son los navegadores a la hora de confiar en estos certificados, en primer lugar, quieren saber que los sitios web que presentan los certificados se someten a validaciones periódicas. No es tan diferente de cómo ocasionalmente tiene que registrarse para actualizar la información de su licencia de conducir.

La otra razón es más técnica. Es más difícil multiplicar las actualizaciones y los cambios técnicos cuando los certificados no caducan en 3-5 años. Considerando que, si los certificados vencen cada 24 meses, el período más largo que cualquier certificado podría estar desactualizado es de dos años. En 2017, la validez máxima se redujo de tres años a dos. Es probable que se reduzca a 12 meses en breve.

¿Cómo se renueva un certificado SSL / TLS?

La renovación puede ser un nombre poco apropiado porque está reemplazando el certificado anterior por uno recién emitido. Hacer esto con regularidad le permite mantenerse actualizado con los nuevos avances con la tecnología de cifrado y garantiza que su información de validación se mantenga actualizada. Las CA solo pueden reutilizar la información de validación que se proporcionó inicialmente durante tanto tiempo antes de que los requisitos de línea de base las obliguen a volver a validarla.

Cuando está renovando, puede mantener el mismo tipo de certificado que tenía antes, o puede optar por algo nuevo, incluso puede cambiar las CA. Lo importante es la cantidad de tiempo que le queda en el certificado que vence; puede transferirlo hasta tres meses. Siempre que renueve antes de que expire el certificado, puede transferir el tiempo restante y reutilizar cualquier información de validación que no haya expirado desde su última validación. Si dejas que caduque, empiezas de cero.

¿Qué es la inspección HTTPS?

A muchas empresas más grandes con redes más grandes les gusta tener visibilidad sobre su tráfico. En ese sentido, HTTPS es un arma de doble filo. Protege la privacidad de las personas, pero también puede ayudar a los ciberdelincuentes a esconderse. Muchas organizaciones descifrarán su tráfico HTTPS en un dispositivo periférico o en un middlebox y luego lo enviarán en texto plano detrás de su firewall o lo volverán a cifrar y lo enviarán en su camino. Cuando no vuelve a cifrar el tráfico, se denomina Terminación SSL. Cuando vuelve a cifrar, eso se llama puente SSL.

¿Qué es la descarga SSL?

La descarga de SSL es otra práctica empresarial. A escala, realizar miles de apretones de manos y luego cifrar y descifrar todos esos datos puede afectar los recursos de una red. Por lo tanto, muchas redes más grandes descargarán las funciones de SSL a otro dispositivo para que el servidor de aplicaciones pueda concentrarse en sus tareas principales. A veces, esto se denomina equilibrio de carga.

¿Por qué mi CA me envió un certificado intermedio?

¿Recuerdas antes cuando hablamos de los programas raíz?

Very OS tiene un almacén raíz que utiliza para realizar juicios de confianza de PKI. Pero las CA no emiten certificados de usuario final a partir de esas raíces por temor a lo que sucedería si alguna vez tuvieran que ser revocado. En cambio, hacen girar raíces intermedias y las emiten. El problema es que esas raíces intermedias no residen en el almacén de confianza de un sistema.

Por lo tanto, si el sitio web no presenta el certificado intermedio junto con el certificado SSL / TLS de hoja, muchos navegadores no podrán completar la cadena de certificados y emitirán una advertencia. Algunos navegadores almacenan en caché los certificados intermedios, pero aún se considera una mejor práctica instalar cualquier intermediario junto con su certificado hoja.

¿Qué documentación necesito para un certificado SSL de validación extendida?

En la mayoría de los casos, la autoridad certificadora que realiza la validación extendida primero intentará acceder a la información a través de recursos de “autoridad gubernamental” disponibles públicamente.

Sin embargo, en algunos lugares, esto podría no ser posible. Sin embargo, hay algunas cosas que pueden ayudar a acelerar la validación. Si bien el número de comprobaciones de validación que puede satisfacer una carta de opinión profesional se ha reducido recientemente, tener un abogado o contador en regla puede ayudar considerablemente.

Además, puede proporcionar una credencial comercial emitida por el gobierno o un documento de “Prueba de derecho” que le otorgue a su organización el derecho a hacer negocios con el nombre indicado. Algunos ejemplos de estos documentos son:

• Articulos de incorporación
• Certificados de formación
• Licencias comerciales / de proveedores / comerciantes
• Documentos de la carta
• Acuerdos de asociación
• Registro de comercio o nombre supuesto
• Registro Mercantil

Palabras de clausura

Espero que esto le dé una idea sobre SSL / TLS. Si está interesado en aprender más, le recomendaría tomando este curso en línea.

Esta publicación fue una contribución de Patrick Nohe, editor de Hashed Out por The SSL Store, un blog que cubre noticias y tendencias de ciberseguridad.