Votre javascript semble désactivé. Ce site l'utilise avec parcimonie et nous vous conseillons de le réactiver.

SSL et HTTPS
News rédigée par nodraak le 09 janvier 2016

Le site web de l'iTeam est désormais accessible via HTTPS, ainsi que certains sous domaines (pour le moment uniquement irc.iteam.org), et des redirections depuis les versions non HTTPS sont en place ! Le certificat est édité par Let's Encrypt.

Cet article va donc en profiter pour présenter le HTTPS. Pour les détails techniques avec Let's Encrypt, scrollez un peu.


Pourquoi chiffrer ?

Quand on visite des sites web, le protocole utilisé est le HTTP. Quand il a été conçu, au début de l'internet, le chiffrement n'était pas la priorité et HTTP a donc été conçu sans chiffrement. Le HTTP envoie donc toutes les données en clair, c'est-à-dire que n'importe qui peut écouter et comprendre les communications. Les usages d'internet ayant évolué, on ne navigue plus uniquement sur des sites web statiques : on peut maintenant payer en ligne, poster ses photos de vacances sur différents réseaux sociaux, ou encore écrire des articles pas forcément appréciés de tous les gouvernements.

Le fait que le premier venu puisse écouter vos communications est un problème majeur de sécurité (dont les conséquences vont d'un numéro de carte bleue ou de mots de passe dans la nature à l'exil forcé du lanceur d'alertes). La solution est de chiffrer les communications, pour cela une surcouche est ajoutée au HTTP : le SSL ; ce qui donne le HTTPS. (Le SSL peut aussi permettre de chiffrer d'autres protocoles : POP, IMAP et SMTP pour les emails, IRC pour la messagerie instantanée, etc.).

SSL et cadenas dans la barre d'adresse

Qu'est-ce que le SSL ?

Le SSL a été créé et développé par la société Netscape et RSA Security. Il en existe une version libre : OpenSSL que vous pouvez utiliser dans vos programmes sans payer de royalties. OpenSSL est libre : tout le monde peut l'utiliser, mais aussi contrôler et vérifier le code source. Le secret réside dans les clés de chiffrement utilisées, pas dans l'algorithme lui-même.

Le SSL assure en réalité trois choses :

  • Confidentialité (chiffrement) : empêche les personnes autres que le client et le serveur d'espionner la commnication. Cela protège les données confidentielles, comme par exemple les mots de passe.
  • Intégrité : assure que les informations reçues sont bien celles qui ont été envoyées et qu'elles n'ont pas été altérées.
  • Authentification : vérifie l'identité du serveur.

Le SSL est un système très ancien (~1995) qui existe en 3 versions, mais est aujourd'hui complètement cassé (la dernière version, SSL v3, a été bannie en 2014 suite à la faille POODLE et a été définitivement abandonnée en juin 2015). Une évolution du SSL, le TLS, a été développé dès 1999. TLS est basé sur SSL mais désactive certains algorithmes faibles (déjà cassés ou en passe de l'être) et en rajoute des nouveaux, plus solides.

Par abus de langage, on utilise la plupart du temps SSL pour désigner le TLS.

Lorsqu'une connexion utilise SSL, la plupart des navigateurs internet affichent un petit cadenas dans la barre d'adresse pour le signifier.

Alors quand je vois le cadenas, c'est sûr ?

Le cadenas vous indique que les communications entre votre navigateur et le site web sont sûres: personne ne peut les espionner, et personne ne peut trafiquer les communications. Mais il ne garantie rien d'autre !

Pour prendre une image: HTTPS (le cadenas), c'est un peu comme un fourgon blindé: Il vous assure la > sécurité du transport. Mais vraiment que du transport. Le fourgon blindé ne vous garantiera pas que la banque utilise de bons coffre-> forts et qu'elle les ferme bien. Le fourgon bindé ne garantie pas non plus que la banque ne fait pas de > malversations. Le fourgon blindé ne garantie vraiment que le transport.

C'est la même chose pour HTTPS (le petit cadenas du navigateur).

De la même manière que des truands peuvent louer les services d'un fourgon blindé, des pirates et truands peuvent très bien créer un site sécurisé (avec le petit cadenas).

Soyez vigilants, et ne confiez pas n'importe quelle information sur n'importe quel site, cadenas ou pas.

sebsauvage.net

Comment fonctionne le SSL ?

Il existe un grand nombre de paramètres qui peuvent varier (version utilisée, méthodes de chiffrement, méthodes de signature et méthodes de compression), ainsi chaque communication nécessite une préparation pour se mettre d'accord sur les paramètres qui seront utilisés : c'est le handshake (poignée de main ou négociation).

Handshake et communication

Au début de la communication, lors du handshake, le client et le serveur s'échangent un certain nombre d'informations afin de trouver le protocole commun le plus puissant :

  • Une liste des paramètres supportés1 :
    • protocoles et versions (SSL ou TLS, quelle version),
    • méthodes de chiffrement (AES, Camellia, DES, RC4, ...),
    • méthodes de signature (MD4, MD5, SHA, SHA1, ...),
    • méthodes de compression.
  • Les certificats.
  • Des nombres aléatoires.

Lors d'une communication chiffrée avec SSL, l'expéditeur des données va tout d'abord signer cryptographiquement les données (pour assurer l'authenticité et l'intégrité des données), puis chiffrer les données (pour assurer la confidentialité des données).

Celui qui réceptionne les données fait l'opération inverse : il déchiffre les données, puis vérifie la signature.

Certificats

Lors d'une négociation SSL, il faut s'assurer de l'identité de la personne avec qui on communique. Comment être sûr que le serveur auquel vous parlez est bien celui qu'il prétend être ? C'est là qu'interviennent les certificats. Au moment de vous connecter sur un serveur web sécurisé, ce dernier vous enverra un certificat contenant le nom de l'entreprise, son adresse, etc. C'est une sorte de pièce d'identité. Les certificats SSL lient ensemble un nom de domaine avec l'identité de l'organisation.

Comment vérifier l'authenticité de cette pièce d'identité ?

Les certificats SSL doivent être émis depuis le certificat racine d'une Autorité de Certification de confiance (Certification Authority), qui sont des sociétés externes (auxquelles vous faites implicitement confiance). La notion de confiance ici est très importante : un certificat est considéré comme fiable si son certificat racine est reconnu. Pour prendre une métaphore, les Autorités de Certification peuvent être comparées à l'État français qui est responsable de délivrer et d'assurer l'authenticité des cartes d'identité des citoyens. Si l'État français disparaissait ou n'était plus reconnu, les cartes d'identité françaises n'auraient plus aucune valeur.

Dans la pratique ces certificats racines sont présents sur la machine de l'utilisateur final. Seul un certain nombre de certificats racines reconnus sont ainsi présents (GlobalSign, DigiCert, VeriSign, ...). Si le certificat d'un site internet n'est pas reconnu, le navigateur affichera un message d'alerte indiquant qu'il ne faut pas lui faire confiance.

Là où des entreprises font payer les certificats (de l'ordre de 100€ ou 200€ par an, imaginez le budget pour les organisations aux revenus limités), Let's Encrypt les propose maintenant gratuitement et de manière automatique, ce qui permet au plus grand nombre de déployer SSL.

Let's Encrypt, une autorité de certification

Pour mettre en place une version HTTPS d'un site, il faut un certificat, qui est édité par une autorité reconnue, appelée autorité de certification. L'édition de certificats auprès de ces autorités est la plupart du temps payante, et prend quelques jours.

Let's Encrypt est une nouvelle autorité de certification, qui génère des certificats gratuitement, de manière automatique (et donc instantané) et qui est libre (qui ne dépend donc pas d'une entreprise).

Let's Encrypt a ouvert une bêta privée le 12 septembre 2015, et depuis le 3 décembre est en bêta publique. Pendant sa phase de bêta privée, Let's Encrypt a délivré plus de 26 000 certificats.

L'iTeam a participé à cette bêta privée et depuis déjà quelques mois sert son site internet en HTTPS grâce au certificat émis par Let's Encrypt.

Comment utiliser Let's Encrypt : les détails techniques

Obtenir les certificats

Pour commencer, il faut télécharger le client disponible sur Github qui se charge de récupérer le ou les certificats.

1
git clone https://github.com/letsencrypt/letsencrypt

Il faut ensuite arrêter un éventuel serveur HTTP (Apache, Nginx, etc.) car Let's Encrypt a besoin de démarrer un serveur sur le port 80 (ou alors il ne faut pas utiliser le plugin Standalone). On peut alors lancer le client qui se charge de tout.

1
./letsencrypt-auto certonly

Le script va ensuite se débrouiller tout seul (il commence par télécharger et mettre à jour les dépendances) et demander quelques informations (sauf si elles sont précisées via la ligne de commande) : un email de contact en cas de problèmes et une liste de un ou plusieurs domaine à sécuriser.

En cas de succès, Let's Encrypt affiche un gentil message :

1
2
3
4
5
6
7
8
9
IMPORTANT NOTES:
 * Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/iteam.org/fullchain.pem. Your cert will
   expire on 2016-03-31. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.
 * If like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Et voilà, en quelques commandes et quasiment immédiatement, les certificats sont récupérés et enregistrés dans /etc/letsencrypt/live/<domaine>/ !

La durée de validité des certificats est de trois mois, il faut donc renouveler les certificats régulièrement. On peut faire une crontab qui se chargera de ça, tous les deux mois pour avoir un peu de marge (pour le détail des options, voir --help et --help all).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
#!/bin/bash

# on se déplace dans le dossier de Let's Encrypt
cd /root/letsencrypt/

# on arrête apache pour que Let's Encrypt fonctionne
service apache2 stop

# Let's Encrypt fait son boulot
./letsencrypt-auto \
    certonly \
    --agree-tos \
    --domains iteam.org,www.iteam.org,irc.iteam.org \
    --email responsable@iteam.org \
    --renew-by-default \
    --rsa-key-size 4096 \
    --text

# on redémarre apache
service apache2 start

Configurer son serveur web (exemple avec Apache)

Une configuration SSL est un compromis entre sécurité et utilisabilité : un site requérant les algorithmes les plus récents et les plus sûrs sera très bien protégé mais seuls les utilisateurs ayant des logiciels à jour pourront s'y connecter. Cette configuration doit être mise à jour régulièrement, en fonction des découvertes de nouvelles faiblesses dans les algorithmes utilisés.

Pour activer le HTTPS sur Apache, il faut modifier deux fichiers :

  • /etc/apache2/ports.conf, pour écouter sur le port 443 :
1
2
3
4
<IfModule mod_ssl.c>
    NameVirtualHost *:443
    Listen 443
</IfModule>
  • /etc/apache2/httpd.conf, pour configurer les algorithmes :
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
SSLHonorCipherOrder     on
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256: \
    ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384: \
    ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: \
    DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256: \
    ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA: \
    ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA: \
    ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA: \
    DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA: \
    DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES: \
    !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA: \
    !KRB5-DES-CBC3-SHA

On commence par désactiver le SSL pour ne garder que le TLS (c'est un compromis acceptable, dans l'idéal on ne garderait que TLS v1.2). La liste des cipher est construite à partir du générateur de Mozilla et modifiée suite aux informations de ssllabs et d'Imirhil qui donnent une note et indiquent les vulnérabilités.

On peut finalement mettre à jour chaque vhost (/etc/apache2/site-available/*) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<IfModule mod_ssl.c>
    <VirtualHost *:443>
        # Configuration classique
        # ...

        # SSL
        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/iteam.org/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/iteam.org/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/iteam.org/chain.pem
        # HSTS (voir en dessous) :
        Header always set Strict-Transport-Security "max-age=7776000"
    </VirtualHost>
</IfModule>

Le HSTS (Strict-Transport-Security) fait partie des best practices : cet en-tête annonce au client que le site doit être accédé uniquement via HTTPS, et ce pour la durée spécifiée (ici 7776000 sec, soit 3 mois).

On peut également mettre en place des redirections vers la version HTTPS :

1
2
3
4
5
# http://iteam.org -> https://iteam.org
<VirtualHost *:80>
    ServerName iteam.org
    Redirect permanent / https://iteam.org/
</VirtualHost>

Sources :


    • Un chiffrement asymétrique, (RSA, DH, ...), qui permet, après authentification de la clef publique du serveur, la constitution d'un secret partagé entre le client et le serveur.
    • Un chiffrement symétrique (beaucoup plus rapide que les chiffrements asymétriques), (AES, Camellia, DES, RC4, ...), qui est utilisé dans la phase d'échange de données, les clefs de chiffrement symétrique étant calculées à partir du secret partagé.
    • Une fonction de hachage (MD4, MD5, SHA, SHA1, ...) est également utilisée, pour assurer, entre autres, l'intégrité des données.