SSL/TLS pour les nuls (#oupa)

@aeris
20 juin 2015, PSES

Aeris

Groupe cyber-terroriste individuel
Auto-radicalisé sur Internet

Mail / Jabber : aeris@imirhil.fr
GNU/Social : https://status.imirhil.fr/
Blog : https://blog.imirhil.fr/
Conférences : https://confs.imirhil.fr/

GPG : EFB7 4277 ECE4 E222
OTR : 5769 616D 2D3D AC72

Sécurité des communications — Transport

2 modes de protection

Point-à-point (TLS…)
End-to-End (GPG, OTR…)

Historique de SSL/TLS

1994 : SSL v1.0 (théorie, jamais mise en œuvre)
1995 : SSL v2.0 (trop moisi, SSL v3.0 lancé dans la foulée)
1996 : RFC 6101, SSL v3.0 (tout moisi aussi, + 2014 : Poodle)
1999 : RFC 2246, TLS v1.0
2006 : RFC 4346, TLS v1.1
2008 : RFC 5246, TLS v1.2

Objectifs

Les chiffrements symétriques (AES, RC4, DES) sont

rapides et supportent les flux

mais reposent sur un partage de secret

Les chiffrements asymétriques (RSA, DSS, ECDSA) sont

lents et ne supportent pas les flux

mais ne supposent pas une ligne sécurisée

Objectifs

SSL/TLS est un protocole couplant

un échange de secret par chiffrement asymétrique

un chiffrement symétrique avec ce secret

SSL/TLS doit assurer 3 fonctions :

l’authentification
le chiffrement
l’intégrité

Authentification & échange de clef

Chiffrement

Seuls chiffrements encore fiables à l’heure actuelle :

AES (128/256 bits)
CAMELLIA (128/256 bits)
SEED (128 bits)

Très attendus :

CHACHA20+POLY1305 (256 bits)
GOST (256 bits)
ED25519 (ECC)

Intégrité

MD-5 totalement cassé
SHA-1 en passe de l’être
SHA-2 ou supérieur

Exemple : IE 6

Exemple : IE 11

Exemple : Chrome 37

Exemple : Firefox 32

Comment qu’on se cause alors ?

« Eh, coucou, je cause SSLv3, TLSv1.0 et TLSv1.1 ! Et toi ? »

« Je cause TLSv1.0, TLSv1.1 et TLSv1.2. On a qu’à causer TLSv1.1 donc ! »

« OK, mais quel dialecte ? Je cause [insérer ici whatmille cipher]. »

« Moi je cause [insérer ici un bouzillion de cipher], on a qu’à causer TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ! »

Perfect Forward Secrecy (PFS)

Échange de clef initial :

Le client génère un nombre aléatoire C l’envoie en clair
Le serveur génère un nombre aléatoire S l’envoie en clair
Le client
- génère aléatoirement la pré-clef maîtresse P′
- calcule la clef maîtresse P = f(P', C, S)
- envoie P′ _chiffré
Le serveur
- déchiffre P′ avec sa clef privée
- calcule P = f(P′, C, S)

Perfect Forward Secrecy (PFS)

Un attaquant peut enregistrer l’intégralité du flux chiffré
Il peut mettre la main sur la clef privée par la suite
- Il a accès à C et S, qui circulaient en clair
- Il peut déchiffrer P′ avec la clef privée compromise
- Il peut recalculer P !
Il peut alors déchiffrer l’intégralité des communications enregistrées !

⇒ Nécessité de la Perfect Forward Secrecy

(Promis, je vous épargne la théorie mathématique 😁)

L’enfer TLS

Très dépendant de la compétence des administrateurs https://imirhil.fr/tls.html

L’enfer TLS

Très dépendant de la compétence des administrateurs https://imirhil.fr/tls.html

L’enfer TLS

4 lignes pour se mettre à l’abri

Caisse d’Épargne : 2 ans and counting…

SSLCipherSuite EECDH+AES:+AES128:+AES256:+SHA
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLCompression off

Résumé

Disponible pour plus ou moins tout (Web, mail…)
Transparent pour l’utilisateur
~~Mauvaise volonté~~ Bon vouloir des admins
InCompétences des admins
Sécurité « opportuniste »
Transparent pour l’utilisateur

Sécurité des communications — TLS

FAUX !

HTTPS garantit uniquement que :

seul le serveur en face peut lire mes informations
que le serveur en face a été approuvé par une des 181 autorités de certification embarquées dans le navigateur

Pas que c’est bien ma banque en face !

Sécurité des communications — TLS

TLS est basé sur une chaîne de confiance :
Les amis de mes amis sont mes amis.

Mais qui sont mes amis qui n’ont aucun ami au-dessus ?

⇒ Embarqués « en dur » dans le navigateur

181 dans Mozilla Firefox

Problème :

Gouvernement chinois, syrien, turc, français…
Microsoft, Dell, AOL, Atos…
Comodo, Digicert, RSA…
Bref, la moitié de la planète…

Sécurité des communications — TLS

CACert, autorité de certification communautaire

⇒ Supprimée des dépôts standards

Considération purement technique/physique
- Résister à 1600° pendant 2h
- Résister au crash d’un Boeing à pleine vitesse
Mais qu’une didactature ou une entité commerciale/gouvernementale ait accès à la clef privée n’est pas génant

HTTP Strict Transport Security (HSTS)

Un site peut commencer en clair et décider ensuite de faire du HTTPS
Tout le monde peut faire des liens vers n’importe qui et n’importe comment
Il y a des gros michants qui s’amusent avec le réseau (SSLStrip)

HTTP Strict Transport Security (HSTS)

On a quand même envie de protéger nos utilisateurs et de les obliger à passer en HTTPS

S’il clique sur un (vieux) lien HTTP
S’il clique sur un lien qu’on ne maîtrise pas
S’il y a un gros michant sur sa ligne

⇒ En-tête HSTS

Une fois le site consulté une 1ère fois, il mémorise qu’il doit obligatoirement revenir dessus en HTTPS

S’il voit du HTTP, il redirige automatiquement et sans aucune requête en clair vers la version HTTPS

HTTP Public Key Pinning (HPKP)

Problème de la confiance en les CA

CA compromise
CA pas intégrée (CAcert, CA perso…)
pas de CA du tout (auto-signé)

Alerte anxiogène pour l’utilisateur

Voire pas d’alerte du tout !

HPKP embarque l’empreinte du certificat dans les en-têtes

Header always set Public-Key-Pins \
"max-age=31536000; pin-sha256=\"Qxj9WO4/TmT/MlQW2Mbmy7yD91Yv3L/CsB3G4lLAuUE=\""

DNSSec + DANE/TLSA

Même problématique que HKPK

DANE/TLSA déclare le certificat utilisé dans le DNS, protégé par DNSSec

Plus complet, permet un contrôle plus fin :

0/2 : contrainte sur la CA, 1/3 : contrainte sur le certificat
0/1 : respecte X.509, 2/3 : shunte X.509
0 : certificat complet, 1 : clef publique
0 : valeur complète, 1 : SHA-256, 2 : SHA-512

_443._tcp.blog TLSA 1 1 2 \
2F8C1697D3B1F77016E89489A12F6F0F39162F547866E5030474D370 \
EB552FAEC8821E1FC1597F5A2BA3ADC12993EEB222F6D1A9E6A21DE1 \
24745A5FE5863F74