2. SSL
• Utilise un transport par flux bidirectionnel d’octets
• Fournit un transport par flux bidirectionnel d’octets sécurisé :
• Confidentialité : chiffrement
• Intégrité : les altérations sont détectées
• Authentification du serveur : par certificat X.509
• Authentification du client (optionnel)
• Utilisé comme base dans plusieurs protocoles, en particulier HTTPS :
• Le transport sous-jacent est une connexion TCP (port par défaut : 443)
• Le client « sait » qu’il doit faire du HTTPS (l’URL commence par https://)
• Un premier dialogue établit les paramètres cryptographies (« handshake »)
• Le protocole HTTP est ensuite appliqué dans le tunnel
2
3. SSL : historique
• Initialement conçu par Netscape (Secure Sockets Layer) :
• SSL 1.0 : jamais publiée
• SSL 2.0 : « publiée » en février 1995
• SSL 3.0 : 1996 (cf RFC 6101)
• Pris en charge par l’IETF (Transport Layer Security) :
• TLS 1.0 ( = SSL 3.1) : janvier 1999 (RFC 2246)
• TLS 1.1 : avril 2006 (RFC 4346)
• TLS 1.2 : août 2008 (RFC 5246)
• SSL 2.0 est maintenant « prohibé » (RFC 6176, mars 2011)
• SSL 2.0 n’a pas de détection fiable de la fin de connexion
3
5. SSL : handshake
Le client propose :
• Version maximale du protocole
• Cipher suites (combinaisons d’algorithmes cryptographiques)
• Algorithmes de compression de données
• Extensions…
Le serveur dispose :
• Le serveur choisit la version, la cipher suite, la compression…
Authentification :
• Le serveur envoie sa clé publique sous la forme d’un certificat
• Le client valide le certificat du serveur par rapport à des autorités racines
qu’il connaît a priori
• Le client vérifie que le nom attendu du serveur (celui qui apparaît dans
l’URL) est bien inscrit dans le certificat (validé)
5
6. Méthodologie
Essayer des adresses IPv4 aléatoires :
• Connexion au port 443
• Si un serveur répond, faire plusieurs handshakes pour savoir ce que le
serveur supporte (extraction de la liste des cipher suites une par une)
• Recommencer pour chaque version du protocole
• Aucun handshake n’est complété (on s’arrête au ServerHelloDone)
•
•
•
•
•
•
Client multithreadé, écrit en C#
Une nouvelle adresse essayée chaque seconde
Plateforme : un serveur virtuel sous Linux (loué à memset.com)
2585566 adresses contactées (sur 1 mois)
16027 serveurs trouvés
… recontactés une semaine après, seuls 13848 ont répondus à
nouveau (86.4%)
6
7. IPcalypse
Adresse IPv4 : 32 bits
Certaines plages sont réservées (environ 13.8% du total) :
• 0.0.0.0/8
• 10.0.0.0/8
• 224.0.0.0/4
• 240.0.0.0/4
• …
Il y a 3702258679 adresses IPv4 possibles.
L’IPcalypse survient quand toutes les adresses sont épuisées.
RIR
blocs /24 libres
IPcalypse
jours restants
Afrinic (Afrique)
220631
11/11/2019
2353
APNIC (Asie + Pacifique)
72640
15/04/2011
-779
ARIN (Amérique du Nord)
401419
27/08/2013
86
LACNIC (Amérique Latine)
175524
27/05/2015
724
RIPE (Europe et Asie centrale)
68474
14/09/2012
-261
7
8. IPcalypse : SSL responsable ?
Dans HTTPS, le handshake a lieu d’abord, puis le dialogue HTTP
survient.
! Lors du handshake, le serveur ne connaît pas encore l’URL, et
notamment le nom sous lequel il est connu du client.
! Mais le certificat du serveur doit contenir ce nom.
! Donc HTTPS n’est pas compatible avec le Virtual Hosting.
Solutions :
• Ajouter une extension SSL qui indique le nom visé (Server Name
Indication : RFC 6066)(non supporté par WinXP+IE, Android 2.*, Java
pre-1.7)
• Mettre plusieurs noms dans un certificat (+ wildcards)
• Acheter une adresse IPv4 par site
• Attendre IPv6 (déploiement mondial prévu en 2007…)
8
9. IPcalypse : SSL innocent ?
Seulement 0.62% (ou même 0.54%) des adresses IP contactées ont un
serveur SSL.
• SSL n’est pas responsable du problème
• Corriger SSL (extension SNI) ne résoudra pas le problème
• L’essentiel des IP est consommé par les particuliers
• En attendant IPv6, les plus gros ISP envisagent des proxys + NAT
9
11. Choix de la cipher suite et attaque BEAST
Théoriquement, le serveur suit l’ordre de préférence du client.
BEAST (Duong et Rizzo 2011) :
• Attaque sur le client quand il utilise un chiffrement de type CBC en SSL 3.0
ou TLS 1.0
• Nécessite un code hostile sur le client (contexte Web avec Javascript et
requêtes cross-domaines)
• Ne marche pas actuellement (plusieurs niveaux de contremesures sont
installées dans les navigateurs Web)
• Le serveur peut protéger le client en imposant une préférence pour les
algorithmes non-CBC (par exemple RC4).
En pratique : 71.1% des serveurs suivent les préférences du client,
27.5% imposent leur ordre, et 1.4% font « autre chose » (0.58%
choisissent une cipher suite non annoncée par le client…).
Mais : 82.7% des serveur ne protègent pas contre BEAST.
11
12. Compression et CRIME
CRIME (Duong et Rizzo 2012) :
• Même contexte que BEAST
• Beaucoup plus facile à appliquer (requêtes de type <img>)
• Utilise la compression pour reconstruire un cookie (le chiffrement ne cache
pas la longueur des données)
• L’attaque concerne là encore le client, mais le serveur peut protéger le client
en refusant d’appliquer la compression SSL
• La compression au niveau HTTP n’est pas concernée (car elle s’applique
seulement sur le corps des requêtes, pas sur les entêtes)
14.0% des serveurs supportent la compression SSL.
12
14. Horloges
Dans le ClientHello et le ServerHello, client et serveur envoient
des séquences aléatoires de 32 octets. Le standard indique que les
quatre premiers octets ne sont pas aléatoires, mais doivent contenir
l’heure courante (en nombre de secondes depuis le 1er janvier 1970).
7.6% des serveurs (1053) n’envoient pas l’heure courante.
Sur les 12795 autres serveurs :
• Environ 65% sont précis à la seconde
• 10% sont décalés de plusieurs heures
14
17. SSL et certificats
Le serveur possède une clé privée :
• En connaissant la clé privée du serveur, on peut mettre en place un faux
serveur de même nom
• En connaissant la clé privée du serveur, on peut déchiffrer les connexions
(sauf usage d’une cipher suite de type DHE)
• La clé publique correspondante est dans le certificat du serveur
• L’authentification du serveur par le client, c’est quand le client s’assure qu’il
connaît la vraie clé publique du serveur attendu
• 0.27% des serveurs n’envoient pas de certificat du tout (ils supposent
que le client le connaît déjà).
• 0.53% des serveurs possèdent plusieurs certificats et n’envoient pas
toujours le même.
17
18. Certificats réutilisés
13810 serveurs présentant un certificat, mais seulement 10147 chaînes
distinctes : certaines chaînes (et clés privées) sont partagées.
Une des chaînes apparaît à 1071 reprises (sur Internet, environ 1.5
millions de systèmes utilisent cette clé « privée ») !
• Apparemment, c’est un certificat + clé par défaut sur des routeurs
« personnels » utilisant mini-httpd.
Une autre chaîne revient 155 fois : certificat par défaut pour routeurs
ADSL Vodafone (Italie).
33.2% des chaînes sont réduites à un unique certificat auto-signé (pas
d’autorité de certification, « validation » manuelle et enregistrement par le
client).
18
19. Types et tailles de clés
Algorithme
Taille (bits)
Nombre
Proportion
RSA
512
68
0.67%
RSA
768
95
0.94%
RSA
~1024
3378
33.29%
RSA
1279
1
0.01%
RSA
~2048
6495
64.00%
RSA
3072
1
0.01%
RSA
4096
100
0.99%
DSA
1024
6
0.06%
Gost R 34.10-1994
1024
1
0.01%
Gost R 34.10-2001
256 (ECC)
2
0.02%
Aucune trace d’ECDSA ! Tout le monde fait du RSA.
19
20. Validité et expiration des certificats
Sur les 13810 serveurs avec certificat :
• 2915 (21.1%) ont au moins un certificat expiré dans leur chaîne
• 20 (0.14%) ont au moins un certificat non encore valide dans leur chaîne
Y2038 : la version binaire du « bug de l’an 2000 »
• Les machines « genre Unix » représentent les dates comme un compte de
secondes depuis le 1er janvier 1970 00:00 UTC, sur 32 ou 64 bits.
• Le 19 janvier 2038, à 03:14:08 UTC, ce compte atteint 231 : les machines
qui utilisent un entier 32 bits signé se croiront le 13 décembre 1901.
• Les autorités racine « usuelles » ont quasiment toutes une date de fin de
validité au plus tard en 2037 afin de ne pas produire ce problème en
avance.
156 des serveurs (1.13%) utilisent une chaîne avec au moins une date
au delà du 19 janvier 2038.
20
21. Encodage incorrect de certificat X.509
Environ 3% des chaînes contiennent au moins un certificat qui n’est pas
strictement conforme au standard (RFC 5280) :
• Numéro de série négatif ou au-delà de la limite prescrite (2159)
• Caractère invalide dans une chaîne PrintableString
• Date avec fuseau horaire
• Etc…
18.7% des chaînes utilisent encore TeletexString. 5.3% utilisent
BMPString. Pourtant, le standard de 1999 (RFC 2459) indique :
The DirectoryString type is defined as a choice of PrintableString,!
TeletexString, BMPString, UTF8String, and UniversalString.
The!
UTF8String encoding is the preferred encoding, and all certificates!
issued after December 31, 2003 MUST use the UTF8String encoding of!
DirectoryString (except as noted below).!
21
22. X.509 et révocation
La révocation est le mécanisme servant à déclarer qu’un certificat ne
doit plus être considéré comme valide. Un client ne devrait accepter un
certificat de serveur qu’après avoir obtenu une preuve « fraîche » que le
certificat n’est pas révoqué.
Deux mécanismes :
• CRL : liste des numéros de série des certificats révoqués, signée par l’AC
• OCSP : serveur donnant le statut d’un certificat donné, sur requête (avec
signature)
Support
Nombre
Proportion
CRL
7728
55.9%
OCSP
4315
31.2%
CRL ou OCSP
7741
56.1%
CRL et OCSP
4302
31.1%
22
23. Conclusions
• Il y a beaucoup de serveurs « non standard » déployés, pour usages
spécifiques.
• Les évolutions technologiques se déploient lentement.
• Les vendeurs de matériels embarqués font n’importe quoi.
• Personne ne veut être le premier à utiliser certaines innovations (IPv6,
ECDSA…).
23
