Cómo (y por qué) implementar un SSL vía SSL Flexible de CloudFlare

PabloYglesias Https

 

La semana pasada explicaba en un artículo los movimientos de servidor (y desventuras) que había tenido estos últimos meses a la hora de realizar uno de los mayores cambios sufridos a nivel de arquitectura de la web.

Y al final del mismo lanzaba una pregunta: ¿Qué SSL implementamos?

Había a priori tres alternativas (SSL certificado tradicional, Let’s Encrypt o SSL Flexible de CloudFlare), y después de esperar sus respuestas tanto por comentarios como por RRSS, me he decidido este fin de semana a hacerlo con Let’s Encrypt, por la comodidad que suponía, y pese a que con ello seguramente he perdido un poco de optimización.

Implementar Let’s Encrypt en un servidor es relativamente sencillo. La mayoría de proveedores ya hasta te ayudan con el paso, siendo un mero paseo, y queda en manos del administrador solucionar los problemas frecuentes que saldrán por contenido mixto (contenido que intenta cargar por HTTP), al cual también nos enfrentaremos en este tutorial.

Por ello, quería explicar el por qué de un cambio semejante, y ya de paso, hacerlo de la mano de otra de las alternativas que postulé: el SSL Flexible de CloudFlare, cuya configuración inicial es sensiblemente más compleja, y que hace unos meses apliqué en esta misma página, teniendo que volver atrás no porque no funcionase, sino por motivos externos que explicaba en el hilo anterior.

Hacia un entorno cifrado por defecto

A día de hoy, y como comentaba recientemente con algunos patronos, para un blog como éste dar el paso es totalmente opcional. Pero todo apunta a que en algunos meses será algo recomendable, y en otros tantos, obligatorio para cualquier web, comparta o no información del usuario.

Razones para estar a favor y en contra hay muchas, sinceramente, y que podríamos resumir en:

  • Seguridad: Un HTTPs únicamente certifica que la comunicación entre el usuario y el destino (que ojo, puede ser la web, o un intermediario), se realiza mediante SSL, esto es, cifrado. El cambio es para bien, pero recalco que con él no es que nos aseguremos que el dato que usted envía desde su dispositivo llega y se trata de forma totalmente cifrada en el servidor. Lo que podemos asegurar es que la comunicación hasta el punto de destino sí es cifrada. Que de allí esa información salga a otro lado y sea interceptada, queda fuera del alcance y potestad del candadito verde.
  • Privacidad: Este tipo de protocolos son obligatorios siempre y cuando haya un tráfico de datos críticos en alguna de las dos direcciones (como puede ocurrir con una pasarela de pago en una web de comercio electrónico), pero no es estrictamente necesario para una web como la nuestra, con la que usted está compartiendo, a lo mucho, su correo y su nombre (si escribe un comentario o me envía un email desde los formularios de contacto), su IP y demás datos de localización del sistema (versión del SO, versión del navegador, idioma,…).
  • Velocidad de carga: Esto sí me parece más interesante. La cuestión es que por ahora, y según el tipo de servidor que tengas, HTTP/2 (por aquí explico de qué se trata) solo funciona bajo protocolo seguro. A saber, nginx obliga a que la página cargue por SSL para obtener los beneficios de HTTP/2.
  • Posicionamiento: El cuarto en discordia. Que la página cargue más rápidamente ya es un aspecto crítico para el posicionamiento, pero es que además caminamos hacia un entorno en el que Google prioriza las páginas HTTPs frente a aquellas HTTP. Es un punto más dentro de los cientos de criterios que el buscador tiene en cuenta, pero es un punto que se implanta una vez y funciona para siempre, además que de no hacerlo, cuando esto pase a ser obligatorio, estaremos en desventaja frente al resto de la competencia.
  • Independencia: Por contra, lo que obtenemos con un internet basado en conexiones “seguras” es menos descentralización. A día de hoy, hay X proveedores de certificaciones SSL (donde X es un número que se puede contar con los dedos de las manos), y aunque bien es verdad que por lo menos ya hay alternativas gratuitas, se trata de un elemento más de control sobre la libertad que en su día dio sentido al tercer entorno.

Alternativas gratuitas (y problemáticas) de un forzado SSL en WordPress

Comentaba que existían opciones gratuitas en el mercado. La más conocida es Let’s Encrypt, que ha democratizado el acceso al protocolo seguro y que parece, a priori, la menos mala de las opciones. Pero claro, dependes de que tu proveedor (o tu servidor) sean compatibles.

En este caso optamos por utilizar el SSL que CloudFlare ofrece de manera gratuita a todos sus clientes. Semejante en todo caso a Let’s Encrypt (es autofirmado), pero que opera con todos los navegadores actuales (si usted usa IE7 o inferior, Opera 8 o inferior, y versiones ya deprecated de Chrome, Firefox, Safari y compañía, o si pertenece a ese 5% de lectores que sigue atreviéndose a conectarse a la red desde un WindowsXP, lo lamento, pero hay que actualizarse o morir…).

CloudFlare, como seguramente sabe, ofrece bastante más que un “simple CDN”. Tiene una herramienta Anti-DDoS, permite una gestión de DNS avanzada (cosa que por ejemplo mi proveedor no ofrece) y además, una certificación SSL gratuita.

Se trata de un SSL flexible, lo que quiere decir que en efecto la comunicación está cifrada hasta los servidores de CloudFlare, pero de ahí al servidor se hace de forma tradicional. Eso sí, bien es verdad que hacerle un MITM a una compañía como CloudFlare (maneja cerca de una tercera parte del tráfico mundial) resulta, a priori, un poco complicado :).

Eso sí, hay que considerar un punto, y es que CloudFlare, al operar como proxy inverso, se reserva la potestad de intervenir en las comunicaciones que considera potencialmente peligrosas. Esto es a grandes rasgos bueno (evita, como comentamos, ataques DDoS), pero también identifica a los usuarios que visiten nuestra página vía redes anónimas como TOR como potencialmente peligrosos, bloqueándoles la visita y haciéndoles pasar captchas periódicos para seguir navegando.

Para la mayoría de webs este tráfico seguramente sea despreciable, pero no es así en mi caso, al tratar esta página de privacidad y nuevas tecnologías, y por ende, teniendo un porcentaje bajo pero significativo de usuarios que me leen mediante TOR. Y es, por tanto, la razón principal por la que al final he desestimado utilizar CloudFlare y he habilitado el SSL de Let’s Encrypt, aunque recalco que para mayor optimización, la recomendación de un servidor sigue siendo la que explico en este artículo.

Una configuración inicial que me mantuvo en la noche del viernes hasta las cinco de la mañana liado, y es que una cosa es la teoría (bastante bien explicada en este tutorial (EN)), y otra es la realidad de cada uno.

  • En mi caso, el plugin que teóricamente evita que haya un bucle de redireccionamientos (ergo, que la página no cargue), no conseguía bypasear a WordFence, un plugin de seguridad que tenía instalado.
  • También hay que forzar la conexión vía HTTPs, que bien se puede hacer con el archivo .htaccess, o como en mi caso, con el propio plugin de CloudFlare, y mediante la directiva dentro de la cuenta de CloudFlare que explican en el tutorial superior, cambiando por supuesto en Ajustes de WP Generales, las dos direcciones de la página a https.
  • Además, tuve que cambiar a mano varias llamadas a elementos HTTP (generalmente llamadas a imágenes del propio tema y curiosamente un script de emoticonos (EN) que viene por defecto mal configurado a partir de WordPress 4.2) para que en efecto, no hubiera contenido mixto y obtuviera el candadito verde que informa al usuario de que la conexión se realiza de forma privada y segura.
  • Y más tarde, actualizar los sitemap, avisar a la Herramienta de WebMaster de Google del cambio y crear con un plugin de SEO urls canonizadas de HTTP a HTTPs (para evitar que el buscador considere las dos versiones como dos páginas distintas).

Reserve unas cuantas horas para ello, ya que cada página es un mundo, y tenga siempre disponible una conexión FTP (y hasta una copia de seguridad) por si las cosas salen mal.

La parte buena es que solo tendremos que hacerlo una vez, y en principio esto quedará configurado hasta el fin de los días :).

PHP7, AMP y el feedback continuo

Con el cambio de servidor y la implantación del SSL he pasado la página a la versión de PHP 7, la última, aprovechando que WordPress y la amplia mayoría de plugins/themes ya son compatibles 100% con ella.

Únicamente tuve un problema con una llamada a funciones deprecated de un elemento del tema, que después de buscar un rato por SlackOverFlow y tirar un par de líneas, quedó solucionado.

Es uno de esos cambios, junto a HTTP/2 y la API de WP, que hacen mejorar radicalmente la respuesta de este CMS.

Junto a este cambio, he habilitado además la versión reducida de la página siguiendo los criterios de Acelerated Mobile Pages de Google.

Disponible únicamente en las páginas dinámicas (las entradas del blog, para que nos entendamos) AMP ofrece una versión hiperoptimizada de consumo directo del contenido de esta web, que quizás en unos meses/años pase a ser la que se cargue por defecto en entornos de movilidad. Sin botones sociales, sin widgets, sin añadidos de ningún tipo. Prácticamente solo el contenido en bruto, como ocurre con los RSS.

Gracias a ello, pasamos de una demora de unos 3 segundos hasta la carga completa de un artículo del blog (es leíble mucho antes, pero aquí se tiene en cuenta cualquier script que carga en segundo plano), al escaso segundo y medio que tarda de media en cargarse un artículo AMP.

Puede ver un ejemplo en cualquier artículo publicado, simplemente añadiendo /amp a la URL, como sería el caso de este mismo: https://www.pabloyglesias.com/pabloyglesias-por-https/amp.

 

Como siempre, pueden surgir problemas. Por ello, si nota que algo no funciona como debiera, de verdad, hágamelo saber, que miles de ojos ven mejor y más que solo un par.

Cualquier duda (metodología, problemas, sugerencias) ya sabe que es bienvenida.

¡Que disfrute del fin de semana! Aunque parezca lo contrario, y pese a que estos cambios me han costado más de lo esperable, yo me lo he pasado como un niño :).

Y ya que estoy, si le apetece animarme por el esfuerzo, dejo por aquí el banner de donaciones. Estamos ya cerca de conseguir el siguiente hito en Patreon, que nos aseguraría cubrir los costes mensuales del proyecto. A ver si este mes lo conseguimos…

¡Muchas gracias, y espero que note mejora!

Edit a día 7 de Junio del 2016: He publicado otro artículo en el que explico paso por paso algunas configuraciones para minimizar el aspecto negativo en el SEO que tiene un cambio de URL, en este caso, al aplicar SSL.

hazme patrono pabloyglesias