0
SSL sur Internet : état 2013
Thomas Pornin
1er juin 2013
© Groupe CGI inc. CONFIDENTIEL
SSL
•  Utilise un transport par flux bidirectionnel d’octets
•  Fournit un transport par flux bidirectionnel d’octets sécu...
SSL : historique
•  Initialement conçu par Netscape (Secure Sockets Layer) :
•  SSL 1.0 : jamais publiée
•  SSL 2.0 : « pu...
SSL : handshake
Client
ClientHello

Server
-------->
ServerHello
Certificate*
ServerKeyExchange*
<--------

CertificateReq...
SSL : handshake
Le client propose :
•  Version maximale du protocole
•  Cipher suites (combinaisons d’algorithmes cryptogr...
Méthodologie
Essayer des adresses IPv4 aléatoires :
•  Connexion au port 443
•  Si un serveur répond, faire plusieurs hand...
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
•  ...
IPcalypse : SSL responsable ?
Dans HTTPS, le handshake a lieu d’abord, puis le dialogue HTTP
survient.
!  Lors du handshak...
IPcalypse : SSL innocent ?
Seulement 0.62% (ou même 0.54%) des adresses IP contactées ont un
serveur SSL.

•  SSL n’est pa...
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

...
Choix de la cipher suite et attaque BEAST
Théoriquement, le serveur suit l’ordre de préférence du client.
BEAST (Duong et ...
Compression et CRIME
CRIME (Duong et Rizzo 2012) :
•  Même contexte que BEAST
•  Beaucoup plus facile à appliquer (requête...
Algorithmes supportés
Cipher suite

Nombre

Proportion

RSA_WITH_3DES_EDE_CBC_SHA

13300

96.0%

RSA_WITH_RC4_128_SHA

129...
Horloges
Dans le ClientHello et le ServerHello, client et serveur envoient
des séquences aléatoires de 32 octets. Le stand...
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...
Certificats réutilisés
13810 serveurs présentant un certificat, mais seulement 10147 chaînes
distinctes : certaines chaîne...
Types et tailles de clés
Algorithme

Taille (bits)

Nombre

Proportion

RSA

512

68

0.67%

RSA

768

95

0.94%

RSA

~10...
Validité et expiration des certificats
Sur les 13810 serveurs avec certificat :
•  2915 (21.1%) ont au moins un certificat...
Encodage incorrect de certificat X.509
Environ 3% des chaînes contiennent au moins un certificat qui n’est pas
strictement...
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 v...
Conclusions
•  Il y a beaucoup de serveurs « non standard » déployés, pour usages
spécifiques.
•  Les évolutions technolog...
Questions ?
Upcoming SlideShare
Loading in...5
×

BSidesQuebec2013-ssl

107

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
107
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "BSidesQuebec2013-ssl"

  1. 1. SSL sur Internet : état 2013 Thomas Pornin 1er juin 2013 © Groupe CGI inc. CONFIDENTIEL
  2. 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. 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
  4. 4. SSL : handshake Client ClientHello Server --------> ServerHello Certificate* ServerKeyExchange* <-------- CertificateRequest* ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] Application Data <-------<-------> 4 Finished Application Data
  5. 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. 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. 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. 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. 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
  10. 10. 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% 17 0.12% SSL 2.0 seulement 10
  11. 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. 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
  13. 13. 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
  14. 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
  15. 15. Certificats X.509 15
  16. 16. Certificats X.509 : chaînes 16
  17. 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. 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. 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. 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. 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. 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. 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
  24. 24. Questions ?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×