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
hoy en día, 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. hoy en día, 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.
________
¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?
Revisa mi setup de trabajo, viaje y juego (ES).
Y si te gustaría ver más de estos análisis por aquí. Si el contenido que realizo te sirve en tu día a día, piénsate si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
Dos cosas.
Por suerte no uso cloudflare, vengo desde el año pasado observando a varias paginas que visito que usan ese servicio, y no, no es algun analisis sobre ellas, la verdad es que a cada cierto tiempo ocurre algun tipo de error y pagina deja de existir por un par de horas, error de host es lo que mas repite en su aviso del problema, lo que si es que en otros casos muestra una version de prueba de la pagina alojada en ellos, aunque no se puede mayor caso mas que ver y usar algunas opciones el error aun esta activo. Lo de tor si no sabia que ocurria con ellos.(apuntando).
Sobre AMP, tardando un poquito, tardando, tardando, tardando, veo el resultado y pienso de inmediato en la opcion que hace poco agrego firefox, aunque son pocas en las que no funciona, pero aca si, la opcion de Iniciar Vista Lectura, bastante similar, aunque se diferencia mas en el tipo de letras y demas formato por cada uno de estos.
Cierto lo del candadito verde, aunque este cifrado, siempre esa informacion llegara a manos de terceros. Veo caminos de metadatos aun por recorrer.
En principio CloudFlare te ofrece descentralización de contenido, lo que minimiza la carga del servidor, y evita, que si este se cae (cosa que acaba ocurriendo), al menos los visitantes tengan una página estática para consumir.
Por supuesto, es un intermediario mal, y siempre pueden ocurrir problemas, pero en principio, y salvando casos como el tema de TOR, la herramienta es potentísima y recomendable.
AMP es prácticamente mostrar el contenido sin diseño. En eso por supuesto se va a parecer a la Vista Lectura de Firefox, de Safari, y a los propios lectores RSS. La idea, que puedes ver ya si buscas en google.com algunos contenidos de grandes periódicos americanos, es que se muestre el contenido directamente en móviles, sin cargar el diseño (lo que más suele demorar la carga), al igual que está haciendo Facebook con los Instant Articles, pero al menos en los dominios del propio medio (y no en los del intermediario).
Saludos Dbillyx!
Enhorabuena por el artículo Pablo, me ha encantado. Yo estoy pasando por un proceso parecido al tuyo. He estado usando let´s encrypt y sin problemas hasta que configuré un multisite con dominios mapeados y ahí es cuando empezó a darme quebraderos de cabeza. Ahora estoy pensando hacerlo a través de Cloudflare que la verdad es que la relación entre precio y servicio que ofrece parece excelente. Saludos
Ya te digo. CloudFlare es una herramienta increíble.
En mi caso me he decidido por let’s encrypt para esta página, pero con alguno de mis clientes tenemos CloudFlare, y de hecho, lo tuve durante casi dos años en esta página, hasta que surgieron estos problemas que comentaba en el artículo.
Es increíble como una empresa que casi nadie conoce pasa a ser tan importante para la difusión de contenido.
Gracias por compartir tu experiencia Kiko!
Que buen articulo, pero tengo un par de dudas.
La primera Let\’s encrypt es gratuito?, es decir me puedo generar un certificado como lo generaría en una maquina normalita, es realmente confiable el certificado generado, (que si, que el candado verde lo confirma) pero igual tenia que preguntarlo.
Luego esta el tema de SSL gratuito con cloudflare, yo vengo usando cloudflare desde hace un tiempo para mis sitios y los sitios de los clientes y puedo decir que es increible lo que puedes hacer con esta herramienta y no hablo solo del DNS, prevencion de DDoS tambien tenemos las reglas, las estadisticas y muchas otras más que nos permiten que nuestro servicio tenga un valor agregado, ahora bien, lo que si no he logrado realizar es configurar un ssl gratuito, tienes pensado crear un post al respecto o si ya lo tienes, nos compartes el url?
Saludos.
Buenas Norwill.
Let’s Encrypt es gratuito, por supuesto. Es un certificado que se instala en el servidor, y de ahí que necesites tener acceso a backoffice, o que el hosting te lo permita. Y claro está, es tan “seguro” como lo sería cualquier otro certificado (TLS1.2). Simplemente que en vez de emitirlo una certificadora de pago, lo emite una organización sin ánimo de lucro.
En este artículo, no obstante, explico cómo esta democratización del SSL llega a ser perjudicial para la industria, sobre todo, habida cuenta de la confianza (absurda, ya que el candadito verde nunca quiso decir que el sitio fuera confiable) que depositamos en esta medida.
Por otra parte, y como te comentaba, CloudFlare es una herramienta fenomenal. El único pero que le puedo poner es que, en aras de proteger aún más las páginas, han considerado todo el tráfico proveniente de TOR como ilegítimo, y obligan a los usuarios a pasar captchas para seguir consumiendo el contenido.
En la cuenta de pago esto lo puedes modificar mediante reglas, pero en la gratuita viene activo por defecto, y es el motivo principal de que al final me decidiera por Let’s Encrypt. Pero vamos, que he usado durante años CloudFlare y seguiré recomendándolo.
Y si te fijas, en este mismo artículo, enlazo a un tutorial que lo vi en su día muy completo, añadiendo más adelante los problemas que al menos yo me encontré para habilitar CloudFlare SSL en esta misma página.
Échale un ojo y si tienes más dudas me comentas.
Saludos Norwill, y me alegro que te haya gustado!
El paso hacia unas comunicaciones siempre cifradas es un paso evolutivo necesario. La web se encuentra suficientemente madura como para plantearse dar el siguiente paso hace una web más cifrada.
Como bien describes, dentro de un ecosistema más seguro, es un punto adicional. Cada vez la web nos enlaza y entrelaza haciendo más dificil saber cuando una información es importante y debe serlo de cuando no lo es. Al final la mejor forma es no tener que distinguirlo, si todo va cifrado tenemos una preocupación menos. Aquí el canal utilizado desde que se cifra hasta que se descifra pasa a ser privado. El resto de componentes exactamente igual que si no se cifrase.
En cuanto al rendimiento no he notado nada distinto, solo el candadito verde en el navegador, pero de no decirlo, ni eso hubiese visto.
En cuanto a las compatibilidades , pues no solo afecta a los usuarios de windows xp, a los de windows 98, que aun quedan, también les afecta. Ciertamente, las compatibilidades que vemos en informática, muchas veces están fuera de toda lógica, en algún momento hay que sacrificarla y que sea el usuario el que “se apañe”. Si no nos acabamos encontrando con cosas como que en los htmls de algunas webs aun aparecen compatibles con navegadores que no soportaban marcos, algo que en las versiones 4 de internet explorer ya eran compatibles, algo que no tiene ningún sentido.
Personalmente, el cifrado debería ir de extremo a extremo, y no caer dicho cifrado cuando llega a determinado server, que sea una gran empresa, seria o con políticas de seguridad de la leche no es razón suficiente, es una debilidad innecesaria en el entorno. Cosas como el filtrado desde tor pueden realizarse igualmente, quizás si dificulta la detección de un ddos, pero sigue siendo un riesgo que debe ser asumido. En cualquier caso, podemos situarnos en un inicio de la democratización del cifrado en todo internet, así que, hasta que lka mayor parte de la web haya dado el paso es necesario hacer determinadas concesiones. Pero en mi opinión, cualquier web joven, como es el caso, o activa, es un paso que debe realizar o tener planificado dentro de un roadmap de la empresa.
Por lo demás, el problema del cifrado es tan antiguo como internet, llevo muchos años viendo que las comunicaciones entre los equipos de una empresa e internet son poco menos que públicos, y los usuarios no son conscientes de ello, el cambio de hubs por switch mejoró bastante la situación, pero no lo suficiente. El cifrado es el siguiente paso y hay que darlo cuanto antes.
Así es. Por cierto, que el cifrado que tenemos actualmente aplicado es de Let’s Encrypt, y por lo que he visto, sí va de extremo a extremo. El de cloudflare solo llega a sus servidores (normal, es un SSL flexible), teniendo que optar por la cuenta premium para poder utilizarlo en el servidor de llegada (o utilizar uno propio).
En todo caso, la problemática que ofrecía era la que comento en el artículo. Que eso haría que tuviera que sacrificar la comodidad de los usuarios de TOR, que ya bastante incómodos estarán por navegar a la velocidad que se mueve TOR como para encima penalizarlos por ser conscientes e intentar remediar el problema de la privacidad en Internet.
La web, al menos de puertas adentro (con usuario logueado) va bastante más rápida que antes. De puertas afuera irá igual o ligeramente mejor, pero es que ya desde hace unos años tenía la página muy pero que muy optimizada para visitantes (a nivel de administrador había veces que era una putada los tiempos de carga), y ya sabes que si hemos ganado 0,1 o 0,2 segundos a efectos prácticos para el usuario no se nota.
Será por eso que no noto nada.
También, cuando hablamos de cifrado debemos distinguir si lo que queremos es que no sea legible el contenido por un intermediario o si vamos a pagar con visa y nos fiamos o no de a quien le damos nuestros datos.
Una lectura de un blog, en la que ni siquiera he entrado con user o password no tiene sentido que la web me certifique quien es, al menos en principio, los datos solo van en un sentido, por decirlo de algún modo y lo que cuenta es que no se pueda saber que información lees. A nivel práctico, se dificulta que me espien, aunque pueden saber en que web he entrado. Lo cual es interesante si una empresa quiere saber que uso hacen sus empleados de la red, saben la web, pero no lo que leen.
Por cierto, me gusta casi más tu versión de la web amp, pero algunas páginas no cargan cuando lo intento….
Páginas o entradas? Si intentas entrar en una página de la web vía amp, no entrará, ya que AMP por definición es solo para contenido dinámico, y las páginas se supone que son estáticas (aunque en efecto se carguen dinámicamente como una entrada del blog).
Si te das cuenta de otra cosa avísame y le echo un ojo. Esta tecnología está aún en pañales, sinceramente, y estamos aún en espera de que haya mejor documentación.
Y por cierto, me he dado cuenta que gracias al SSL Analytics me muestra menos información de los usuarios. El Not provider típico ahora engoloba la mayoría de visitas, lo cual es una alegría para todos nosotros (aunque a mi me muestre menos información, jajaja).
Pues no se decirte, a veces simplemente le añado el amp al final de la página, para quitar los añadidos que le pones y tener el contenido puramente dicho y no sale nada… Ya te contaré
Coño, pues debería salir. La próxima vez, si te acuerdas, pásame la URL que mencionas.
Eso sí, ten en cuenta que esto solo funciona para entradas. Las páginas estáticas (y la home) quedan exentas. Saludos Khepper!