HTTP es el protocolo que nos permite las comunicaciones entre agentes dentro de Internet. Dicho protocolo es bastante sencillo y sigue un esquema de peticiones y respuestas que permiten recibir o enviar recursos a través de la World Wide Web, entre otras cosas. Cuando un servidor recibe una petición, la procesa y devuelve una respuesta, ya sea afirmativa o negativa.

Dichas peticiones se realizan a través de internet sin ningún tipo de codificación ni seguridad adicional. Cualquiera puede leer las peticiones si tiene acceso al medio por donde se transmiten. Cualquiera puede intentar pedir, enviar, obtener o modificar un recurso de un servidor independientemente de quien sea y que intenciones tenga.

 

Para paliar estas deficiencias se implementó una versión del protocolo que permite transacciones mas seguras donde antes de interactuar con un servidor podemos implementar una capa de seguridad que nos permite controlar quien accede al servidor y evita que las peticiones circulen por la red sin cifrado, ese protocolo es HTTPS.

Esta versión segura de HTTP implementa la comunicación entre el cliente y el servidor bajo una capa (TLS/SSL). Es decir, emisor y receptor llegan a un acuerdo acerca de como van a codificar los datos punto a punto para posteriormente emitir toda la comunicación codificada.

Para que esto sea posible, el servidor debe estar en posesión de una clave pubblica y otra privada y/o un certificado X509, generalmente firmado por una autoridad de rango superior, que certifica que ese certificado es válido y por tanto, ese servidor es de confianza. En realidad lo que se conoce como firma digital es una de las aplicaciones de los sistemas de criptografía asimétrica.

 

¿Qué es y como funciona la criptografía asimétrica?

Podemos imaginar la criptografía asimétrica como una ecuación con 2 incógnitas y una constante. Una incógnita es la clave púbica, la otra es la clave privada y la constante es el dato que queremos codificar. Lo curioso de los sistemas de criptografía asimétrica es que dicha operación puede ser calculada en un solo sentido, es decir, para una constante dada, podemos generar o calcular la clave pública a partir de la privada pero no podemos obtener la clave privada a partir de la publica. Algo que ocurre, por ejemplo, con las ecuaciones con logaritmos.

Veamos el siguiente ejemplo:

 

y = b^x               x = log_b y

 

Para un b conocido, podemos calcular y  a partir de x, pero no podemos calcular x a partir de y.

La explicación es la siguiente: para calcular y, solo tenemos que calcular una potencia, mientras que la única forma de saber el resultado del logaritmo, es probar valores preguntándose: ¿cuantas veces hay que multiplicar b por si mismo para que de y?

Las iteraciones que nos llevan a la resolución del problema son tantas, que el problema se considera irresoluble. Solo quien sabe x puede obtener y a partir de b.

Por lo tanto:

• ciframos con clave publica y desciframos con la privada para implementar cifrado asimétrico: solo el poseedor de la clave privada podrá leer los mensajes cifrados con su propia clave pública. Pero nadie que tenga la clave publica podra obtener la privada.

 

• ciframos con clave privada y desciframos con clave pública para firmar digitalmente: Cualquiera puede descifrar el mensaje con la clave publica que ha sido préviamente cifrado con clave privada, pero el hecho de que el mensaje sea descifrado con esa clave pública implica que solo el poseedor de la clave privada asociada a esa clave publica puede haber codificado ese mensaje. Por tanto, este sistema nos certifica que el emisor es quien generó la clave publica y no otro.

 

¿Cómo se usa el certificado?

Volvamos al certificado. El certificado, en resumen, es un archivo que expone la clave pública de ese servidor para que sus datos puedan ser codificados. Es decir, nos dice con que algoritmo de codificación (operación matemática) y con que clave pública debemos codificar nuestra comunicación para que ese servidor, y solo él que tiene la clave privada, pueda descodificar los mensajes. De este modo, simplificando mucho la explicación, es como se implementa la capa SSL/TLS.

Existen varios métodos de codificación  y en uno de los pasos del protocolo HTTPS conocido como handshake, cliente y servidor se ponen deacuerdo acerca del método de codificación que van a usar. O lo que es lo mismo, que operación van a usar las claves para codificar. Ese método debe ser uno que ambos entiendan y acepten, obviamente.

 

Certificados como fuente de confianza

Existe una paradoja en todo este proceso en la que no hemos reparado aún. La clave pública esta expuesta en el servidor (en el certificado alojado en él) me sirve como método de cifrado pero ¿realmente me sirve como garantía de seguridad? ¿Que un servidor tenga una certificado significa que puedo confiar en el?

En realidad no. La generación de un certificado, como hemos visto, no es otra cosa que el cálculo de una operación matemática que nos arroja dos claves: la pública y la privada. Por consiguiente el echo de tener esas claves no es garantía de nada. Es por eso que existen la autoridades de certificación.

 

Las autoridades de certifcación

Imaginemos que tuviésemos un listado de todas las claves públicas confiables en nuestro cliente. Inequívocamente sabríamos que el servidor que nos envía datos firmados con esa clave, es digno de nuestra confianza. Pero es imposible mantener una base de datos actualizada con un volumen de datos tan grande. Tendríamos que tener cada una de las claves publicas de todos los servidores a los que nos conectamos: cada una de las webs que consultamos tendría uno distinto y sería imposible de mantener.

En cambio, si que podemos tener la firma de unas cuantas autoridades de certificación en las que sabemos que podemos confiar. De modo que cuando consultamos el certificado de un servidor, hay un apartado con una autoridad de certificacion superior que certifica que ese documento es confiable y además ese certificado esta firmado con la firma de esa autoridad superior. De modo que podemos ir comprobando cada una de las autoridades hasta llegar a una de esas pocas en las que confiamos. Algo parecido a lo que ocurre con el sistema DNS.

 

Certificados autorfirmados

A menudo nos encontramos al implementar un servidor, no queremos o no podemos disponer de la certificación de una de estas autoridades  (no certifican gratuitamente) y optamos por generar nuestras propias claves y albergar la clave pública de forma manual en nuestro cliente. De esta forma omitimos todo el proceso. A esto se le llama usar certificados autofirmados ya que la autoridad certificadora somos nosotros mismos.