© Groupe CGI inc. CONFIDENTIEL

SSL sur Internet : état 2013

Thomas Pornin 1er juin 2013

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

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

SSL : handshake

Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange*

CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify*

[ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data

4

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

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

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.

7

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

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

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

Versions

Version Nombre Fraction SSL 2.0 5084 36.71% SSL 3.0 13709 98.99% TLS 1.0 13508 97.54% TLS 1.1 3221 23.26% TLS 1.2 3254 23.50% SSL 2.0 seulement 17 0.12%

10

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

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

Algorithmes supportés

Cipher suite Nombre Proportion RSA_WITH_3DES_EDE_CBC_SHA 13300 96.0%

RSA_WITH_RC4_128_SHA 12907 93.2%

RSA_WITH_RC4_128_MD5 11991 86.6%

RSA_WITH_AES_128_CBC_SHA 11909 86.0%

RSA_WITH_AES_256_CBC_SHA 11894 85.9%

RSA_WITH_DES_CBC_SHA 7761 56.0%

RSA_EXPORT_WITH_RC4_40_MD5 5078 36.7%

RSA_EXPORT_WITH_RC2_CBC_40_MD5 4614 33.3%

RSA_EXPORT_WITH_DES40_CBC_SHA 4389 31.7%

RSA_WITH_IDEA_CBC_SHA 4361 31.5%

DHE_RSA_WITH_3DES_EDE_CBC_SHA 4211 30.4%

DHE_RSA_WITH_AES_128_CBC_SHA 4194 30.3%

DHE_RSA_WITH_AES_256_CBC_SHA 4158 30.0%

DHE_RSA_WITH_DES_CBC_SHA 2434 17.6%

DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 1819 13.1%

13

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

Certificats X.509

15

Certificats X.509 : chaînes

16

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

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

Types et tailles de clés

Aucune trace d’ECDSA ! Tout le monde fait du RSA.

19

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%

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

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

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)

22

Support Nombre Proportion CRL 7728 55.9% OCSP 4315 31.2% CRL ou OCSP 7741 56.1% CRL et OCSP 4302 31.1%

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

Questions ?