Certificados de seguridad para nuestra web. Opciones y recomendaciones.

Es muy importante proporcionar una navegación segura a nuestros visitantes. De hecho cada día está más de moda hacerlo; más y más webs proporcionan una versión segura, y otras imponen esa seguridad. Por ejemplo, si tenemos una tienda online, es importante que los datos sensibles, como el pago, o los datos de nuestros clientes se transmitan por canales seguros. Incluso si tenemos un sistema de usuarios, es recomendable que la contraseña de ese usuario viaje por un canal seguro.

Básicamente, si proporcionamos un acceso HTTPs a nuestra web, estamos proporcionando un cifrado entre el servidor y el usuario que visita la web (por lo que si alguien vigila las comunicaciones le va a resultar complicado descifrarlo, porque nada es imposible), y por otro lado, le daremos al usuario la certeza de que está accediendo al sitio que quiere acceder, y por tanto nosotros (nuestra web) es quien dice ser.

Este HTTPS no es tan tan diferente al HTTP de toda la vida. Es más, es el mismo HTTP detrás de una conexión SSL. Dicha conexión SSL implica una negociación cliente-servidor para decidir qué algoritmos de cifrado van a utilizar e identificar el servidor. Esto conlleva un incremento de la información que se transmite (aunque las conexiones hoy en día son bastante rápidas para soportarlo). Cuando se ha producido la negociación SSL y las dos partes saben cómo se van a cifrar los datos, se establece una conexión HTTP normal bajo ese protocolo seguro. Normalmente, esta conexión HTTPS utilizará el puerto 443, mientras que HTTP usa el puerto 80. Como he dicho antes, normalmente, podemos utilizarlo en cualquier puerto.

Para ello, tenemos tres caminos:

Comprar un certificado SSL

Opción cara, hay certificados de todos los precios, podremos comprarlos en muchos proveedores de hosting y dominios, o directamente en proveedores de certificados SSL. Los precios varían en función de las garantías que ofrecen, de lo meticuloso que sea el proceso de verificación y de la cuantía de la indemnización.

Antes de que intentemos comer de la indemnización, dicha cuantía, que a veces es mucho dinero (llegando a más de un millón de dólares en algunos proveedores) es lo máximo que se otorgará a un cliente final (un visitante de nuestra web, vamos), si por culpa del certificado confió en un sitio en el que la entidad emisora del certificado confiaba (nuestra web) y ha perdido dinero. Algo así como que si nosotros timamos al visitante y le sacamos el dinero, ellos cometieron un fallo al confiar en nosotros, y se "disculpan" ante el cliente si ha perdido dinero... pero vamos, si engañamos a alguien de la denuncia no nos libramos. Por cierto, si el problema es con respecto al cifrado, no es seguro que den las indemnizaciones. Bueno, es un tema delicado, si es porque tu servidor no está configurado para ofrecer la máxima seguridad en la conexión, es problema de tu web, si por ejemplo, el algoritmo de firma es SHA-1 y el certificado un poco antiguo, en el momento en el que ellos te avisan para que cambies el certificado, que no te va a costar nada, si por culpa del débil algoritmo tienes un problema, es problema tuyo.

Por otro lado, los procesos de verificación pueden llegar a ser largos, por lo que la entidad emisora nos puede pedir toda clase de datos como empresa (escaneo de documentos identificativos o legales), entrar a nuestra web (incluso a zonas privadas de la misma, por lo que es bueno tener un usuario de prueba o un usuario tonto en ocasiones). Vamos, que ellos tienen que determinar que nuestra web y nosotros, somos de confianza, por lo que nos van a investigar.

Por último, el tipo de certificado. Tenemos uno muy básico que sólo certifica el dominio, esos suelen ser baratos, y los podemos conseguir por unos 8€ o menos al año, luego tenemos por ejemplo los EV (Extended Validation), que son por ejemplo los que tienen los bancos, que aparece el nombre del banco y muchos más datos cuando verificas información del certificado y suelen ser muy completos. También tenemos los multidominio (algo así como que si contratas un certificado para varios dominios, te puede salir más barato que un certificado para cada uno), o los wildcard (que pueden cubrir todos los subdominios dentro de un dominio)...

Let's Enctrypt

Hace poco se lanzó Let's Encrypt. Aquí podemos conseguir certificados gratuitos. Eso sí, su duración es de 90 días. Ellos recomiendan que automatices el sistema de obtención e instalación de certificados, pero si no lo haces, 90 días lo consideran suficiente para que lo puedas hacer a mano. Está bien, porque son una autoridad, no tendremos problema como en los siguientes, y porque si automatizamos el proceso de instalación y generación de certificados y hay que cambiar algún algoritmo de cifrado no hay que esperar mucho tiempo para que caduque el certificado ni nada. Son muy nuevos, y sólo validan dominios, no hay indemnización, pero para un certificado sencillo y tener nuestro sitio cifrado, nos vale.
También tenemos cacert.org, que se encargan de firmar nuestros certificados, pero tendremos el mismo problema que con los autofirmados.

Certificados auto-firmados

Yo me lo guiso, yo me lo como. Es la opción que he utilizado en muchos sitios, sobre todo cuando sólo un pequeño grupo de personas va a acceder al recurso y todos confían en ti como proveedor del servicio, pues adelante. El problema es que podemos recibir un mensaje de este tipo:

Y esto se debe a que nosotros mismos nos hemos firmado el certificado. Bueno, también vale crear un certificado familiar, y éste firme a cada uno de los miembros de la familia, estamos en las mismas. ¿ Quién es tu familia para firmar ? Es decir, no es reconocida como una autoridad que pueda dar confianza a cada uno de los miembros de tu familia.
Pero claro, si confiamos en nosotros (o en nuestra familia), podemos continuar, y aceptar el riesgo o también instalar nuestro certificado raíz en los equipos donde se va a utilizar la web. Por ejemplo, la sede de la FNMT en España hace esto.

Para saber cómo podemos generar nuestro certificado SSL podemos seguir el siguiente tutorial.

Instalación del certificado

Si nuestra web está en un hosting compartido o VPS gestionado, seguramente tengamos que hablar con nuestro proveedor de hosting para instalar el certificado, porque sólo ellos tendrán acceso. En ocasiones proporcionan un panel de control donde podemos hacerlo, pero no siempre.

Si por el contrario, la web la tenemos en un servidor que gestionamos nosotros, una vez tenemos el certificado en nuestro poder, para instalarlo, debemos asegurarnos de que nuestra web es lo suficientemente segura. Constantemente, muchos algoritmos de cifrado y negociación son declarados inseguros, pero claro, si damos un nivel de seguridad extrema, tal vez el cifrado que utilicemos no sea compatible con navegadores antiguos, así que tenemos que hacer un balance de esto.

Además, es difícil estar al día de todo lo que sucede, por suerte Mozilla pone a nuestra disposición Mozilla SSL Configuration Generator donde podemos encontrar una plantilla para copiar y pegar con varias configuraciones de seguridad listas para entrar en la configuración de nuestra web. Además, está bien revisar esta configuración de vez en cuando, porque puede que haya actualizaciones, igual de recomendable que es actualizar nuestro sistema a menudo.

Cosas de SEO

Lo primero, he de decir que no soy experto en SEO.

Google, comunicó hace algo más de un año que daría prioridad a las webs que utilicen HTTPS, es decir, si usas conexión segura, saldrás más arriba, aunque en muchos sitios (lo siento, cuando he visitado las webs de referencia ya no existían) decían que no lo habían notado apenas, aunque es algo difícil de medir.

Por otro lado, tenemos que plantearnos si nos interesa mantener las dos versiones, la versión HTTP y la HTTPS. Es decir, una será segura y la otra no. Está claro que si somos un banco, queremos ser seguros desde el principio, pero, ¿si somos una tienda? Ya depende, algunos prefieren utilizar HTTPS sólo en zonas sensibles de usuario y otros en toda la tienda.

Lo que sí que tenemos que tener claro es que si nuestra web es accesible por los dos protocolos (seguro e inseguro), es como si dos páginas tuvieran el mismo contenido (igual que si soportamos www.midominio.com y midominio.com ; tenemos que asegurarnos de que los buscadores sepan cuál es la buena, es decir, la principal, al menos la que queremos que sea la principal (y así no nos penalicen por contenido duplicado). Para ello, debemos poner en las páginas:

También cabe decir que si una página HTTPS enlaza a una HTTP, la segunda no recibirá el Referrer, es decir, la segunda no podrá saber de dónde viene el enlace. Esto no tiene que ver exactamente con el SEO, pero sí con la analítica web.

Recursos internos

Tenemos que tener cuidado con el tipo de recursos (imágenes, estilos, javascripts, etc) que utilizamos en nuestra web, ya sean en nuestro dominio o en otros lugares. Debemos utilizar siempre contenidos accesibles a través de HTTPS, o si no, los navegadores pueden quejarse, diciendo que nuestra web es potencialmente peligrosa porque accede a contenido no protegido.

Es muy común utilizar javascripts procedentes de un CDN, tipo:

En ese caso, al ser el CDN de Google, soporta HTTPS, pero si por algún casual, se está descargando un tipo de letra, o un estilo, que no procede de HTTPS, podríamos copiarlo en nuestro servidor y acceder a él desde ahí.

Además, todos los enlaces internos, sería interesante que apuntasen a páginas seguras.

Cookies

Es importante que las cookies sean seguras también. En PHP podemos conseguirlo poniendo a true el parámetro secure. También es muy recomendable activar httponly para las cookies, aunque eso es otra historia para que el navegador se encargue de que sólo pueden ser accedidas por el protocolo HTTP (o HTTPS) y no por Javascript, por ejemplo, lo que puede dar lugar a ataques por parte de usuarios malintencionados.

Imponer conexión https en Apache

Normalmente, yo suelo utilizar Apache como servidor, y un pequeño trozo de configuración que suelo utilizar en algunos sitios es este:

Justo encima de la configuración del VirtualHost seguro, es más, en el mismo fichero, para no liarme mucho. De esta forma, todas las conexiones que no sean seguras se redirigirán a conexiones seguras. Seguramente haya formas más elegantes de hacerlo, pero esta me parece lo suficientemente sencilla.

Foto: Miguel A Ramirez (Unsplash)