Let’s Encrypt : sécurité pour tous ou passoire pour tous ?

Let’s encrypt vient de sortir de sa version béta. Ça m’inspire une petite réflexion à deux balles du dimanche soir.

Chaîne de confiance et authentification des sites web

Les concepteurs de certains sites web choisissent parfois de chiffrer la connexion entre votre navigateur internet et le serveur sur lequel est hébergé le site web. Cela peut avoir plusieurs finalité : éviter qu’un des intermédiaires entre votre navigateur et le dit serveur n’obtiennent des informations confidentielles (mots de passe, informations de paiement) ou puissent connaitre les pages que vous avez consultées sur ce site (page wikipedia traitant de droits de l’homme dans une dictature par exemple). Pour faire simple, lorsque vous vous connectez, un échange de clés intervient afin que chacun puisse chiffrer les données envoyées. Le chiffrement de ce flux d’octets entre vos deux machines se matérialise par le fameux « cadenas » dans votre navigateur.

Au delà d’une écoute passive, les nombreux réseaux que traversent ces octets pourraient décider de se faire passer pour ledit site web. Il est donc nécessaire que le serveur répondant à la requête de l’utilisateur prouve qu’il est bien celui qu’il prétend être. Pour cela sa clé publique (ie son certificat) est signé par une autorité de confiance. Lors de la connexion de votre navigateur web, celui-ci vérifie que le certificat envoyé par le serveur correspond au domaine demandé. Il  utilise ensuite à la clé publique de l’autorité de confiance qui a signée ce certificat (ou le certificat d’autorités intermédiaires) pour vérifier l’authenticité du certificat transmis. Cette clé est stockée localement au sein du navigateur. Les navigateurs du marché sont donc distribués avec les clé publiques d’un nombre limité d’organisations reconnues pour être des tiers de confiance.

NB : L’architecture présentée ici ne fonctionnent bien évidement pas qu’avec le web mais cet exemple est particulièrement pédagogique.

Pourquoi Let’s encrypt ?

Lorsque j’ai installé dumaine.me sur un vieil ordinateur portable situé sous mon bureau, trois possibilités s’offraient à moi :

  • ne rien chiffrer, ce qui exposait le mot de passe ce blog par exemple
  • chiffrer en utilisant un certificat auto-signé : chaque visiteur souhaitant accéder à un contenu chiffré devait ajouter ce certificat à son navigateur. Je devais donc le transmettre par un canal « sûr » avant qu’il puisse se connecter : pas très pratique !
  • passer par une autorité de certification reconnue par la plupart des navigateurs du marché

Pour des questions pratiques, j’ai choisi cette troisième option. J’ai demandé à la seule autorité de certification (reconnue sur tous les OS par les navigateurs les plus utilisés) gratuite que je connaisse de signer mon certificat : StartSSL.

Ces organisations, la plupart à but lucratif, ont pour modèle économique de garantir différents niveaux de confiance, liés à différents niveaux de vérification, d’informations circulant sur internet, et principalement des certificats évoqués ci-dessus. StartSSL propose une gamme gratuite mais comportant certaines restrictions.

De nombreuses machinent hébergent des données personnelles sans chiffrer leur échanges car leur propriétaire n’a pas les moyens techniques et financiers de les sécuriser. Let’s encrypt tend à satisfaire ce besoin : il fournit une suite logicielle facilitant la configuration des serveurs web et propose de signer gratuitement les certificats produits via une autorité de certification reconnue (celle de Cisco en l’occurrence).

Quelles limites ?

Depuis son lancement à l’automne, la part des sites chiffrant leurs communications a augmentée significativement. Certains industriels incluent aujourd’hui les certificats Let’s encrypt dans des produits grands public (NAS, Freebox, domaines OVH, Gandi etc). De nombreuses données personnelles et/ou sensibles qui circulaient en clair il y a un an sont aujourd’hui chiffrées. Une victoire de plus pour Canard ? Ce n’est pas si simple…

Cette architecture de tiers de confiance constitue, avec le DNS et la hiérarchie des opérateurs (tiers 1 / tiers 2 / tiers 3), l’une des seules choses non horizontales, non distribuées (au mieux décentralisées) de l’architecture d’internet. Le fait que de nombreux utilisateurs passent par le même acteur pour chiffrer leurs communications peut potentiellement diminuer la résilience de l’ensemble. Cette autorité de certification devient un hony pot de plus en plus appétissant, que se soit en terme d’attaques ou de pressions politiques.

Le scandale Snowden a confirmé les craintes de la communauté informatique internationale : certains gouvernements espionnent massivement leur population. Let’s encrypt pourrait potentiellement leur faciliter le travail. L’épisode Lavabit confirme les pressions exercées sur des acteurs ciblés outre atlantique.

Dans la série « C’est quoi le pire ? » : se croire en sécurité lorsque ce n’est pas réellement le cas ou savoir que l’on est pas du tout en sécurité ? À partir de quand est-on « réellement » en sécurité ? Cette notion a-t-elle un sens indépendamment du contexte ?

Néanmoins, la formalisation d’un protocole (ACME) visant à simplifier la configuration et le renouvèlement de certificats, fussent-ils ou non distribués via l’autorité de certification Cisco, est une amélioration significative et aidera à la démocratisation de l’auto-hébergement.

Au delà de l’aspect technique, Let’s encrypt a une vertu indéniable : son buzz contribue à mieux faire connaitre des points fondamentaux de la sécurité informatique. Et qui sait, cela induira peut-être l’émergence d’une alternative réellement distribuée ? Des pistes sont actuellement explorées du côté de la blockchain…

#CodeImpots : premier bug ?

Mise à jour : si l’article posté était bien un poisson d’avril, le lien entre potentiels bugs et pratiques d’ouverture n’en reste pas moins intéressant.

Le code source de la calculatrice des impôts a été présenté ce matin. \o/ L’un des participants au hackathon #CodeImpots aurait découvert un bug d’arrondi qui pourrait engendrer des rappels si c’est réellement ce code qui est en production à la DGFiP.

Il va être intéressant de voir comment réagissent les autorités. Aux extrémités, je perçois deux postures :

  1.  « L’erreur est humaine, si nous avions partagé ce code plus tôt nous n’aurions peut-être pas poussé cette erreur en production. Le partage donne l’occasion à nos agents d’améliorer continuellement nos applications et nous leur en donnerons les moyens. Ce changement de culture se fera progressivement mais il faut prendre le pas tout de suite. Cette nouvelle pratique est la suite logique des démarches de mutualisation des SI. »
  2. « Ce coup de com’ était sympa mais revenons à nos pratiques ancestrales et à une opacité totale où l’on peut imaginer faire les choses parfaitement sans que ce soit vérifiable. Nous utiliserons à l’avenir l’exception de sécurité nationale de la loi pour une République Numérique pour bloquer toute nouvelle tentative d’accès par la CADA (article 1 bis du texte présenté au sénat). La volonté politique de changement n’est pas assez forte. »

Je croise les doigts pour que le premier cas l’emporte durablement !

Petite satisfaction personnelle pour terminer : la DGFiP a décidé d’utiliser Python pour développer son interpréteur. Mon langage préféré se diffuse donc au delà d’OpenFisca dans la sphère publique. 😉