[Sécurité] Ce que j’attends d’un service Web

honor-guardAprès avoir sillonné le Web et ses nombreux services, je pense qu’aujourd’hui je suis en mesure d’établir une petite liste des choses que j’attends d’un service orienté Web au niveau de la sécurité. Pour rappel, je commencerai par la phrase suivante:

Ce n’est pas parce qu’un prestataire vous dit qu’il est sécurisé qu’il faut lui faire aveuglément confiance. La confiance passe par la vérification.

Ainsi, on peut dire que des prestataires comme Microsoft et son cloud Office (notamment par le biais de son service OneDrive) paraît sécurisé, mais c’est pourtant lui qui garde les clés de vos données. Ce qui n’est pas nécessairement de bonne augure lorsqu’on le soupçonne de faire copain-copain avec la NSA, de leur propre gré ou non.

Voyons donc les éléments de ce dossier, en bref:

  • La liaison entre le prestataire et le particulier doit être sécurisée
  • Les données doivent être chiffrées une fois entreposées chez le prestataire
  • Le prestataire ne doit pas avoir connaissance de la clé de chiffrement

Je me rends bien compte que ce niveau de sécurité, que j’estime être « raisonnablement bon », n’est de loin pas respecté par tous et qu’il peut même être excessif suivant la nature du service prodigué. Il me semble néanmoins que c’est le moins que l’on puisse attendre d’un service qui manipule des données sensibles ou personnelles.

La liaison sécurisée

Il s’agit du premier rempart face à un éventuel pirate informatique. Si la liaison est sécurisée (petit cadenas dans la barre d’adresse du navigateur) via un certificat SSL qui tient la route, n’importe qui ne peut pas s’introduire entre deux et réaliser une attaque de type MITM. Cependant, un simple cadenas n’est pas suffisant si l’on cherche à faire de la « bonne » sécurité.

Désactivation de la liaison non-sécurisée

On peut mettre en place toute la sécurité que l’on veut sur la liaison en elle-même, s’il reste une possibilité de forcer le trafic sur un canal non sécurisé (HTTP) la compromission des informations est très facile pour un hacker. Règle d’or: désactiver toute possibilité d’utiliser du HTTP simple lorsqu’on a mis en place du HTTPS.

Par exemple, un simple fichier .htaccess (Apache 2.x) à la racine du site peut faire l’affaire:

RewriteEngine On
RewriteCond %{SERVER_PORT} ^80$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Il reste simplement à valider la configuration avec un petit « service apache2 reload » qui va bien.

PFS – Perfect Forward Secrecy

La liaison peut être sécurisée d’autant mieux en mettant en oeuvre PFS. Cette couche supplémentaire s’assure que toute compromission de session de navigation n’entraine pas celle des sessions passées et futures. Il s’agit d’un standard aujourd’hui dans les liaisons sécurisées qui implique de renouveler la clé de chiffrement de la conversation à chaque nouvelle session. De cette manière, même si le trafic est surveillé, il est impossible de le déchiffrer en entier. Plutôt pratique.

L’activation de PFS dans Apache 2.x se fait très facilement dans le fichier du VirtualHost déjà forcé avec une liaison SSL:

SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

Il reste simplement à valider la configuration avec un petit « service apache2 reload » qui va bien.

HSTS – HTTP Strict Transport Security

De manière très brève, HSTS est une fonctionnalité du serveur Web qui indique au navigateur que celui-ci ne devrait jamais utiliser sa version HTTP non-sécurisée. Le navigateur de l’internaute va donc, selon les procédures définies, tenter automatiquement de le rediriger vers la version sécurisée. Cette fonction permet d’éviter qu’un internaute se mette à dialoguer en clair avec le serveur de manière inattendue. C’est un peu comme si le serveur disait au navigateur « chut, viens discuter ailleurs plutôt, on est peut-être surveillés ici ».

HSTS se met en place également très facilement dans Apache 2.x grâce aux instructions suivantes dans le VirtualHost déjà forcé en SSL:

Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"

Notez que si mod_header n’est pas activé sur votre serveur Apache, il sera nécessaire de le faire via la commande (applicable pour les serveurs Debian récents):

a2enmod headers

Il reste simplement à valider la configuration avec un petit « service apache2 restart » qui va bien.

Chiffrement des données

Pour un bon niveau de sécurité et afin d’éviter les fuites de données (data leaks) que l’on connait chez de nombreux grands pontes du Web ces dernières années, il est nécessaire de chiffrer le plus de données possibles, essentiellement les données liées aux utilisateurs et permettant – directement ou non – de les identifier. Pour ce faire, l’utilisation des techniques de cryptographie traditionnelles peut être envisagée, que ce soit par chiffrement symétrique ou asymétrique.

Le mieux reste l’asymétrique (p. ex: PGP) et vous allez comprendre pourquoi dans le chapitre suivant 😉

Isolation des données et des clés

Le dernier point pour assurer une bonne sécurité chez un prestataire est de séparer les responsabilités. La personne (physique ou morale) qui détient les données ne doit pas non plus détenir les clés de chiffrement, sans quoi il devient affreusement facile pour un pirate informatique de déchiffrer tout ce qui était caché à l’origine. C’est sur ce point précis que des prestataires comme Microsoft ou Dropbox pêchent à mort. Ils détiennent vos données, les sécurisent avec leurs algorithmes et gardent les clés pour vous « faciliter la vie ». Pourtant, certains prestataires comme ProtonMail, dont j’ai déjà parlé plusieurs fois sur ce blog, y arrivent !

Comment font-ils ? Et bien la réponse est simple: ils stockent vos données et vous les renvoient chiffrées, puis vous les déchiffrez. Le processus complet devrait ressembler à ceci pour assurer une bonne sécurité dans un service Web:

  1. Le client (vous) s’authentifie auprès du prestataire
    1. Via un classique couple login/password; ou
    2. Avec une double authentification (login/password + token/SMS/email instantané)
  2. Le prestataire vous envoie vos données chiffrées
  3. Vous saisissez un (autre) mot de passe pour déverrouiller votre clé privée (PGP)
  4. Votre clé privée déchiffre vos données

Et inversement, lorsque vous avez terminé:

  1. Votre clé privée chiffre vos données
  2. Votre clé privée se verrouille (pas besoin de retaper votre mot de passe)
  3. Vous vous authentifiez auprès du prestataire (si ce n’est pas encore fait; voir point 1 du processus précédent)
  4. Vous envoyez vos données chiffrées au prestataire via une liaison sécurisée
  5. Le prestataire stocke vos données

Le mot de la fin

Simple en apparence, non ? Et bien sachez que tout ceci peut être mis en place avec des technologies actuelles et de manière ergonomiquement acceptable. Cela signifie qu’il est même envisageable de réaliser ce genre de service en ligne via un navigateur Web capable de stocker une clé privée de manière sécurisée (et même IE sait le faire, hein, alors !). Il serait donc possible d’accéder à toutes vos données chiffrées aussi simplement qu’aujourd’hui, mais avec une couche sécuritaire beaucoup plus développée.

Le seul problème reste encore la bande passante de votre connexion Internet et la lenteur d’accès à de gros volumes de données. Pour cela, j’imagine que d’autres solutions doivent exister.

Source de l’image d’entête: Pixabay.

Quelques sources utilisées pour la rédaction de ce dossier: