La importancia de tener un sitio HTTPS en 2017

Google lleva ya varios años advirtiendo sobre la importancia de que los sitios webs adopten el protocolo seguro HTTPS. En agosto de 2014 colgaron un post en su blog sobre seguridad, comentando que tendrían en cuenta el HTTPS como factor para el posicionamiento de la web en los resultados.

El siguiente tweet de Gary Illyes Webmaster Trends Analyst en Google, deja bien claro cuales son las intenciones de Google con respecto al HTTPS para este 2017:

¡Haz un favor a tus visitantes y mueve tu sitio a HTTPS este año! ¿Necesitas ayuda? ¿Tienes preguntas? ¡Nosotros te cubrimos! https://support.google.com/webmasters/answer/6033049#https-faqs

Estamos en 2017 y ahora Google va a darle otro empujón al HTTPS, y para ello va a hacer uso de su navegador Google Chrome, el cual a partir de la versión 56 mostrará un mensaje en la barra de navegación en aquellos sitios no seguros (que no tengan HTTPS instalado).

Como vemos, ahora se agrega la etiqueta de “No es seguro” junto al nombre de la web en la barra de direcciones. Anteriormente, ese menaje no aparecía:

De momento ese aviso únicamente se mostrará en las páginas de un sitio web que cumplan las siguiente dos condiciones:

  • No sean seguras. Es decir, no estén bajo HTTPS. Por ejemplo: http://misitio.com
  • Que se transmita algún tipo de información, como login, datos de contacto, datos de tarjeta de crédito, etc.

En resumen, que si tu sitio aún hace uso de http y un usuario va a hacer login, o enviar un formulario de contacto, se le mostrará la advertencia de “No es seguro” en la barra de navegación.

Este es solo un aviso por parte de Google para que los sitios comiencen a hacer uso de conexiones seguras HTTPS, y no cabe duda que en no mucho tiempo, ampliará la advertencia de “No es seguro” a cualquier sitio que no haga uso de HTTPS, independientemente de si en ese sitio se envía información de formularios o no.

Teniendo en cuenta que la cuota de mercado de Google Chrome es de más del 55%, es más que prudente el comenzar con la implementación del HTTPS cuanto antes, ya que independientemente de que Google pueda llegar a penalizar a los sitios no seguros, el tener un sitio bajo HTTPS aumenta la confianza y credibilidad de nuestro sitio frente al usuario final.

El implementar HTPPS en un sitio web consta de 3 partes principales:

  1. Instalar un certificado SSL en el servidor web y configurarlo
  2. Cambiar el código fuente y contenidos de la web para que únicamente se carguen recursos desde URLs HTTPS.
  3. Redirigir todo el tráfico HTTP a HTTPS para que el contenido se muestre siempre en HTTPS.

Si estás decidido a implementar HTTPS en tu sitio web, puedes ponerte en contacto conmigo usando el siguiente formulario, y te daré un precio dependiendo de la complejidad de tu sitio, comenzando desde 50€.

Cómo borrar un fichero de la caché de Nginx de forma manual

Nginx ofrece por defecto soporte para cachear ficheros, de tal modo que puede acelerar sustancialmente nuestra página web sirviendo una copia cacheada, evitando así utilizar recursos del servidor, y entregando con mucha velocidad la página al usuario. Es una situación en la que todos ganan.
Aquí tenéis una guía de cómo activar la caché en Nginx.

Nginx Plus (de pago) tiene opción de eliminar la caché (purgar) de forma selectiva. Sin embargo con Nginx debemos instalar un módulo para llevar a cabo esa tarea. El más conocido es el de FRiCKLE, aunque también podéis probar el módulo de wandenberg.

En este tutorial no vamos a tratar de cómo instalar los módulos para purgar la caché de Nginx, si no que vamos a ver como podemos borrar esos ficheros de forma manual, descubriendo cuál es la ruta donde se han almacenado los ficheros cacheados. Obviamente esta no es la manera más cómoda de borrar la caché, pero tal vez os sea útil en algún momento el saber cómo localizar los ficheros cacheados por Nginx.

Lo primero es saber en que directorio se está guardando la caché, para ello debemos mirar el fichero de configuración de Nginx de nuestro sitio web y buscar la siguiente directiva:

Puede ser fastcgi_cache_path o uwsgi_cache_path, dependiendo de la configuración de nuestro fichero de Nginx.

Ya tenemos la ruta de donde se están guardando los ficheros cacheados por Nginx, en este caso es: /var/cache/nginx/misitio/

Ahora vamos a ver como podemos averiguar el nombre del fichero cacheado. Para esto tenemos que saber lo que es la cache_key. En nuestro fichero de configuración de Nginx, es posible que encontremos la siguiente directiva:

Esta directiva sirve para definir de forma unívoca la URL del documento que se va a guardar. Por ejemplo, la página https://misitio.com/index.php/about-us tendrá la cache_keyhttpsmisitio.com/index.php/about-us

Si nuestro fichero de configuración de Nginx no tiene la directiva proxy_cache_key, Nginx utiliza por defecto la siguiente cache_key: $scheme$proxy_host$request_uri

Ahora que ya tenemos cómo se calcula nuestra cache_key, necesitamos un último paso para saber el nombre exacto que tendrá el fichero de caché.
Para esto debemos hacer un md5 a la cache_key, por ejemplo:

da como resultado:

Ya estamos cerca de tener la ruta completa del fichero cacheado.
Ahora debemos quedarnos con los últimos 3 caracteres del md5, en este caso e26 , y debemos:

  • Seleccionar el último carácter: 6
  • Seleccionar el antepenúltimo y penúltimo caracteres: e2
  • Unirlos en forma de subdirectorios: /6/e2 => /ultimo_caracter/antepenultimocaracter+penultimocaracter

Estos dos directorios son parte de la ruta de donde va a estar nuestro fichero, de tal forma, que nuestra ruta hasta ahora sería:

Falta lo más sencillo, que es el nombre del fichero, el cual se va a corresponder al md5 que calculamos con su cache_key. De tal forma que la ruta completa será:

Ya tenemos localizado el fichero para poder borrarlo o hacer lo que queramos con él.

Como redirigir (301) de http a https en Plesk con Apache

Dentro de no mucho tiempo, el tener una página bajo https con un certificado SSL será algo obligatorio si queremos que nuestros usuarios no salgan huyendo de ella.

En caso de que hayamos instalado ya nuestro certificado y nuestra web sea accesible bajo https, debemos redirigir nuestro antiguo sitio http al nuevo https. De tal modo que si alguien accede a http://misitio.com/noticia-interesante, se le redirija de forma automática a https://misitio.com/noticia-interesante. De ese modo no tendremos duplicidad de contenido.
Además, queremos que nuestra redirección sea permanente (301), para que los buscadores consoliden la información referente a las URLs de nuestra web.

Para ello, nos vamos a nuestro panel principal de Plesk, y en las opciones de nuestro dominio, pinchamos sobre “Configuración de Apache y nginx

Ahora, en la caja de texto de “Directivas adicionales para HTTP” introduciremos la siguiente línea:

Pulsamos sobre Aplicar, y veremos un mensaje como el siguiente.

Ahora solo queda comprobar que la redirección se ha realizado correctamente. Para ello accedemos a nuestro sitio con http://misitio.com y abrimos la consola de Chrome (F12) y en el panel de Network, veremos como se indica que se ha redirigido con 301 de http://misitio.comhttps://misitio.com.

Es posible que vuestra versión de Plesk sea distinta a la que se muestra en las imágenes y por tanto que la ruta para acceder a la pantalla de “Directivas adicionales para HTTP” sea algo distinta. En las imágenes se muestra la versión 12.50 de Plesk.