SSL/TLS 101 para principiantes

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

Aunque Netscape inventó originalmente el SSL a mediados de los 90, no se hizo obligatorio que todos los sitios web instalaran un certificado SSL/TLS hasta el verano de 2018, cuando Google empezó a marcar los sitios sin cifrar como «No seguros«

Aunque Google -con su motor de búsqueda, su navegador Chrome y su sistema operativo Android- puede redefinir Internet unilateralmente, no estaba solo en este mandato. Apple, Microsoft, Mozilla y el resto de los principales actores de la industria tecnológica han tomado la decisión concertada de exigir certificados SSL/TLS y HTTPS.

La razón es sencilla: sin SSL/TLS y la posibilidad 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 sería fácilmente legible por un tercero.

El único inconveniente de este reciente impulso hacia el cifrado universal es que ha forzado una afluencia de nuevos clientes a un mercado desconocido, que hace muy poco por resultar menos confuso para el propietario medio de un sitio web o de una empresa.

Este artículo servirá como guía exhaustiva 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.

Esperemos que al final se sienta seguro a la hora de seleccionar, comprar e implementar un certificado TLS, y recuerde que si tiene alguna pregunta puede dejarla en los comentarios a continuación.

Elementos fundamentales

Empecemos hablando del concepto que reside en el corazón de todo esto: la encriptación.

La encriptación, en su iteración más directa, es poco más que la codificación de datos -utilizando un cifrado o clave predeterminada- para que sean ilegibles para cualquiera excepto para otra parte que disponga de 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 pueda utilizarse tanto para cifrar como para descifrar información.

Al principio, la mayoría de los cifrados en los que se basaban estos criptosistemas eran primitivos y se basaban en simples sustituciones o en la sustitución de palabras comunes por caracteres. Pero con el paso del tiempo los cifrados se vieron más influidos por las matemáticas y crecieron en complejidad.

Por ejemplo, a mediados del siglo XVI en Francia, el criptógrafo del rey Luis XIV creó un cifrado tan bien diseñado que no fue descifrado hasta 250 años después y sólo parcialmente. A día de hoy hay registros de cientos de años en los archivos franceses que quizá nunca puedan descifrarse.

Pero mientras que históricamente la encriptación ha sido un medio para estar encubierto o ser clandestino, la llegada de internet ha llevado el concepto a un ámbito más general. Internet es omnipresente y maneja una serie de funciones críticas. Cada día, miles de millones de personas la utilizan para acceder y enviar información sensible, gestionar sus finanzas, realizar transacciones con empresas… lo que se le ocurra.

El problema es que Internet no se diseñó en su totalidad para escalar a lo que se ha convertido. Al principio, en los días en que el mundo académico y el gobierno de EE.UU. desarrollaban por primera vez protocolos de red, internet sólo se veía como un mecanismo para el libre intercambio de información entre el gobierno y las instituciones académicas. En aquel momento, la actividad comercial era ilegal en la red. El comercio electrónico ni siquiera era una palabra que se hubiera inventado todavía. Y sitio web era más bien una noción geográfica.

Así que, cuando se introdujo por primera vez el HTTP o Protocolo de Transferencia de Hipertexto en 1991, el hecho de que las conexiones que formaba intercambiaran datos en texto plano no era un problema descalificante.

Hoy las cosas son muy diferentes. La información que se intercambia en línea no es investigación académica o información de libre acceso, es información personal identificable y datos sensibles que pueden costar dinero a la gente o incluso, en algunas regiones, sus vidas. Esto exigía un enfoque más seguro.

La respuesta fue la encriptación.

Un problema de intercambio de claves

Un problema que históricamente ha plagado incluso a los mejores criptosistemas sigue persistiendo en la actualidad.

Lo que hemos discutido antes, y lo que ha sido tradicionalmente el estándar para la encriptación, es la encriptación de clave privada. También se denomina cifrado simétrico o cifrado bidireccional, en el que las claves privadas se encargan de las funciones de cifrado y descifrado necesarias para comunicarse.

Para que la encriptación de clave privada funcione, la clave privada debe transferirse entre las partes, o ambas partes deben poseer su propia copia. En cualquier caso, 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 la propia encriptación.

Entonces, en la década de 1970 -técnicamente dos épocas diferentes, con todo un océano de diferencia- se conceptualizó y se dio vida a una nueva forma de encriptación: la encriptación de clave pública.

Mientras que la encriptación de clave privada es una función bidireccional, simétrica, con la clave privada capaz tanto de encriptar como de desencriptar datos, la encriptación de clave pública es asimétrica; unidireccional. En lugar de una única clave privada, existe un par de claves pública-privada. La clave pública se encarga del cifrado y está, como su nombre indica, a disposición del público, mientras que la clave privada, que se encarga del descifrado, es mantenida en secreto por su propietario. Utilizando la clave pública, uno puede cifrar un dato y enviarlo al propietario de la clave, donde sólo él podrá descifrarlo.

Genial, pero ¿en qué es útil?

Bueno, la encriptación unidireccional no es ideal para encriptar conexiones a internet, es algo difícil comunicarse cuando una parte sólo puede encriptar, y la otra sólo puede desencriptar. No, para encriptar una conexión a internet, necesitaría utilizar una encriptación simétrica, de clave privada.

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

Cifrado de clave pública.

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

Aquí es donde uniremos todos estos conceptos. Si quiere que su comunicación con un sitio web sea privada, entonces necesita conectarse a él de forma segura. Si quiere conectarse de forma segura con ese sitio web, entonces necesita intercambiar claves privadas simétricas para poder utilizarlas para comunicarse. SSL/TLS (y PKI en general) no es más que un mecanismo elegante para crear e intercambiar esa clave de sesión.

Utilizando SSL/TLS, puede autenticar el servidor o la organización con la que se va a conectar y asegurarse de que intercambia de forma segura las claves privadas que utilizará para cifrar su comunicación con la parte deseada.

Desgraciadamente, SSL/TLS y PKI tienen mucha terminología y partes móviles que pueden confundir fácilmente a la gente, pero éstas desmienten el hecho de que cuando se despoja de todas las matemáticas y la jerga técnica, se trata simplemente de una elegante solución tecnológica moderna a un problema antiguo: el intercambio de claves.

Repasemos ahora algunos términos clave

Antes de seguir adelante, repasemos un par de términos clave. Ya hemos introducido el HTTP, protocolo de transferencia de hipertexto, que ha sido la columna vertebral de internet durante décadas. Pero como ya hemos comentado, internet evolucionó hasta convertirse en algo muy diferente de lo que era cuando se publicó por primera vez el HTTP en 1991.

Se necesitaba un protocolo más seguro. Así surgió HTTPS.

HTTPS, que a veces se denomina HTTP sobre TLS, utiliza el cifrado para hacer que los datos que se intercambian durante una conexión sean ilegibles para cualquiera que no sea la parte a la que van destinados. Esto es especialmente importante si se tiene en cuenta la naturaleza de una conexión moderna a Internet.

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 de camino a 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 introduzca el comando «tracert geekflare.com/es»

Lo que verá es el camino que recorrió su conexión de camino a su destino. Hasta 30 saltos. Eso significa que sus datos pasan por 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 escuchador instalado en cualquiera de esos dispositivos, puede robar cualquier dato transmitido e incluso manipular la conexión en algunos casos.

Es lo que se denomina un ataque man-in-the-middle (MITM).

Si quiere aprender sobre el ataque MITM, consulte 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 eso es fundamental que los datos estén encriptados durante la transmisión. No tiene ni idea de quién podría estar escuchando, ni 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 utiliza el puerto 80. HTTPS suele utilizar 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.

Por desgracia, los términos SSL/TLS, HTTPS, PKI y cifrado se utilizan mucho, a veces incluso indistintamente, así que para aclarar cualquier confusión persistente, he aquí una guía rápida:

• SSL – Secure Sockets Layer, el protocolo de cifrado original utilizado con HTTPS
• TLS – Transport Layer Security (Seguridad de la capa de transporte), el protocolo de cifrado más reciente que ha sustituido a SSL
• HTTPS – La versión segura de HTTP, utilizada 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 funcionan conjuntamente para permitir las conexiones HTTPS. Y PKI se refiere a todo el conjunto cuando se aleja.

¿Lo ha entendido? No se preocupe, lo hará.

Construir una infraestructura de clave pública

Ahora que hemos sentado las bases, alejémonos 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 el sitio le presenta. En un par de secciones hablaremos de lo que ocurre después de esa autenticación, pero vamos a empezar hablando del modelo de confianza que hace posible todo esto.

Así pues, empezaremos planteando la siguiente pregunta: ¿cómo sabe mi ordenador si debe confiar en un certificado SSL/TLS determinado?

Para responderla, tendremos que hablar de la PKI y de los distintos elementos que la hacen funcionar. Empezaremos por 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 una serie de normas predeterminadas a cambio de poder emitir certificados digitales de confianza.

Existen docenas de CA, tanto gratuitas como comerciales, que pueden emitir certificados de confianza.

Todas ellas deben atenerse a un conjunto de normas que ha sido debatido y legislado a través del Foro CA/Browser, que actúa como organismo regulador de la industria TLS. Estas normas describen aspectos como:

• Salvaguardas técnicas que deben existir
• Mejores prácticas para realizar la validación
• Mejores prácticas de emisión
• Procedimientos y plazos de revocación
• Requisitos de registro de certificados

Estas directrices han sido establecidas por los navegadores, junto con las CA. Los navegadores desempeñan un papel único en el ecosistema TLS.

Nadie puede llegar a ningún sitio en Internet sin su navegador. Como tal, es el navegador el que recibirá y validará el certificado digital TLS y luego intercambiará claves con el servidor. Así que, dado su papel primordial, su influencia es considerable.

Y es importante tener en cuenta que los navegadores han sido diseñados para ser lo más escépticos posible. Para no fiarse de nada. 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 actuó con la diligencia debida.

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 antiguas CA que han tenido problemas con los navegadores y han sido puestas en la calle.

Cuando una autoridad de certificación ha demostrado su conformidad con los requisitos básicos del Foro CAB y ha superado todas las auditorías y revisiones necesarias, puede solicitar a los distintos programas raíz que se añadan sus certificados raíz.

Programas raíz

Un programa raíz -los principales están dirigidos por 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 – pueden emitir certificados digitales de confianza, después de todo – por lo que la seguridad es de máxima preocupación.

Por eso las CA casi nunca emiten directamente los certificados de la propia CA raíz. En su lugar, crean certificados raíz intermedios y los utilizan para emitir certificados de usuario final o de hoja. También pueden ceder esas raíces a las sub-AC, que son autoridades de certificación que no tienen sus raíces dedicadas pero que pueden emitir certificados con firma cruzada a partir de sus intermedios.

Así pues, unamos 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. Esta solicitud contiene todos los detalles que el sitio web desea que se incluyan en el certificado. Como verá dentro de un momento, la cantidad de información puede variar desde detalles comerciales completos hasta una simple identidad del servidor, pero una vez completada la CSR, se envía a la Autoridad de Certificación para su emisión.

Antes de emitir el certificado, la CA tendrá que hacer su diligencia debida exigida por el Foro CA/Browser y validar que la información contenida en la CSR es exacta. Una vez verificado esto, firma el certificado con su clave privada y lo envía de vuelta al propietario del sitio web para su instalación.

Encadenamiento de certificados

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

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

El navegador va a leer la firma digital y a subir un eslabón en la cadena: a continuación, comprobará la firma digital del certificado intermedio cuya clave privada se utilizó para firmar el certificado hoja. Va a continuar siguiendo las firmas hasta que la cadena de certificados termine en una de las raíces de confianza de su almacén 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á.

Esta es la razón por la que no puede emitir y autofirmar sus certificados.

Los navegadores sólo confiarán en los certificados SSL/TLS que puedan encadenar hasta su almacén raíz (lo que significa que han sido emitidos por una entidad de confianza). Las autoridades de certificación están obligadas a cumplir unas normas específicas para mantener su fiabilidad, e incluso así los navegadores se resisten a confiar en ellas.

Los navegadores no tienen esas garantías sobre los certificados autofirmados, razón por la cual sólo deben desplegarse en redes internas, detrás de cortafuegos y en entornos de prueba.

Tipos de certificados SSL/TLS y funcionalidad

Antes de ver SSL/TLS en movimiento, hablemos de los certificados y de las distintas iteraciones que hay 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.

Antes hemos mencionado que la instalación de un certificado TLS le permite configurar su sitio web para que realice conexiones HTTPS a través del puerto 443. También actúa como una especie de distintivo del nombre del sitio o servidor con el que está interactuando. Volviendo a la idea de que, en el fondo, SSL/TLS y PKI son todas formas exquisitas de intercambio seguro de claves, el certificado SSL/TLS ayuda a notificar al navegador a quién está enviando la clave de sesión, quién es la parte al otro lado de la conexión.

Y cuando se desglosan las distintas iteraciones de los certificados SSL/TLS, esto es algo pertinente a tener en cuenta. Los certificados varían en cuanto a funcionalidad y nivel de validación. O dicho de otro modo, varían en función de:

• Cuántas identidades afirmar
• En qué puntos finales afirmar la identidad

Responder a esas dos preguntas le dará una indicación bastante clara del tipo de certificado que 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 cuánta información de identidad quiera hacer valer su sitio web.

• Certificados SSL de validación de dominio – Afirman la identidad del servidor
• Certificados SSL con validación de organización – Afirman la identidad parcial de la organización
• Certificados SSL con Extended Validation – Afirman la identidad completa de la organización

Los certificados SSL con validación de dominio son, con diferencia, los más populares debido a su precio y a la rapidez con la que pueden emitirse. Los certificados SSL/TLS de DV requieren una simple comprobación de control de dominio, que puede realizarse de varias formas diferentes, pero en cuanto se realiza el certificado puede ser emitido. También puede obtener gratuitamente algunas versiones de 30 y 90 días, lo que sin duda ha aumentado su cuota de mercado.

El inconveniente es que los certificados SSL de DV afirman una identidad mínima. Y dado que casi la mitad de todos los sitios web de phishing tienen ahora un certificado SSL DV instalado en ellos, no necesariamente le compran mucho en el camino de la confianza.

Los certificados SSL con 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 tras la decisión de 2016 del Foro CAB de invalidar todos los certificados SSL de intranet. La validación de organización requiere un examen empresarial ligero y normalmente puede emitirse en uno o dos días, a veces más rápido. Los certificados SSL OV afirman cierta información organizativa, pero un usuario de Internet tendría que hacer clic en el icono del candado y buscarla. Hoy en día se ven muchos certificados SSL OV desplegados en grandes redes empresariales y corporativas, para conexiones realizadas detrás de cortafuegos, por ejemplo.

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

Los certificados SSL con Extended Validation son, con diferencia, los más controvertidos, ya que algunos miembros de la comunidad tecnológica consideran que hay que hacer más para reforzar la validación de la que dependen. Sin embargo, los SSL con EV afirman al máximo la identidad. Para completar la validación ampliada, 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: al afirmar la identidad suficiente, un sitio web con un certificado SSL con EV recibe un tratamiento único en el navegador, que incluye que su nombre aparezca en la barra de direcciones del navegador.

No hay otra forma de conseguir esto, y no se puede falsificar: la barra de direcciones EV es uno de los indicadores visuales más potentes que tenemos hoy en día.

En qué puntos finales afirmar la identidad

La otra forma en que varían los certificados SSL/TLS es en cuanto a su funcionalidad. Los sitios web han evolucionado bastante desde los primeros días de Internet, con varias empresas desplegando sitios de diferentes maneras. Algunas tienen múltiples dominios para diferentes verticales de la empresa; otras utilizan subdominios para múltiples funciones y aplicaciones web. Algunas utilizan ambos.

Sea cual sea el contexto, existe un certificado SSL/TLS que puede ayudarle a protegerlo.

Dominio único

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

Multidominio

Los certificadosmultidominio o los certificados de comunicación unificada (en el caso de los servidores Microsoft Exchange y Office Communications) también existen para ofrecer a las organizaciones la posibilidad de cifrar varios dominios con un único certificado. Esta puede ser una opción atractiva, ya que ahorra dinero y hace que la gestión de los certificados (caducidades/renovaciones) sea mucho más sencilla.

Los certificados multidominio y UCC utilizan SAN, el campo Nombre alternativo del sujeto en la CSR, para añadir 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, pudiendo adquirir el resto según sus necesidades.

Certificados SSL comodín

Los certificados SSLcomodí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.website.com
• portal.sitioweb.com
• usuario.sitioweb.com

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

Ahora cualquier subdominio, incluso los que aún no haya añadido, puede protegerse con ese certificado.

Sin embargo, los certificados Wildcard tienen dos inconvenientes. La primera es que al utilizar la misma clave pública en algunos puntos finales, es más vulnerable a ciertos exploits como los ataques Bleichenbacher.

El otro 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 en delegarles ese nivel de confianza. Si desea la barra de direcciones EV en sus subdominios, tendrá que cifrarlos individualmente o utilizar un certificado EV Multidominio.

Comodín multidominio

Una adición relativamente nueva al ecosistema SSL/TLS, el Multi-Domain Wildcard puede cifrar hasta 250 dominios diferentes, pero también puede utilizar un asterisco en los campos SANs, lo que también le permite cifrar 250 dominios diferentes Y todos los subdominios de primer nivel que los acompañan.

Otro caso de uso del Multi-Domain Wildcard es como Wildcard multinivel, donde puede cifrar subdominios en varios niveles de la URL (un Wildcard estándar sólo puede cifrarlos en un nivel).

Debido a la funcionalidad Wildcard, los Multi-Domain Wildcards tampoco están disponibles en EV.

SSL/TLS en movimiento

Ahora que hemos cubierto todos los conceptos significativos que conforman SSL/TLS y PKI, vamos a ponerlo todo junto y verlo en movimiento.

Validación y emisión

Empecemos por el principio, con un sitio web que compra un certificado SSL/TLS a una CA o a un revendedor. Tras la compra, el contacto de la organización que gestiona 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 asegurarse de que la información contenida en el certificado es exacta. Por lo general, en el caso de 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 las bases de datos gubernamentales.

Una vez completada la validación, la CA utiliza una de las claves privadas de uno de sus certificados emisores, normalmente una raíz intermedia, y firma el certificado antes de devolvérselo al propietario del sitio web.

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 que realice conexiones HTTPS en el puerto 443 (utilizando redireccionamientos 301 para enviar el tráfico de las páginas HTTP preexistentes a sus nuevas contrapartes HTTPS).

Autenticación y el Handshake 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 realizará una serie de comprobaciones.

En primer lugar, autenticará el certificado viendo su firma digital y siguiendo la cadena del certificado. También se asegurará de que el certificado no ha caducado y comprobará los registros de Transparencia de Certificados (CT) y las Listas de Revocación de Certificados (CRL). Siempre que la cadena conduzca a una de las raíces del almacén de confianza del sistema y que sea válida, el navegador confiará en el certificado.

Ahora es el momento del apretón de manos.

El apretón de manos 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.

En primer lugar, decidirán un conjunto de cifrado. Un conjunto 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 esto se ha refinado en TLS 1.3.

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

Una vez que ambas partes disponen de 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 hemos repasado antes interactúan entre sí para crear un sistema sofisticado pero elegante para asegurar las conexiones a Internet. Utilizamos la criptografía de clave pública para intercambiar de forma segura las claves de sesión con las que nos comunicaremos. Los certificados que afirman la identidad del servidor o de la organización son de confianza gracias a la infraestructura que tenemos establecida entre las distintas CA, los navegadores y los programas raíz.

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

Hay un montón de piezas móviles, pero cuando se va más despacio y se comprenden todas individualmente, es mucho más fácil ver cómo funciona todo junto.

Antes de irnos, terminemos con algunos movimientos relacionados con SSL/TLS que puede hacer después de la instalación/configuración para sacar el máximo partido a su inversión.

Después de SSL/TLS – Sacar el máximo partido a su implementación

El mero hecho de tener un certificado instalado y de que su sitio web esté configurado correctamente no significa que su sitio web sea seguro. TLS es sólo un componente de una estrategia de ciberdefensa más amplia y holística. Pero un componente importante, no obstante. Vamos a cubrir algunas cosas que puede hacer para asegurarse de que está sacando el máximo provecho de la implementación.

Desactive la compatibilidad del servidor con protocolos antiguos

Volviendo a la conversación que tuvimos antes sobre suites de cifrado, parte de la configuración de su servidor consiste en decidir qué suites de cifrado y versiones SSL/TLS va a soportar. Es imperativo que deshabilite el soporte de versiones SSL/TLS antiguas así como de algoritmos específicos para evitar la vulnerabilidad a varios exploits conocidos.

Tanto SSL 2.0 como SSL 3.0 tienen más de 20 años. La mejor práctica era dejar de darles soporte hace años, pero a día de hoy alrededor del 7% de las 100.000 primeras páginas de Alexa siguen permitiéndolos. Esto es peligroso porque le expone a ataques de SSL stripping y downgrade como POODLE.

TLS 1.0 y TLS 1.1 también están de prestado.

Las principales empresas tecnológicas, Apple, Microsoft, Google y Mozilla, anunciaron conjuntamente este otoño que dejarán de dar soporte a TLS 1.0 y 1.1 a principios de 2020.

Estas versiones del protocolo son susceptibles de sufrir vulnerabilidades como las de POODLE, FREAK, BEAST y CRIME (todas ellas son acrónimos). TLS 1.2 lleva diez años en el mercado y debería ser el estándar. TLS 1. 3 se finalizó el verano pasado y su adopción ha avanzado a un ritmo constante desde entonces.

Además, hay algoritmos específicos que tampoco deberían utilizarse. DES, por ejemplo, puede romperse en cuestión de horas. RC4 es más vulnerable de lo que se creía y ya ha sido proscrito por los Estándares de Seguridad de Datos de la Industria de Tarjetas de Pago. Y por último, dadas las noticias de recientes exploits, ya no es aconsejable utilizar RSA para el intercambio de claves.

Algoritmos/cifradores sugeridos:

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

SSL siempre activo

En el pasado, los sitios web a veces sólo han migrado las páginas web que recopilan información a HTTPS, mientras servían el resto del sitio a través de HTTP. Esta es una mala práctica.

Además de que Google marcará esas páginas como «No seguras», también está exponiendo potencialmente a los visitantes de su sitio a un riesgo al hacer que sus navegadores salten una y otra vez entre las páginas cifradas y las HTTP.

Debería configurar todo su sitio web para HTTPS. Esto se denomina SSL siempre activo. Después de todo, no es que esté pagando por página, su certificado SSL/TLS puede cifrar todo su sitio. Así que hágalo.

Configure un registro de autorización de autoridad de certificación (CAA)

Uno de los riesgos más importantes que plantean los certificados digitales, en general, es la emisión errónea. Si a alguien que no es usted se le emite un certificado SSL/TLS para SU sitio web, puede hacerse pasar por usted y causar todo tipo de problemas.

Los registros CAA ayudan a mitigar este riesgo restringiendo qué Autoridades de Certificación pueden emitir certificados digitales para su sitio web. Las Autoridades de Certificación están obligadas por el Foro CA/Browser a comprobar los registros CAA antes de emitir cualquier certificado. Si la CA no tiene autorización para emitir para ese sitio, no puede hacerlo. Hacerlo se consideraría una emisión errónea y provocaría la ira de la comunidad de navegadores.

Añadir un registro CAA es relativamente fácil, es un simple registro DNS que puede añadirse 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 el mismo.

Añada su sitio web a la lista de precarga HSTS

HTTP Strict Transport Security, o HSTS, es una cabecera HTTP que obliga a los navegadores a realizar únicamente conexiones HTTPS con un sitio determinado. De esta forma, aunque el internauta intente ir a la versión HTTP de la página, sólo acabará visitando la versión HTTPS. Esto es importante porque cierra la ventana a varios exploits conocidos, como los ataques de downgrade y el secuestro de cookies.

Por desgracia, queda un pequeño vector de ataque con HSTS, por lo que debería añadir su sitio web a la lista de precarga. Normalmente, cuando un visitante llega a su sitio web, su navegador descargará el encabezado HTTP y luego lo mantendrá durante el tiempo que se haya establecido que dure la política. Pero en esa primera visita, antes de que el encabezado haya sido recibido, todavía existe una pequeña abertura para un atacante.

La lista de registro de precarga HSTS es ejecutada por Google y alguna variación de la misma utilizada por los principales navegadores. Esos navegadores sólo saben conectarse a través de HTTPS a cualquier sitio web que esté en la lista, aunque nunca lo haya visitado antes. Su sitio puede tardar una o dos semanas en aparecer en la lista, debido a que las actualizaciones de la lista se publican junto con los calendarios 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 o en la nube?

PREGUNTAS FRECUENTES SOBRE SSL/TLS

¿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 certificado X.509 en lugar de «certificado digital» o «certificado PKI»

¿Por qué caducan los certificados SSL/TLS?

Hay dos razones para ello.

La primera es que Internet cambia continuamente, los sitios web vienen y los sitios web van. 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 los presentan se someten a validaciones periódicas. No es muy diferente de cómo de vez en cuando tiene que comprobar para actualizar la información de su permiso de conducir.

La otra razón es más técnica. Es más difícil que proliferen las actualizaciones y los cambios técnicos cuando los certificados no caducan hasta pasados 3-5 años. En cambio, si los certificados caducan cada 24 meses, lo máximo que puede estar caducado un certificado son dos años. En 2017, la validez máxima se redujo de tres a dos años. Es probable que en breve se reduzca a 12 meses.

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

Renovar puede ser un poco equívoco porque está sustituyendo el certificado antiguo por uno recién emitido. Hacerlo con regularidad le permite estar al día de los nuevos avances de la tecnología de cifrado y garantiza que su información de validación se mantiene actualizada. Las CA sólo pueden reutilizar la información de validación suministrada inicialmente durante cierto tiempo antes de que los requisitos básicos les obliguen a revalidarla.

A la hora de renovar, puede mantener el mismo tipo de certificado que tenía antes o puede optar por algo nuevo, incluso puede cambiar de CA. Lo importante es cuánto tiempo le queda del certificado que caduca: puede prorrogarlo hasta tres meses. Siempre que renueve antes de que caduque el certificado, podrá prorrogar el tiempo restante y reutilizar cualquier información de validación que no haya caducado desde su última validación. Si deja que caduque, empezará de cero.

¿Qué es la inspección HTTPS?

A muchas empresas 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 descifran su tráfico HTTPS en un dispositivo periférico o una caja intermedia y luego lo envían en texto plano detrás de su cortafuegos o lo vuelven a cifrar y lo envían de vuelta. Cuando no se vuelve a cifrar el tráfico, se denomina Terminación SSL. Cuando sí lo vuelve a cifrar, se denomina puenteo SSL.

¿Qué es la descarga SSL?

La descarga SSL es otra práctica empresarial. A escala, realizar miles de handshakes y luego cifrar y descifrar todos esos datos puede gravar los recursos de una red. Por eso, muchas redes grandes descargarán las funciones SSL a otro dispositivo para que el servidor de aplicaciones pueda centrarse en sus tareas principales. Esto se denomina a veces equilibrio de carga.

¿Por qué mi CA me ha enviado un certificado intermedio?

¿Recuerda que antes hablamos de los programas raíz?

Todos los sistemas operativos tienen un almacén raíz que utilizan para realizar juicios de confianza PKI. Pero las CA no emiten certificados de usuario final a partir de esas raíces por miedo a lo que ocurriría si alguna vez hubiera que revocar uno. En su lugar, crean raíces intermedias y emiten certificados a partir de ellas. El problema es que esas raíces intermedias no residen en el almacén de confianza de un sistema.

Así que, si el sitio web no presenta el certificado intermedio junto con el certificado SSL/TLS de la hoja, muchos navegadores no podrán completar la cadena de certificados y emitirán una advertencia. Algunos navegadores sí almacenan en caché los certificados intermedios, pero se sigue considerando la mejor práctica instalar cualquier intermedio junto con su certificado hoja.

¿Qué documentación necesito para un certificado SSL con Extended Validation?

En la mayoría de los casos, la autoridad de certificación que realiza la validación ampliada intentará primero acceder a la información a través de los recursos de «autoridad gubernamental» disponibles públicamente.

Sin embargo, en algunos lugares, esto puede no ser posible. Sin embargo, hay algunas cosas que pueden ayudar a acelerar la validación. Aunque el número de comprobaciones de validación que puede satisfacer una Carta de Opinión Profesional se ha reducido recientemente, hacer que un abogado o contable en regla firme una puede seguir siendo de gran ayuda.

Además, puede proporcionar una credencial comercial emitida por el gobierno o un documento de «prueba de derecho» que otorgue a su organización el derecho a hacer negocios bajo el nombre listado. Algunos ejemplos de estos documentos son

• Artículos de Incorporación
• Certificados de constitución
• Licencias de empresa/proveedor/comerciante
• Documentos constitutivos
• Acuerdos de asociación
• Registro de nombre comercial o supuesto
• Registro Mercantil

Observaciones finales

Espero que esto le haya dado una idea sobre SSL/TLS. Si está interesado en aprender más, le recomiendo que siga este curso en línea.

Este artículo ha sido escrito por Patrick Nohe, editor de Hashed Out by The SSL Store, un blog sobre noticias y tendencias en ciberseguridad.