Todo lo que necesitas saber para migrar tu web a HTTPS

Escrito por Ramón Saquete

Desde que Google anunció en 2014 que el uso de HTTPS iba a favorecer al SEO, muchas webs lo están implantando. Pero, ¿sabes realmente qué es el Hypertext Transfer Protocol Secure?, ¿realmente es seguro para ti y tus visitantes?, ¿te has preguntado alguna vez si tu web lo necesita?, ¿sabes qué debes hacer para contratarlo?, y sobre todo, ¿sabes cómo hacer la migración a HTTPS para que afecte lo mínimo posible al SEO? Encontrarás las respuestas a estas cuestiones y muchas más si sigues leyendo.

¿Qué es HTTPS?

Imagínate que en el proceso de enviar una carta intervienen cinco personas: la primera escribe el contenido de la carta y una serie de datos adicionales en la cabecera que indican cosas relativas a ese contenido, como el tamaño del mismo, su fecha, el idioma, etc. A esta persona le podemos poner el “extraño nombre” de HTTP emisor.
HTTP emisor le pasa la carta a la segunda persona (SSL emisor o TLS emisor), que se encarga de cifrar el contenido sustituyendo unas letras por otras.

Seguidamente, SSL o TLS le pasa la carta a la tercera persona (TCP emisor) que, entre otras cosas, parte la carta en trozos y los numera porque al cartero no le gusta llevar cartas muy grandes.

A continuación, TCP emisor le va dando cada trozo de la carta al señor IP emisor, que coge cada trozo y lo mete en un sobre donde escribe la dirección de destino y el remitente.

Por último, IP emisor le entrega cada sobre a la quinta y última persona, que se podría llamar Ethernet, PPP, … que asigna cada carta al buzón más cercano para que el cartero se encargue de llevarla a destino.

La carta al llegar a destino sigue el proceso inverso, es decir, el señor Ethernet receptor recoge las cartas, se las pasa a IP receptor que saca los trozos de los sobres y se los da a TCP receptor que los va recomponiendo. Después, el SSL receptor descifra el contenido y por último un HTTP receptor mira las cabeceras para saber cómo tiene que interpretar dicho contenido.

Como ya te habrás dado cuenta, si en esta descripción cambias persona por protocolo de comunicación y carta por documento HTML, lo que tienes es el funcionamiento del protocolo HTTPS. El funcionamiento del protocolo HTTP sería exactamente igual pero eliminando el protocolo SSL/TLS.
En la siguiente imagen ilustro gráficamente el viaje de este documento HTML, donde el emisor y el receptor pueden ser, respectivamente, el servidor de la web y el navegador o viceversa:

HTTPS, consigue tres mejoras respecto a HTTP:

• 1ª. Toda la información viaja cifrada entre el servidor de la web y los clientes.
• 2ª. Nadie puede modificar la información interceptándola durante el envío a su destino.
• 3ª. El dominio de la web queda autentificado, es decir, tu página web tendrá una firma digital que demostrará ante los que quieran navegar por ella que es tu dominio y es realmente de tu empresa.

Nos adentraremos en cada punto más adelante.

¿Por qué deberías usarlo en tu web?

Aunque hay usuarios que no se fijan si la web tiene o no HTTPS y la mayoría de los que se fijan sólo conocen su utilidad para enviar datos cifrados, eso ya es suficiente para generar confianza en tu sitio, lo cual es muy importante en los e-commerce o en cualquier web donde se le pidan datos personales al usuario.

Por otro lado, como ya he comentado al principio, Google dijo:

HTTPS es un factor que afecta levemente al posicionamiento y es posible que aumente su importancia

¿Por qué no deberías usarlo en tu web?

Porque afecta negativamente al tiempo de carga de la página (aunque no demasiado), ya que tiene que establecer el método de cifrado en la primera conexión y tiene que cifrar y descifrar datos.

Al poner HTTPS, todas las URLs de nuestro sitio web cambiarán, con lo que afectará temporalmente al posicionamiento, ya que tendremos que hacer redirecciones y perdemos los «me gusta» en redes sociales. Así que, si tenemos un blog y no recopilamos datos de usuarios, puede que no nos compense la pequeña mejora en el SEO dado que puede no sea apreciable por la pérdida de rendimiento.

¿Cómo funciona el cifrado?

HTTPS usa dos algoritmos de cifrado, uno de clave pública llamado RSA y otro de clave privada (normalmente AES o 3DES). El primero se usa para transmitir de forma cifrada la clave del segundo que es más rápido de utilizar, pero como no quiero aburriros con explicaciones sobre criptografía y matemáticas discretas, si queréis profundizar un poco más podéis leer éste artículo que escribí sobre RSA.

Lo importante que debéis saber es que el cifrado de clave pública, que se usa para proteger la información, también se usa para realizar la firma digital que verifica que vuestro dominio os pertenece. Si tuviese que hacer una comparación en el mundo real, es como si hubieseis firmado ante un notario que vuestro dominio pertenece a vuestra empresa y todos los usuarios de vuestra web hubiesen estado presentes para dar fe del acto. A este «notario» se le llama autoridad certificadora, o en inglés, Certification Authority (CA), que son empresas que venden certificados SSL de firma digital, necesarios para tener HTTPS, y son los que más os van a cobrar a la hora de contratar este servicio con vuestro proveedor de hosting. Aquí puede ser que el proveedor de hosting os ofrezca certificados de una CA con la que tenga acuerdos, o que os permita poner certificados que hayáis comprado directamente vosotros a alguna otra CA. En este último caso os saltaríais un intermediario, pero ello no implica que, en todos los casos, os resulte más barato.

¿Qué tipo de certificado SSL elegir?

Hay varias clasificaciones para los certificados:

Según el número de dominios

• De un solo dominio: como sólo se puede tener un certificado por IP, si tenemos otro dominio en el mismo servidor y queremos ponerle también HTTPS, tendremos que comprar otro certificado y otra IP.
• Multidominio: con un solo certificado podemos tener HTTPS en varias webs alojadas en el mismo servidor bajo la misma IP.
• Comodín o wildcard: son certificados que sirven para todos los subdominios de un dominio. Por ejemplo si queremos tener https://midominio.com y https://www.midominio.com, ya que tenemos la intención de redirigir https://midominio.com al subdominio https://www.midominio.com, con un certificado wildcard sólo necesitaremos un certificado y una IP, mientras que con un certificado de un solo dominio necesitaremos dos de cada.

Autofirmados

• Un certificado autofirmado es aquel que firmamos nosotros mismos asegurando que la web es nuestra. Este tipo de certificados no cuestan nada y se usan para hacer pruebas o para entrar de forma segura a servicios que vamos a usar sólo nosotros. Los navegadores muestran estos certificados con una alerta de seguridad:
  

Certificados firmados por una CA, según el tipo de validación

El tipo de validación hace referencia a la cantidad de burocracia necesaria para validar que nuestra empresa realmente tiene el dominio:

• Validación de dominio: con este tipo de validación no te hacen preguntas, sólo verifican que sea un dominio válido. Muchas autoridades certificadoras no ofrecen este servicio porque no conlleva ningún tipo de seguridad, al pasar la validación fácilmente. En el otro extremo tenemos la relativamente reciente CA Let’s Encrypt que ofrece certificados gratuitos de este tipo, esto es algo que ya están aprovechando los hackers. Algunos navegadores muestran estos certificados con un candado gris y otros con un candado verde, en la barra de navegación.
• Validación de negocio u organización: este tipo de validación es más exhaustiva. Tienes que demostrar que posees una empresa dando los datos de razón social, gerente, confirmación de que el dominio te pertenece respondiendo a un email que te suelen mandar al administrador del dominio y todo aquello que pida la CA. Los navegadores muestran este tipo de certificados con un candado verde:
• Validación extendida: en este tipo de validación piden aún más información y hacen comprobaciones más exhaustivas, como que la dirección física de la empresa coincide con la dirección dada para el dominio. También es el tipo de validación más cara por lo que solo lo suelen usar bancos o entidades importantes. Este tipo de validación se muestra con un candado verde y el nombre de la empresa validada. Además, si pinchamos en el candado podemos ver más información de la empresa:

Otras características

• Cantidad de bits de la clave pública RSA: cuantos más bits más seguro es el certificado. Google recomienda certificados de clave pública de 2048 bits como mínimo.
• Tipo de algoritmo de hash para la firma: es un algoritmo que se usa para «trocear» la firma y hacerla ilegible. Aquí hay que tener en cuenta que SHA1 está obsoleto desde el 1 de Enero de 2017 y el navegador puede mostrar un aviso:
  

Se recomienda que el certificado use alguna variante de SHA-2 como SHA-256.

• Tipo de algoritmo de cifrado para la clave privada: puede ser AES o 3DES (DES está obsoleto). Se recomienda AES porque es más rápido y que tenga como mínimo 128 bits
• Compatibilidad con los navegadores: este es un punto que todas las CA suelen cumplir, pero no está demás que digan que son compatibles con el 99% de los navegadores. El 100% es imposible ya que puede haber navegadores muy antiguos con los que no lo sean.

Podemos encontrar casi cualquier combinación de estas características en los certificados que ofrecen las autoridades certificadoras. Por ejemplo, podemos tener un certificado que sea multidominio, wildcard y con validación extendida, todo al mismo tiempo.

Algunas autoridades certificadoras famosas son GeoTrust, Verisign, Thawte, Comodo, Symantec, etc. Pero también hay algunos revendedores que ofrecen certificados baratos y la gratuita Let’s Encrypt (su software de gestión de automática de certificados no está actualmente disponible para servidores Windows). Así que ya sabéis, poner en Google «SSL certificate» o algo similar y ya podéis poneros a comparar certificados y precios que se ajusten a vuestras necesidades y presupuesto. El precio para un dominio suele estar aproximadamente entre los 40 € y los 300 € al año.

¿Qué se debe tener en cuenta de cara al SEO para no perder tráfico en una migración?

• Redirecciones 301: se deben redireccionar todas las URLs con http a su versión con https. Teniendo en cuenta todas las posibilidades, por ejemplo, para el dominio https://www.midominio.com serían recomendables todas estas redirecciones:
  • • http://www.midominio.com -> https://www.dominio.com
    • https://midominio.com -> https://www.dominio.com (para esta redirección es necesario tener certificado para midominio.com, ya que la redirección ocurre después de que se valide el HTTPS)
    • http://midominio.com -> https://www.dominio.com
• Etiquetas de enlace canonical y alternate: todos las etiquetas rel=»canonical» y rel=»alternate», para idiomas y urls alternativas en móvil, deben tener https.
• Sitemap: si tenemos la posibilidad de regenerar los sitemaps debemos hacerlo.
• Establecer el dominio principal con https en Google Search Console.
• Comprobar el archivo robots.txt por si tenemos rutas absolutas o estamos filtrando el tráfico por https.
• Actualizar enlaces y rutas a imágenes en el código.
  Si tenemos alguna imagen en el código que cargue por http el navegador nos mostrará una señal de advertencia encima del candado.
  Si tenemos marcos (iframes) por http dentro de una web que funciona por https, es probable que la política de seguridad por defecto del navegador impida que se muestre.
• Rastrear el sitio web con algún crawler para ver que todos los enlaces funcionan correctamente.

¿Qué debe tener en cuenta el administrador de sistemas para no perder tráfico?

El proceso de instalación de un certificado puede ser complejo, sobretodo si no se dispone de un panel que automatice el proceso y, además, depende del servidor web. Pero aquí no voy a entrar a describir en qué consiste, ni en como se hace, si no a especificar los aspectos de configuración que se deben tener en cuenta para que la web no deje de estar accesible y que podemos comprobar para ver si el administrador que nos ha instalado el certificado ha hecho bien su trabajo:

Renovación

Es muy importante que el administrador del sistema se acuerde de renovar el certificado cada año o en la fecha que corresponda. No es raro encontrarnos con clientes con la web bloqueada por un aviso de seguridad, durante un día entero o más, porque el administrador no renovó su certificado. El proceso de renovación puede llevar tiempo y hay que hacerlo con antelación a la fecha de caducidad. Las empresas certificadoras no te cobrarán esos días de más por renovar antes, al contrario, muchas te ofrecen descuentos.

Podemos ver la fecha de caducidad de un certificado viendo sus propiedades en la configuración avanzada del navegador.

Sí usamos Let’s Encrypt, la renovación la realiza un programa automáticamente.

Instalar los certificados raíz e intermedios en el servidor

Las autoridades certificadoras también tienen su firma digital que utilizan para firmar tu certificado. A estos certificados de las CA se les llama certificados raíz. La clave pública de éstos viene preinstalada en todos los navegadores para poder verificar la firma de los certificados de las webs que los usan.

También hay otro tipo de certificado llamado intermedio, que se usa por seguridad, para mantener el certificado raíz con la clave privada offline, ya que de hacerse público todos los certificados de la CA dejarían de ser válidos. Cuando existe el certificado intermedio, el raíz firma éste y éste a su vez, el certificado de nuestra página web.

Este certificado intermedio debe existir en el servidor, porque si el navegador no lo tiene, el servidor lo transmite junto con el de la web. Puede ocurrir que al administrador se le olvide instalar el certificado intermedio en el servidor y por lo tanto que el HTTPS no funcione en todos los navegadores. Así que siempre es recomendable probar la web en los principales navegadores de escritorio y móvil. Si no funciona en alguno, es que al administrador se le olvidó instalar el certificado intermedio en el servidor.

En la configuración avanzada de nuestro navegador, podemos ver los certificados que tenemos instalados:

Versión de TLS

También se recomienda usar la última versión de TLS (actualmente la 1.2). SSL es una versión más antigua de TLS.

Redirecciones

Finalmente, cuando el administrador active HTTPS en nuestra web, ésta debería funcionar tanto por HTTP como por HTTPS y es el desarrollador el que debe encargarse de añadir las redirecciones.

Comprobación mediante herramienta online

Estos son los fallos más habituales, pero puedes comprobar la instalación de tu certificado en éste enlace.

¿Puedo usar HTTP2 al mismo tiempo que HTTPS?

HTTP2 es una versión nueva de HTTP 1.1. Como HTTPS en realidad son dos protocolos (HTTP y SSL/TLS) y la seguridad la da SSL/TLS, cambiar la versión de HTTP no afecta a lo que haga el protocolo siguiente, del mismo modo que cambiar IPv4 por IPv6 no afecta al resto de protocolos. Esto es por lo que se diseñaron los protocolos de comunicación en capas y por lo que todas las combinaciones son posibles, HTTP2 con HTTPS, HTTP2 sin HTTPS, HTTP 1.1 con HTTPS y HTTP 1.1 sin HTTPS. Sin embargo, los navegadores no soportan la combinación HTTP2 sin HTTPS.

¿Es HTTPS realmente seguro?

Sí lo es. El único punto flaco, son los ataques del tipo MitM (Man in the Middle). Si nos conectamos a Internet por una conexión WiFi abierta que haya puesto ahí un hacker, esté podría interceptar la comunicación de manera que al escribir en nuestro navegador http://www.facebook.com, el hacker evite que nos redirija a https://www.facebook.com, capturando todos nuestros datos (si no nos damos cuenta de que no hay candado en la URL). Para tratar de evitarlo, al menos en la mayoría de los casos, se usa la siguiente cabecera HSTS del protocolo HTTP:

Strict-Transport-Security: max-age=31536000;

Esta cabecera le dice al navegador que no se pueden hacer peticiones por HTTP a la web en el plazo de un año. El único problema es que nos quitamos la posibilidad de retractarnos y volver a tener HTTP en nuestra web.

Referencias adicionales

• Definición del protocolo HTTPS en el W3C
• Preguntas frecuentes sobre el protocolo seguro HTTPS
• Definición original del protocolo HTTP
• Definición de HTTP2 en GitHub
• Preguntas frecuentes sobre HTTP2
• Post sobre cómo usar Let’s Encrypt para implementar un certificado SSL libre y gratuito en tu web

Espero que os haya sido de ayuda y si tenéis alguna duda, no dejad de preguntarla en los comentarios. Intentaré resolverla a la mayor brevedad posible.