¿Sirve para algo la garantía de un certificado SSL?

La respuesta corta sería : no. La garantía de los certificados no sirven realmente para nada porque es prácticamente imposible que se hagan efectivas. Digamos que la garantía funciona como el pan «de pueblo» o la comida «casera», no deja de ser un reclamo.

Certificados en Comodo-apetekan181
La garantía de los certificados SSL

¿En qué consiste y qué cubre la garantía de un certificado?

La garantía del certificado SSL cubre cualquier daño que pueda derivarse de la emisión indebida de un certificado a una entidad fraudulenta. Por ejemplo, si un usuario se conecta a un sitio web fraudulento pero ha obtenido un certificado de una autoridad de certificación reconocida, ese es un caso en el que la garantía del certificado puede aplicar porque ha sido culpa de la Autoridad Certificadora (CA).

Ojo, la garantía cubre al usuario final, no al propietario del certificado. En este sentido, el concepto de la garantía del SSL puede ser engañosa porque el propietario del certificado SSL no puede reclamarlo. La garantía se aplica sólo a los usuarios finales. Si alguien compra un producto de un sitio HTTPS seguro y esto lleva a una pérdida de dinero. En este caso, el usuario final tiene derecho a reclamar una compensación de garantía. La CA cubrirá las pérdidas de acuerdo a sus términos y condiciones.

En SSL Dragon mencionan el caso de DigiNotar, que entregó un certificado para Google.com a una empresa que no era Google.

En este artículo Scott Helme, Do SSL warranties protect you? As much as rocks keep tigers away… tenéis más detalles sobre este asunto.

Probando Mailvelope en RoundCube: PGP en tu webmail

PGP siempre ha estado ahí pero me ha dado pereza probarlo… y ya sé por qué. El caso es que me he tenido que poner con ello y…

Qué es PGP

Malo será que no hayas oído hablar de ello. De forma resumida, PGP (Pretty Good Privacy) ofrece la posibilidad de firmar y cifrar la información transmitida a través del correo electrónico. En sus comienzos era un programa desarrollado por Phil Zimmermann en 1991 y a lo largo de los años se ha generalizado para describir el método de encriptado que utiliza este software (esto no es exactamente así… en la Wikipedia tenéis la versión larga de la historia).

Su funcionamiento se basa en la estructura de clave pública (o cifrado asimétrico): nos ponemos a juguetear de nuevo con nuestra clave pública y privada. En este caso, la clave pública se pone a disposición de los contactos de correo potenciales bien comunicándosela o cargándola en un servidor de claves externo. Con esta clave estos contactos cifrarán los mensajes electrónicos que quieran enviarte… y solo tú podrás descifrarlos.

xaedes & jfreax & Acdx, CC BY-SA 3.0, via Wikimedia Commons

La clave privada (protegida con contraseña, personal, secreta e intransferible por la cuenta que te trae) nos sirve para descifrar los correos electrónicos entrantes previamente cifrados con la clave pública.

Para establecer una comunicación segura siguiendo este proceso, será necesario que tu interlocutor también haga uso del protocolo PGP y te informe acerca de su clave pública.

Adicionalmente, la firma electrónica garantiza la autenticidad de los mensajes que se envían; es decir, nos aseguramos que el que envía el mensaje es quien dice ser.

Cómo implementamos PGP en nuestro correo

Como hemos visto antes, para empezar a usar PGP hay que hacer unas cuantas cosas con antelación:

  • Crear el par de claves necesarias: la pública y la privada
  • Intercambiar las claves con los destinatarios (de forma directa o a través de servidores)
  • Confirmar y validar de alguna forma esas claves para que no nos la cuelen (usando el fingerprint, muestras de sangre…)
Niveles de confianza para un certificado en Kleopatra
Niveles de confianza para un certificado en Kleopatra

Y una vez tenemos esto, ya podemos cifrar y descifrar los mensajes a troche y moche.

Para generar y gestionar las claves, existen diversos programas (os aparecen en la web de OpenPGP > Software) y algunos, como Thunderbird, ya tienen la gestión del cifrado de extremo a extremo (End to End Encryption) integrada de serie desde su versión 78.

El caso es que eso está muy bien, pero muchos usamos webmails: Gmail, Yahoo (sí, todavía hay gente que lo usa), Hotmail/Outlook… o el que te proporciona tu proveedor de hosting que casi seguro que es RoundCube. Para todos ellos, existe Mailvelope, un plugin para Firefox y Chromium (Chrome, Opera, Edge…). Mailvelope está basado en OpenPGP.js

Pantallazo de la web de Mailvelope
La web de Mailvelope el 17 de diciembre de 2020

En este documento del INCIBE os cuentan como usar PGP con el cliente de Outlook y con anteriores versiones de Thunderbird (como digo, a partir de la v78, no es necesario ningún plugin), a continuación os muestro como usar PGP en Firefox con Mailvelope para vuestro webmail.

Mailvelope + Roundcube (en Firefox)

Lo primero es descargar e instalar el plugin: https://addons.mozilla.org/es/firefox/addon/mailvelope/ y… comenzamos:

Empezamos…

Generamos el par de claves para el buzón de correo

Creamos nuestras claves. Las podemos crear nuevas o importarlas si ya las tenemos creadas.

´Creamos un nuevo par de claves para el buzón escogido

En este caso la vamos a crear desde el principio. Completamos los datos que nos piden en la pantalla, ponemos la contraseña y damos a generar las claves. Podemos elegir entre diversos algoritmos de encriptado, la fecha de validez de los certificados y si queremos que se suba a un servidor de claves o no:

Generando las claves con la información indicada…

Una vez generadas las claves, nos aparecerán en el Gestor de claves:

El gestor de claves con nuestras claves (privada y pública)

Al crear las claves y subirlas al servidor de Mailvelope, nos llegará al correo un mensaje para verificar la dirección de correo. El correo está cifrado, así que tendremos que descifrarlo previamente:

Mensaje cifrado de validación

La aplicación trae opciones para cifrar/descifrar mensajes ya sea copiando y pegando el contenido del mensaje o subiendo el archivo cifrado. En nuestro caso, desciframos el mensaje haciendo copia-pega. Nos dará la opción de descargar el mensaje en un archivo de texto y ahí nos aparece un mensaje con un enlace para confirmar la clave en el key server de Mailvelope

Desciframos el mensaje de validación…

El mensaje una vez descifrado:

Hello sasaeh PGP Test,

please verify your email address o1@sasaeh.com by clicking on the following link:

https://keys.mailvelope.com/api/v1/key?op=verify&keyId=****

After verification of your email address, your public key is available in our key directory.

You can find more info at keys.mailvelope.com.

Greetings from the Mailvelope Team

Autorizamos el dominio del webmail

Ya hemos visto que podemos cifrar y descifrar mensajes desde el menú del plugin, pero lo chulo es tenerlo todo integrado y trabajar con el cifrado dentro de la aplicación, así que tenemos que autorizar el dominio.

Vamos a nuestro webmail y, en las opciones de Mailvelope, pinchamos en "+ Authorize this domain"; en mi caso,

Autorización del dominio

Con esto ya tenemos Mailvelope integrado dentro del webmail y podremos:

  • Ver los mensajes cifrados directamente
  • Cifrar (y firmar) los mensajes desde el webmail a través de la interfaz de Mailvelope
A la hora de componer el mensaje, tenemos la opción de cifrarlo

Y ya está.

En el dashboard de Mailvelope tenéis más opciones para que le echéis un ojo.

Dashboard del plugin

Recordad que para que podáis comunicaros con PGP con otro buzón de correo, los dos tenéis que usar PGP y las claves públicas del destinatario. Podéis importar las claves públicas desde la interfaz de Mailvelope, desde el Keyring, desde donde generasteis vuestro par de claves.

Utilidades SSL

Los proveedores de hosting hacen que la petición e instalación de los certificados SSL sea transparente (en un mundo ideal) y la mayoría de la gente no sabe ni el certificado que solicita; ellos solo quieren que vaya por seguro y cuando falla…

A la hora de chequear el estado de un certificado instalado, decodificar los CSR (Certificate Signing Request) o convertir el certificado a otro formato hay diversas webs que nos ofrecen utilidades.

  • SSL Labs de Quality Labs. Sobre todo en el testeo del servidor aporta muchísima información útil.
  • Digicert SSL Tools. Digicert es la principal Autoridad Certificadora (CA) y pone a nuestra disposición algunas utilidades: generar y chequear CSR, comprobación del sitio web, etc.
  • SSL Certificate Tools. El nombre lo dice todo ;) Es más sencillo que las anteriores pero tiene cositas como el conversor de certificados.

Amalgama del futuro

A veces no sale. Con el ala aleve de no sé qué cosa. Eso es una aliteración. Vacua, vaca, Baco, bacanal, vacante, vacaciones hinchadas, pinchadas, gaseosas, siseantes y sibilinos sacuden el sudor los siervos de Satán. Esto también es una aliteración. La parte final, desde “siseantes”. Y es que a veces no sale.

En el año tres mil tres los números se escriben del revés y se dirá tres mil tres, que es igual, pero no es lo mismo. Esto es ciencia ficción, porque ocurre en el futuro, y en el futuro la atmósfera es menos densa y con un pequeño paso avanzas decenas de metros o más. La cabeza también baila un poco, se tambalea como uno de esos muñecos hinchables. El futuro no sirve de mucho porque arrastra los problemas del pasado, que son los mismos que los del presente. Como mucho, se puede hacer un futuro en tonos ocres, o con abundancia de grises. El futuro tiene un decorado peculiar, pero pasado de moda. ¿Has visto películas de ciencia ficción de los años setenta? El futuro siempre es pasado. Esto puede ser una contradicción o simplemente la constatación de un hecho.

Si en ese futuro pasado hubiera vaqueros, serían vaqueros espaciales, si hubiera toreros, también serían espaciales y podrían torear a la luna, como seguro que le ha cantado algún poeta del pasado pasado. Si hubiera fontaneros, sería un atraso. No puede haber fontaneros en el futuro por muy pasado que sea. El futuro no es ni de los soviets ni de los fontaneros, esto conviene dejarlo claro porque si no, el pueblo se me rebela. Y, por dejarlo todo dicho de una vez, el futuro tampoco es del pueblo. Pueblo pusilánime, pisoteado, pisado, aprisionado, pelado y sin futuro. El pueblo debía gobernar, pero luego llegó el futuro, tan parecido al pasado, que acabó todo siendo muy parecido, pero no lo mismo, como el año tres mil tres.

El futuro se escribió hace tiempo. Cada nueva generación lo reescribe y emborrona, como si todos fueran zurdos y pasaran la manga por el escrito. Un estropicio. Al final el futuro es ahdfjhfkhseu ehrwuhk iuhkhjçñqle chis pum garabín. O cuarenta y dos (42), que vale para todo. También fue siete (7), treinta y tres (33) o seiscientos sesenta y seis (no puede escribirse eso… no no no). Se usan números porque son símbolos y son cortos. El futuro es corto y simbólico.

El futuro vino en un barco, de nombre extranjero que te encuentras en un puerto (espacial) al anochecer, porque el espacio es infinito y oscuro como boca de lobo. Una noche eterna, con estrellas, blink-blink (onomatopeya), que relucen desde su pasado, que no fue el nuestro porque ni siquiera estábamos allí. Como el dinosaurio, dirá alguno. Como el dinosaurio, listillo. Al final se trata de juntar ideas, encadenar palabras, poner la boca en el culo, engarzar el final con el principio, coger el pasado inmemorial (fíjate, de aquel entonces) que nos llevó al pasado grotesco que pergeñó un presente histriónico para empujar toda esta bola hacia un futuro kitsch y hortera.

Encadenar es enlazar, también atar, aprisionar, enjaular, encarcelar. “Niño, ven aquí y enlaza palabras”. Entonces no, entonces es como hilar. Coser palabras en papel de seda, con puntos (.), comas (,) y puntos y comas (;). Puntoscomas. Tojunto, como bancospaña, bancarrota, paticoja. A esto se llama… no sé, amalgama.

Qué es y para qué sirve DNSSEC

Vaya por delante que mi relación con las DNS es, digamos que distante, así que al añadirle apellidos la cosa se me complica.

Para qué vale DNSSEC

Quizá lo más interesante de DNSSEC es saber para qué te puede valer. En este vídeo ochentero (es de 2013, pero parece más antiguo, ¿verdad?) lo explican de forma sencilla:

About DNSSEC (Animated Introduction – With Text Narration)

DNSSEC sirve para impedir que alguien suplante a nuestros servidores DNS y nos proporcione información falsa, evitando la suplantación de servicios de terceros.

Aunque DNSSEC está bastante extendido, no todos los registradores ni todos los registros lo permiten.

¿Cómo funciona DNSSEC?

Autenticando la información mediante un cifrado asimétrico. Aquí empieza la parte más complicada ya que todo el contenido debe ir firmado para asegurar su autenticidad y todos los miembros de la cadena deben ser capaces de validar esa firma, hasta llegar a los servidores DNS raíz. Toda la cadena debe estar configurada para permitir DNSSEC.

De forma resumida, para un dominio:

  • Los servidores DNS deben estar configurados para permitir DNSSEC
  • Se firma la zona del dominio usando 2 pares de claves de seguridad: Zone Signing Key (ZSK) y Key Signing Key (KSK)
    • ZSK se utiliza para firmar la zona del dominio; es quien dice «Estos son mis registros DNS, provienen de mi servidor y deben ser así». Para ello utiliza registros DNS de tipo RRSIG para cada uno de los record sets (conjunto de registros del mismo tipo y nombre)
    • KSK se utiliza para firmar los registros DNSKEY que contendrán las claves públicas de las firmas, tanto ZSK como KSK, y que también tendrán su correspondiente RRSIG asociado.
Diagrama de claves de firma de claves
Diagrama de claves de firma de clave (imagen de CloudFlare)
  • Para transmitir esta información, hay que trasladar la clave pública de KSK a la zona padre. Esto se hace con el registro Delegation Signer (DS), que contiene la clave pública hasheada.
    Cada vez que un resolver se dirige a una zona secundaria, la zona principal también proporciona un registro DS. Este registro DS es la forma en que los resolvers saben que la zona secundaria está habilitada para DNSSEC. Como el DS es un registro «normal», también irá firmado y se irá subiendo en la cadena de confianza hasta la zona DNS raíz. Como curiosidad, como no hay nadie que valide este último registro, se realiza una Ceremonia pública en la que una serie de autoridades realizan la firma de las claves de la zona raíz.
Validación de la cadena de confianza para www.eurid.eu

A todo esto hay que añadir que conviene cambiar las claves ZSK y KSK cada cierto tiempo… con lo que ellos supone de transmisión hacia arriba de los cambios.

Como las KSK se usan para firmar las claves, suelen ser más robustas y hay que modificarlas menos a menudo. Para las ZSK se usan claves más débiles y estas sí se suelen rotar por ejemplo cada 2-3 meses.

Los registros DNS implicados

Ya hemos visto que se están creando bastantes registros nuevos para poder firmar y autenticar estas firmas:

  • RRSIG. Contiene la firma digital de cada resource record set. Esta firma se verifica con la clave pública almacenada en los registros DNSSKEY.
  • DNSKEY. Contiene la clave pública necesaria para validar las firmas de los registros RRSIG.
  • DS (Delegation Signer). Identifica una zona delegada. Hace referencia a un registro DNSKEY en la zona subdelegada. El registro DS se coloca en la zona padre junto con los registros NS delegados.

Adicionalmente aparecerán registros NSEC o NSEC3 (para denegar de forma explícita la existencia de un registro DNS) y también pueden aparecer registros CDNSKEY y CDS para zonas secundarias que soliciten actualizaciones de registros DS en la zona principal.

Referencias

  • Echad un ojo a la explicación de CloudFlare sobre cómo funciona DNSSEC (How DNSSEC works). De lo que he visto es la que mejor aclara qué es y cómo funciona DNSSEC.
  • Si queréis ver cómo es la Root Signing Ceremony, ICANN publica los vídeos en YouTube ;) No esperéis un fiestón con alcohol y stripers.
    Ólafur Guðmundsson (CloudFlare) estuvo invitado y explica el proceso en el artículo The DNSSEC Root Signing Ceremony.
  • No viene mal recordar el cifrado asimétrico, que es lo que nos permite autenticar a las partes en todo este jaleo:
  • Y puedes analizar el estado DNSSEC con el DNSSEC Debugger de Verisign Labs:

Banners de cookies de terceros, ¿peor el remedio que la enfermedad?

Vamos a suponer que la llamada Ley de Cookies se creó para que los usuarios de un sitio web fueran conscientes de que, cuando visitas un sitio web, hay servicios que están dejando información (cookies) para ofrecer cierta funcionalidad: analítica, de personalización, etc.

La Agencia Española de Protección de Datos tiene una guía sobre el uso de las cookies completa y entendible. La puedes leer en Guía Cookies AEPD (PDF).

AEPD.es

Como usuario, esto te puede asustar, ser más consciente de que hay cosas detrás de esa web, de que puedes aceptar/rechazar algunas de esas funcionalidades adicionales (podrías quitar el seguimiento de publicidad, p.ej.). Al final es más fácil pinchar al «Sí a todo por Dios, déjame ver la web» que cualquier otra cosa, así que no sé yo si realmente hemos ganado algo (seguramente algo sí, una miajica si quieres, pero algo).

Como editor de un sitio web, montar un banner de cookies es un pochocho de tres pares de narices. ¿Y yo qué sé qué es una cookie? ¿Qué se yo cómo se ven y se dejan de ver? Ah, ¿pero puedes quitar alguna? Y entonces, ¿voy a perder el mapa chulo que tengo? Pero estamos salvados: hay plugins y pequeños scripts y zurullitos de coña y tienen su versión gratuita y no tienes que hacer prácticamente nada para ponerlos.

Todo perfecto.

Cuando algo es gratis, el producto eres tú

¡¡Chopecha!!

Bien, igual no es tan terrible, o tal vez sí. Lo importante es que sepas que, para que esos servicios funcionen correctamente, analizan tu web, ponen sus propias cookies y las pueden utilizar para realizar rastreos de los usuarios de la web. Vamos, has añadido un rastreador más a la lista que ya tenías.

¿Es eso bueno o malo? Por ahora, es lo que hay. Te ofrezco una funcionalidad, pero cojo algo a cambio (dinero, información…). Al final no sabemos si estos datos lo estamos vendiendo caros o baratos, si la funcionalidad que ofrecen esos servicios de terceros la estamos pagando a doblón o es justo.

Si aún así quieres usar un banner de terceros…

Algunas opciones gratuitas son:

En Arsys hay un par de artículos que te pueden resultar útiles:

Cual es el proceso de validación de un certificado SSL

En otras entradas, hemos hablado de los tipos de certificados que existen y como lo que se valida y el proceso de validación para cada uno de ellos es diferente. Resumo los tipos de certificados:

  1. DV o Validación de Dominio
  2. OV o Validación de Organización
  3. EV o Validación Extendida

El certificado de nivel más alto, incluye la validación requerida por el nivel anterior. Es decir, un certificado OV, requiere una validación de la organización pero también del dominio, y un EV, además de esa validación extendida, validará también la organización y el dominio. Por lo tanto, el proceso de validación de cualquier certificado antes de concederlo siempre será:

  • Se valida el dominio para el que se solicita el certificado. Esto es necesario para los certificados DV, OV y EV y suficiente para un SSL de tipo DV.
  • Se valida la organización para la que se solicita el certificado. Necesario para los certificados OV y EV y suficiente para un SSL de tipo OV
  • Se realizan validaciones adicionales sobre el solicitante del certificado para los SSL de tipo EV.

¿Cómo valido un dominio?

Para validar el dominio, la Autoridad Certificadora (CA) debe asegurarse de que tenemos acceso a la gestión del dominio.

Hay 3 tipos de validaciones: DNS, FILE o EMAIL:

  • Para la validación DNS tendrás que añadir una cadena concreta en un registro DNS.
  • En el caso de FILE, es similar: hay que subir un archivo en una ruta concreta del dominio.
  • Por EMAIL, se enviará un correo con un enlace a una dirección de email fija (admin@example.com…)

Lo normal es que todo este proceso sea transparente para ti si la gestión de las DNS y del certificado los tienes en el mismo hoster.

¿Cómo se valida la organización del certificado?

Al solicitar certificados OV y EV, se pide información completa de la organización y de un Contacto Administrativo dentro de la organziación que respodnerá por la validez de los datos. Con esa información la CA debe asegurarse que los datos son válidos y para ello utiliza la información de entidades y registros públicos, como puede ser el registro mercantil u otros registros similares (p.ej. Google Business o Páginas Amarillas).

Una vez la CA se ha asegurado de la existencia jurídica y operativa de la entidad se realiza una llamada telefónica al teléfono de contacto de la empresa para asegurarse de que todo es correcto.

Para validar una organización, entonces, lo que se se hace es:

  • La CA comprueba que la empresa está registrada y operativa consultando información de autoridades competentes (registro mercantil, etc.)
  • Se valida el domicilio fiscal de la organización
  • Se localiza un teléfono de esa organización y se realiza una llamada de comprobación
  • Se aseguran de que el dominio para el que se solicita el certificado pertenece a la organización

Aunque el proceso está automatizado en gran medida, la concesión del certificado no es inmediata (como puede ser la de un DV), y el proceso puede llevar varios días. Lo bueno es que no tendremos que pasar de nuevo por todo el proceso si solicitamos nuevos certificados para la misma organización: la organización se considera validada durante 27 meses.

Añado un par de enlaces para mostrar cómo hacen esta validación Digicert y Sectigo, dos de las mayores CA:

Y, ¿qué es eso de validación extendida? ¿Cómo se validan los EV?

Vale… me has pillado. Aquí simplemente se indica que las comprobaciones son «más exhaustivas» y yo me remito a lo que diga la guía de CA/Browser forum para la validación extendida (v 1.6.7), llámame cobarde si quieres.

¿Has dicho CA/Browser forum?

CA/Browser forum es el consorcio que agrupa a Autoridades Certificadoras, constructores de software (como Mozilla o Google) y otras entidades relacionadas con las certificaciones y que se encarga de emitir guías y requerimientos que son vinculantes para los miembros del foro.