Todo sobre el HTTPS

Siempre que se estudia un tema, es de buena costumbre empezar por la definición de lo que estamos estudiando y, en este caso, también debemos aclarar que son esas siglas, que en realidad son muchísimas.
HTTP

HTTPSon las siglas en inglés de Hypertext Transfer Protocol, cuya traducción al español es protocolo de transferencia de hipertexto, es el protocolo usado en cada transacción de laWorld Wide Web, WWW o Web, es decir, define la manera de cómo se comunica el servidor con la información y el programa cliente que accede a ella y la muestra al usuario. Por tanto, este protocolo pertenece a la familia de protocolos usados en Internet. Usa por defecto el puerto 80.

El HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, que en 1999 publicaron una serie de normas, una de las más importante es la RFC 2616 que especifica la versión 1.1. de HTTP y define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura Web entre clientes, servidores y proxies para comunicarse. Un año después se publica el RFC2774 que especifica la versión 1.2 del HTTP.

Al cliente que efectúa la petición, por ejemplo un navegador Web, se lo conoce como user agent, o agente del usuario. A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos, URL. Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc.

Comunicaciones HTTPEl protocolo HTTP no tiene memoria, es decir, que no guarda ninguna información sobre conexiones anteriores. Su forma de trabajar es simple, se pide un recurso y muestra ese recurso igual que las otras veces anteriores. Con el paso del tiempo se desarrollaron aplicaciones Web que necesitaban mantener el estado o la memoria de las conexiones anteriores. Para ésto se usan las cookies, que es información que un servidor almacena en el ordenador o el teléfono del cliente, en el user agent. Ésto le permite a las aplicaciones Web crear lo que se llama sesión de usuario, mostrar la información pedida en la forma que anteriormente se ha configurado para ese cliente, y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Ejemplo de un diálogo HTTP

Para obtener un recurso con el URL: http://www.dominio.com/index.html

1.- Se abre una conexión al host, que es el espacio de disco duro de un servido conectado a Internet destinado a este dominio, www.dominio.com en el puerto 80.

2.- Se envía un mensaje de la forma siguiente:

GET /index.html HTTP/1.1

Host: www.dominio.com

User-Agent: Mozilla Firefox

[Línea en blanco]

La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una página Web:

HTTP/1.1 200 OK

Date: Fri, 31 Dec 2003 23:59:59 GMT

Content-Type: text/html

Content-Length: 1221

<html>

<body>

Página principal de www.dominio.com

(Contenido)

.

.

.

</body>

</html>
Mientras el navegador está recibiendo la información del servidor remoto ya es capaz de ir interpretándola, en caso de que sea una página Web, puede ir construyéndola para mostrárnosla al usuario.

HTTPS

Hypertext Transfer Protocol Secure es un protocolo de comunicación HTTP seguro a través de una red informática como Internet. Técnicamente, no es un protocolo en sí mismo, sino que es el resultado de la unión del protocolo SSL/TLS en el encabezado y del HTTP en el contenido, de esta manera se le da seguridad, en concreto en la privacidad y en la autenticidad, cosa que el protocolo HTTP por sí mismo no proporciona. Una diferencia entre ambos protocolos es que HTTP usa el puerto 80 y HTTPS usa el puerto 443.

HTTP no es seguroHTTPS es seguro más seguro
 

SSL/TLS

Secure Sockets Layer, en español: Capa de Conexión Segura y su sucesor Transport Layer Security, TLS, en español: Seguridad de la Capa de Transporte; son protocolos criptográficos que proporcionan comunicaciones seguras en una red insegura, por ejemplo Internet.

HTTP frente a HTTPSEl protocolo SSL es una herramientas criptográficas para proporcionar autenticación y privacidad punto a punto de la información que circula sobre Internet. Habitualmente solo se autentifica el servidor mientras que el cliente se mantiene sin autenticar. Ésto es así pues lo que importa es la información que tiene el servidor, por ejemplo el de un banco, y por tanto, la parte sensible es el servidor del banco que es el que tiene la información de las cuentas del usuario. Para evitar dar esa información a personas no autorizadas, el servidor del banco pide que se autentifique mediante usuario y contraseña.

Podemos diferenciar varias fases en el protocolo SSL:

  • – Negociar entre servidor y navegador el algoritmo que se usará en la comunicación.
  • – Intercambio de claves públicas y de autenticación basadas en certificados digitales.
  • – Cifrado del tráfico, se suele utilizar un cifrado simétrico pues es mucho más rápido que los de clave pública.

Durante la primera fase de la comunicación, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones más actuales proporcionan los siguientes algoritmos, entre otros:

  • – Para criptografía de clave pública se puede usar: RSA, Diffie-Hellman, DSA o Fortezza.
  • – Para cifrado simétrico: RC2, RC4, IDEA, DES, Triple DES y AES.
  • – Para las funciones de resumen o hash: MD5 o alguno de la familia SHA.

Antes de que un cliente y el servidor pueden empezar a intercambiar información protegida por estos protocolos, deben acordar una clave de cifrado. Entre los métodos utilizados para el acuerdo de claves están: las claves públicas y privadas generadas con RSA, Diffie-Hellman, llamado TLS_DH; Diffie-Hellman efímero, denotado TLS_DHE; Diffie-Hellman de Curva Elíptica, denotado TLS_ECDH; Diffie-Hellman de Curva Elíptica efímero, TLS_ECDHE; Diffie-Hellman anónimo, TLS_DH_anon; y PSK, también denominado TLS_PSK.

Los certificados de clave pública que se utilizan durante el acuerdo también varían en el tamaño de las claves de cifrado públicas/privadas utilizadas durante el intercambio y, por tanto, en la solidez de la seguridad que proporcionan el protocolo. Como ejemplo ilustrativo podemos decir que en julio de 2013, Google anunció que dejaría de utilizar claves públicas 1024 bits y cambiaría a claves de 2048 bits para aumentar la seguridad de la encriptación TLS que proporciona a sus usuarios, pues esa longitud se había mostrado débil.

Existen dos razones principales para querer usar los protocolos SSL/TLS, la primera y posiblemente la más común, es para el comercio electrónico y poder aceptar pagos con tarjeta de crédito. Si el sitio Web maneja transacciones comerciales, en donde se trasmitan datos de tarjetas de crédito, cualquier banco y sus asociados exigirán el uso de certificados de seguridad, incluso ésto está estandarizado como PCI DSS, Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago. Es requerido por sistemas bancarios y de pago como: Visa, MasterCard, American Express, etc.

La segunda razón es para mantener segura la información confidencial que maneja el sitio Web, normalmente se usa para proteger los inicios de sesión y evitar que los nombres de usuario y contraseñas sean transmitidos en texto plano, visible a todo el que mire. Ésto también se aplica en caso de que un sitio Web ofrezca servicios de correo, en donde datos de carácter personal son usados diariamente por los usuarios. Hoy en día, con el auge de los servicios en la nube se están implementando mucho más los certificados de seguridad para poder garantizar la confidencialidad e integridad de la información.

Funcionamiento

Podemos decir que los protocolos SSL/TLS intercambian registros, opcionalmente estos registros o algunos de ellos puede ser: comprimido, cifrado y empaquetado con un código de autenticación del mensaje, que se puede denominar MAC,Message Authentication Code, Código de Autenticación del Mensaje. Cada registro tiene un campo de content_type que especifica el protocolo que se está usando.

Cuando se inicia la conexión servidor-cliente, se encapsula otro protocolo, el protocolo handshake o protocolo de acuerdo, que tiene el content_type 22.

El cliente envía y recibe varias estructuras handshake:

  • – Envía un mensaje denominado ClientHello, presentación del cliente, especificando una lista de algoritmos de cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida por el cliente. Éste también envía bytes aleatorios, llamados Challenge de Cliente o Reto, que serán usados más tarde. Además puede incluir el identificador de la sesión.
  • – Recibe un registro denominado ServerHello, presentación del servidor, en el que el servidor elige los parámetros de conexión a partir de las opciones ofertadas con anterioridad por el cliente.
  • – Cuando los parámetros de la conexión quedan establecidos, cliente y servidor intercambian certificados que dependen de las claves públicas de cifrado seleccionadas. Estos certificados son actualmente X.509.
  • – Cliente y servidor negocian una clave secreta simétrica llamada master secret. Todos los datos de claves restantes son calculados a partir de esta master secret y los valores aleatorios generados en el cliente y el servidor, que son pasados a través una función pseudoaleatoria cuidadosamente elegida.

SSL/TLS poseen una variedad de medidas de seguridad:

  • – Numera todos los registros y usa el número de secuencia en el MAC, código de autenticación del mensaje.
  • – Usa un resumen de mensaje mejorado con la master secret de forma que solo con dicha clave se pueda comprobar el MAC. Ésto se especifica en el RFC 2104.
  • – Protección contra varios ataques conocidos, incluyendo ataques man-in-the-middle, como los que implican un degradado del protocolo a versiones previas y, por tanto, menos seguras, o conjuntos de cifrados más débiles.
  • – El mensaje que finaliza el protocolo handshake Finished envía un hash de todos los datos intercambiados y vistos por ambas partes.
  • – La función pseudoaleatoria divide los datos de entrada en 2 mitades y los procesa con algoritmos hash diferentes: MD5 y SHA, después realiza sobre ellos una operación XOR. De esta forma se protege a sí mismo de la eventualidad de que alguno de estos algoritmos se revelen vulnerables en el futuro.

Comunicación SSLTLS es un protocolo de dos capas, que son: TLS Record Protocol y una capa superior compuesta por protocolos que son encapsulados por la capa de registro:Handshake, Alert Protocol, Change cipher Spec y Application protocol.

El protocolo de registro, Record Protocol, se implementa sobre la capa TCP. Este protocolo encapsula protocolos de más alto nivel, como el HandShake Protocol.

Fundamentalmente se encarga de tomar los mensajes a ser transmitidos, fragmenta los datos en bloques manejables, opcionalmente comprime los datos, aplica una MAC, cifra y transmite el resultado. El dato recibido es desencriptado, verificado, descomprimido y reensamblado, entregándose a los clientes en niveles más altos.

Handshake

El protocolo de Handshake es el que permite a las dos partes autenticarse mutuamente y negociar el cifrado antes de intercambiar datos. Negocia y establece la conexión.

Se pueden dar tres modalidades de Handshake a la hora de establecerse la comunicación entre el cliente y servidor:

  • Handshake completo: Tanto el servidor como el cliente se intercambian certificados.
  • Handshake simple: Solo el servidor y no el cliente se autentica con entrega de su certificado.
  • Handshake resumido: Debido a que las operaciones con clave pública, generalmente con RSA, son costosas computacionalmente, TLS incorpora un modo resumido para evitar esas operaciones del handshake completo. En el establecimiento de una conexión el servidor y cliente intercambian un id de sesión que el cliente asociará con la IP y puerto del servidor de modo que cuando el cliente se reconecte usará ese id. El servidor comprobará que tiene en caché ese id de sesión ofrecido por el cliente y en ese caso puede decidir retomar la conexión con los parámetros ya negociados anteriormente u ofrecer un nuevo id obligando a realizar de nuevo un handshake completo. Como se puede entender, es un método que no conviene usar muy repetidamente pues estamos reutilizando las misma claves de cifrado y con ello estamos dando más oportunidades de criptoanálisis a un tercero que capture el tráfico.
Detalle de un Handshake simple
  • ClientHello. El cliente envía un mensaje ClientHello al servidor especificando una lista de conjunto de cifrados, Cipher Suites; métodos de compresión, Compression Methods, y la versión del protocolo SSL más alta permitida. Éste también envía bytes aleatorios que serán usados más tarde, llamados Challenge de Cliente o Reto. Además puede incluir un identificador no nulo de la sesión si quiere intentar retomar una sesión establecida con anterioridad. Si el Id es nulo se renegocia handshake completo.
  • – ServerHello. El servidor contesta al cliente escogiendo una opción de las ofrecidas, enviando id de sesión, versión, compresión y un número aleatorio, random, que se usará con el de cliente en la creación de la clave simétrica.
  • – Certificate. Ofrece su certificado. Este puede contener clave pública para el cifrado o ser un certificado de firma con lo será necesario el paso 4 para enviar una clave pública firmada.
  • – ServerKeyExchange. Este mensaje se envía sólo si el anterior mensaje no incluye clave pública para el cifrado escogido. Con este mensaje el servidor ofrece para el cifrado asimétrico entre cliente y servidor la clave pública firmada con la clave del Certificate. De esta forma se separa la autenticación del cifrado. Lo más común es que el Certificate sea un certificado de autenticación de servidor que incluya la clave pública de cifrado.
  • – ServerHello Done. El servidor da por concluida su fase de negociación asimétrica.
  • – ClientKeyExchange. El cliente tras haber comprobado y validado el certificado, genera el premaster secret con 48 bytes, 2 bytes de la versión SSL y 46 aleatorios, que será el elemento secreto compartido que junto a otros datos intercambiados previamente, como son: random, id de servidor y cliente; darán lugar a un mismo master secret en la parte servidor y en la del cliente y que será la clave simétrica utilizada para cifrar los datos. El premaster secret es cifrado con la clave pública del servidor y enviada. De este modo sabemos que solo el servidor legítimo puede descifrarlo y generar el master secret de la sesión.
  • – ChangeCipherSpec. Con este mensaje el cliente informa que los sucesivos mensajes estarán cifrados con el cifrado y clave acordados.
  • – Finished. El cliente da por finalizada su handshake. El mensaje que finaliza el Handshake incluye un hash de todos los mensajes de handshake que garantiza la integridad de la comunicación.
  • – ChangeCipherSpec. El servidor tras verificar que todo ha ido correctamente, en base al hashing MAC, descifra con su clave privada el premaster secret enviado por el cliente en el paso 6 y genera el master secret del mismo modo que el cliente. En este momento cliente y servidor han logrado establecer una clave simétrica y acordado un cifrado. Con este mensaje el servidor indica que sus mensajes desde este momento se cifran.
  • – Finished. El servidor finaliza el handshake…

El canal seguro SSL/TLS ya está creado, a partir de este momento todos los datos serán cifrados y se usa el protocolo HTTP para la transmisión del recurso. Un recurso ilegible para todos, excepto para las dos partes implicadas en su creación. O eso es lo que pretenden estos protocolos aunque ya veremos que no siempre lo consiguen.

Certificados de seguridad SSL/TLS

Para usar el protocolo SSL se necesita un certificado SSL/TLS, tanto el protocolo como los certificados mismos forman parte de SSL. Este certificado debe estar instalado en el servidor y debe tener una dirección IP fija y los visitantes deben usar un navegador que soporte este protocolo y los certificados usados, que en la actualidad son casi todos los navegadores, por lo menos en sus últimas versiones.

Los certificados SSL/TLS deben ser emitidos por un certificado raíz, de una Autoridad de Certificación, AC, que sea de confianza. Este certificado raíz debe estar presente en el ordenador del usuario para que el certificado SSL sea de confianza, en caso contrario, el navegador mostrará un mensaje advirtiendo que el sitio Web presenta un certificado pero no es de confianza.

Ahora bien, este tipo de alertas no necesariamente dice que el sitio Web no es de confianza, es decir, que es una amenaza, simplemente que el navegador no reconoce su certificado de seguridad. Por ejemplo, si creamos un certificado SSL/TLS que se puede hacer con OpenSSL, y este certificado ha sido emitido por un desconocido, por muy robusto y seguro que sea éste, los navegadores Web no lo reconocerán y mostrarán una ventana de advertencia. En un sitio Web de carácter personal ésto quizás no sea un problema, pero en un portal comercial podría generar cierta desconfianza en los clientes y perder una venta.

Existen diferentes tipo de certificados SSL/TLS que se pueden usar en un sitio Web, básicamente todo dependerá de las necesidades, gustos y capacidad monetaria que se tenga, pero principalmente dependerá de las necesidades.

Certificados compartidos (Shared Certificates)

Estos certificados por lo general son gratuitos, y son dados para empresas de alojamiento Web como los revendedores o en otros caso pueden ser generados de forma personal, usando OpenSSL por ejemplo, o a través de algún servicio que preste un sitio Web. Cumplen su función, pero el hecho de ser compartidos no los relaciona directamente con el nombre de dominio del sitio Web, ésto provocará los mensajes de alerta de los que hablábamos antes.

Certificados de validación de nombre de dominio (Domain Validated Certificate)

Éstos son los certificados SSL más básicos, se enfocan en validar solo el nombre de dominio, dominio.com. Es ideal para situaciones en las que los visitantes del sitio necesitan acceder a zonas seguras, bien sea para trasmitir datos personales, como: nombre de usuario, contraseña, email, etc. A diferencia de los certificados compartidos, éstos no serán objeto de mensajes de advertencia por parte de los navegadores.

Certificados de validación de compañías (Company Validated Certificate)

Estos certificados son muy similares a los de validación de dominios, la diferencia es que para estos certificados es necesario validar datos de la propia compañía y no solo su dominio. Más validación, más seguridad. Una compañía que use este tipo de certificado de seguridad, no sólo está validando su dominio, sino también su empresa. Ésto genera mayor confianza a sus clientes. Es una cuestión de reputación y prestigio para la empresa.

Certificado de validación extendido (Extended Validation Certificates – EV)

Estamos ante la élite de los certificados. El proceso de verificación es aún mayor, se necesitarán verificar una buena cantidad de datos, tanto del sitio Web como de la empresa que lo administra, incluyendo cuestiones jurídicas. Tanto los requerimiento como los procedimientos son minuciosos.

La barra verde en la barra de direcciones del navegador es exclusiva de este certificado. Les asegura a los visitantes que están ante una empresa/organización validada y asegurada. Además, un sitio protegido mediante este certificado hace que los navegadores Web muestren el nombre de la organización junto a la barra de direcciones en color verde y al nombre de la autoridad de certificación que lo emitió. El navegador y la autoridad de certificación controlan la visualización, lo que hace que las técnicas de phishing sean más difíciles de aplicar.

Certificados Wildcard (Wildcard Certificates)

Estos certificados permiten usar un único certificado SSL para ser usado en múltiples subdominios. Por ejemplo, el certificado será usado para dominio.com, compras.dominio.com, contacto.dominio.com, etc.

Certificados Multi-dominio (Multi-Domain Certificates)

Éstos son similares a los Wildcard, la diferencia es que en este caso son usados para dominios y no subdominios. Por ejemplo, el certificado será usado para dominio.com, dominio.net, dominio.org, etc.

La comunicación del certificado

Cuando el navegador hace una petición al sitio Web, éste envía un mensaje donde indica que quiere establecer una conexión segura y envía datos sobre la versión del protocolo SSL/TLS que soporta y otros parámetros necesarios para la conexión, como se ha mostrado arriba.

En base a esta información enviada por el navegador, el servidor del sitio Web responde con un mensaje informando que está de acuerdo en establecer la conexión segura con los datos de SSL/TLS proporcionados.

Una vez que ambos conocen los parámetros de conexión, el sitio Web presenta su certificado digital al navegador para identificarse como un sitio confiable.

Verificación de validez del certificado

Una vez que el navegador tiene el certificado del sitio Web, realiza algunas verificaciones antes de confiar en el sitio:

  • – Integridad del certificado: Verifica que el certificado se encuentre íntegro, ésto lo hace descifrando la firma digital incluida en él mediante la llave pública de la Autoridad Certificadora, AC, y comparándola con una firma del certificado generada en ese momento, si ambas son iguales entonces el certificado es válido.
  • – Vigencia del certificado: Revisa el periodo de validez del certificado, es decir, la fecha de emisión y la fecha de espiración incluidos en él.
  • – Verifica emisor del certificado: Hace uso de una lista de Certificados Raíz almacenados en el ordenador y que contienen las llaves públicas de las ACs conocidas y de confianza. Puedes acceder a esta lista desde las opciones avanzadas del navegador.
  • – Con base a esta lista, el navegador revisa que la AC del certificado sea de confianza, de no serlo, el navegador mostrará una advertencia indicando que el certificado fue emitido por una entidad en la cual no confía.

Sigan leyendo sobre este tema en la siguiente página donde se detallan los Ataques al protocolo HTTPS.

Deja una respuesta

Tu e-mail no será publicado. Los campos requeridos están marcados con *