Jul 052015
 
Artículo Administración de Servidores

HTTPS es un protocolo seguro para la encriptación de la información intercambiada entre un navegador y un servidor web.

Tradicionalmente, ha sido recomendable implementar HTTPS en sitios web que ofrecen funcionalidad adicional a usuarios registrados, tales como tiendas online y otros sitios web de comercio electrónico. En este tipo de sitios, la información que envía el cliente al servidor, y la que recibe del mismo, puede contener contraseñas, números de tarjetas de crédito, y en general datos confidenciales que deben ser encriptados.

Más recientemente, existe una campaña liderada por Google para implementar la encriptación HTTPS en todo tipo de sitios web. Google ha reconocido que el uso de HTTPS en un sitio web es una señal que mejora (aunque débilmente) el posicionamiento del sitio en los resultados de búsqueda.

En este artículo vamos a explicar una manera sencilla de implementar este protocolo en un sitio WordPress, utilizando la red de entrega de contenidos Cloudflare.

Cloudflare

Cloudflare es un servicio CDN (Content Delivery Network, red de entrega de contenidos) que consta de una serie de nodos distribuidos en distintas ubicaciones geográficas. Los nodos actúan como intermediarios entre el cliente y el servidor de origen, mejorando el tiempo de descarga de las páginas, y reduciendo la carga en el servidor.

Uno de los servicios que ofrece Cloudflare es la encriptación SSL entre el cliente y el nodo Cloudflare, sin necesidad de realizar ninguna configuración adicional en el servidor de origen, por lo que resulta muy interesante hacer uso de este servicio como un primer paso en la implementación de HTTPS como protocolo de acceso a nuestro servidor.Para ello, podemos seguir el procedimiento que se explica en nuestro anterior artículo:

Cómo utilizar una red de entrega de contenido (CDN) en un sitio WordPress

Flexible SSL

Este servicio se puede activar sin necesidad de instalar  ningún tipo de certificado en el servidor, y es ofrecido gratuitamente (de hecho, el servicio está activado por defecto). De este modo, aunque la comunicación entre el nodo y el servidor continua utilizando el protocolo no seguro HTTP, la comunicación entre el cliente y el nodo se realiza utilizando HTTPS:

cloudflare_ssl_settings

Algunos señalan que el servicio Flexible SSL no ofrece seguridad completa, porque la comunicación entre el nodo CloudFlare y el servidor de origen no está encriptada. Pero esto se puede solucionar fácilmente de dos maneras:

  • Añadiendo un certificado auto-firmado (que no está validado por ninguna autoridad de certificación, y se puede generar gratuitamente en el mismo servidor de origen). De este modo pasamos la configuración HTTPS del sitio al modo “Full SSL”
  • O bien añadiendo un certificado validado por una autoridad de certificación (p.ej., VeriSign), en la configuración “Full SSL (Strict)”. Esto tiene la ventaja de que, si en algún momento decidimos prescindir del servicio CDN de CloudFlare, el sitio seguirá siendo accesible mediante protocolo seguro HTTPS, sin que aparezcan mensajes de advertencia en el navegador, como ocurriría con un certificado auto-firmado.

Redirección HTTP -> HTTPS en apache

Una vez que nuestro sitio WordPress es accesible a través del protocolo seguro HTTPS, es conveniente implementar una redirección permanente (redirect 301) para que cualquier acceso que se realice a una página con protocolo HTTP sea convertido en un acceso a la misma página con protocolo HTTPS.

La manera “estándar” de establecer una redirección HTTP -> HTTPS en un servidor web apache, como se explica en numerosos sitios web, consiste en añadir las siguientes directrices al fichero .htaccess del sitio:

Sin embargo, en el caso de CloudFlare estas directrices provocan un bucle infinito de redirecciones, porque CloudFlare funciona como un proxy inverso. Cuando se utiliza CloudFlare, la redirección HTTP -> HTTPS se puede realizar insertando en el fichero .htaccess del DocumentRoot del sitio web las directrices:

Cambios requeridos en el menú de WordPress

Aunque tengamos implementada la redirección HTTP -> HTTPS, podemos encontrar que algunos de los elementos de menú apuntan a páginas del sitio utilizando el prefijo “http://”:

Esto se puede evitar sustituyendo las entradas de menú de tipo “página” por entradas de tipo “custom link” que apunten a la misma url, sin el prefijo “https://SERVIDOR”.

Carga de ficheros javascript y hojas de estilo CSS

Normalmente, una página web carga una serie de librerías javascript y hojas de estilo CSS que implementan la funcionalidad y el diseño de la pagina. En wordpress, existe una manera estándar de realizar la carga de estos recursos externos, mediante llamadas a las funciones wp_enqueue_script() y wp_enqueue_style().

Por defecto, estas llamadas generan enlaces con el prefijo “http://”, y los navegadores rechazan cargar estos recursos cuando se solicita la página con protocolo seguro https:

https-error-mixed-content

En el ejemplo, hemos utilizado el complemento Firebug del navegador Firefox para visualizar el problema. En la ventana de log de consola aparece el mensaje de error “Blocked loading mixed active content”.

Para solucionar este problema, podemos añadir al el fichero “functions.php” del tema wordpress una función “fix_hardcoded_http”:

script_loader_tag es un “gancho” (hook) estándar de WordPress, disponible a partir de la versión 4.1.0. Las funciones registradas en este gancho reciben como argumento el código HTML “<script src=’…’>” encargado de cargar una librería javascript, lo modifican y lo entregan como valor de retorno. En este caso, la función “fix_hardcoded_http”, como vemos, elimina de la url del tag la especificación de protocolo “http:”, de modo que el navegador cargará la librería utilizando el mismo protocolo, ya sea http o https, que utilizó para cargar la página en la que se encuentra el tag.

Google Analytics y Google Webmaster Tools

Si utilizamos estas dos herramientas para el análisis del tráfico de nuestro sitio web, una vez implementado el protocolo HTTS en nuestro sitio, deberemos hacer unas modificaciones en la configuración de las mismas.

En Google Analytics, deberemos acceder a la sección de administración “Administration > Property Settings”, y establecer el procolo HTTPS en la URL por defecto de la propiedad correspondiente al sitio web:

ga-property-settings-https

Procedemos de la misma forma para establecer el protocolo HTTPS en el atributo “Website’s URL” del View (o Views, si hay más de uno) asociado a la propiedad:

ga-view-settings-https

En Google Webmaster Tools, al contrario que en Analytics, hay que registrar el sitio con protocolo https como un sitio nuevo, asegurándose de copiar la configuración relevante (por ejemplo, “International Targeting”, y otros parámetros).

Sitemaps

Las urls contenidas en el sitemap o sitemaps del sitio también deberán utilizar el protocolo https. La manera de conseguir esto dependerá del modo en que se han generado, ya sea manualmente, o bien con un plugin u otro tipo de herramienta ad-hoc.

Referencias

 Publicado por en 9:39 am

 Deja un comentario

(requerido)

(requerido)