SlideShare une entreprise Scribd logo
1  sur  24
Télécharger pour lire hors ligne
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é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
ClientHello

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

CertificateRequest*
ServerHelloDone

Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished

-------->
[ChangeCipherSpec]

Application Data

<-------<------->

4

Finished
Application Data
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.
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
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%

17

0.12%

SSL 2.0 seulement

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
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
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)
Support

Nombre

Proportion

CRL

7728

55.9%

OCSP

4315

31.2%

CRL ou OCSP

7741

56.1%

CRL et OCSP

4302

31.1%

22
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 ?

Contenu connexe

En vedette

SSL/TLS Présentation en Français.
SSL/TLS Présentation en Français.SSL/TLS Présentation en Français.
SSL/TLS Présentation en Français.Philippe Lhardy
 
Présentation sécurité open_ssl
Présentation sécurité open_sslPrésentation sécurité open_ssl
Présentation sécurité open_ssldihiaselma
 
ASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain Maret
ASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain MaretASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain Maret
ASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain MaretSylvain Maret
 
Authentification des protocoles de routage
Authentification des protocoles de routageAuthentification des protocoles de routage
Authentification des protocoles de routageThomas Moegli
 
Introduction to SSL/TLS
Introduction to SSL/TLSIntroduction to SSL/TLS
Introduction to SSL/TLSkeithrozario
 
Secure Socket Layer
Secure Socket LayerSecure Socket Layer
Secure Socket LayerNaveen Kumar
 
Introduction to Secure Sockets Layer
Introduction to Secure Sockets LayerIntroduction to Secure Sockets Layer
Introduction to Secure Sockets LayerNascenia IT
 

En vedette (9)

Zona G Bogotá
Zona G BogotáZona G Bogotá
Zona G Bogotá
 
SSL/TLS Présentation en Français.
SSL/TLS Présentation en Français.SSL/TLS Présentation en Français.
SSL/TLS Présentation en Français.
 
Présentation sécurité open_ssl
Présentation sécurité open_sslPrésentation sécurité open_ssl
Présentation sécurité open_ssl
 
ASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain Maret
ASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain MaretASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain Maret
ASFWS 2012 / Initiation à la sécurité des Web Services par Sylvain Maret
 
Cisco ASA
Cisco ASACisco ASA
Cisco ASA
 
Authentification des protocoles de routage
Authentification des protocoles de routageAuthentification des protocoles de routage
Authentification des protocoles de routage
 
Introduction to SSL/TLS
Introduction to SSL/TLSIntroduction to SSL/TLS
Introduction to SSL/TLS
 
Secure Socket Layer
Secure Socket LayerSecure Socket Layer
Secure Socket Layer
 
Introduction to Secure Sockets Layer
Introduction to Secure Sockets LayerIntroduction to Secure Sockets Layer
Introduction to Secure Sockets Layer
 

Similaire à BSidesQuebec2013-ssl

Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)Afnic
 
Cours HTTPS pour UnPointZero
Cours HTTPS pour UnPointZeroCours HTTPS pour UnPointZero
Cours HTTPS pour UnPointZeroCHILDZ Laurent
 
Projet Pki Etapes Clefs
Projet Pki   Etapes ClefsProjet Pki   Etapes Clefs
Projet Pki Etapes Clefsfabricemeillon
 
Push to the web - Websocket et SignalR
Push to the web -  Websocket et SignalRPush to the web -  Websocket et SignalR
Push to the web - Websocket et SignalRMSDEVMTL
 
cours-gratuit.com--CoursInformatique-id3180.pdf
cours-gratuit.com--CoursInformatique-id3180.pdfcours-gratuit.com--CoursInformatique-id3180.pdf
cours-gratuit.com--CoursInformatique-id3180.pdfGodefroyCheumaniTche1
 
Rapport sécurité
Rapport sécuritéRapport sécurité
Rapport sécuritédihiaselma
 
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)Hackfest Communication
 
EIGRP - Authentification
EIGRP - Authentification EIGRP - Authentification
EIGRP - Authentification mdyabi
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfdepinfo
 
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB plc
 
Alphorm.com Formation CEHV9 IV- partie 2
Alphorm.com Formation CEHV9 IV- partie 2Alphorm.com Formation CEHV9 IV- partie 2
Alphorm.com Formation CEHV9 IV- partie 2Alphorm
 
Présentation Microsoft Advanced Threat Analytics | Deep-Dive - MSCloud Summi...
Présentation Microsoft Advanced Threat Analytics  | Deep-Dive - MSCloud Summi...Présentation Microsoft Advanced Threat Analytics  | Deep-Dive - MSCloud Summi...
Présentation Microsoft Advanced Threat Analytics | Deep-Dive - MSCloud Summi...☁️Seyfallah Tagrerout☁ [MVP]
 
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...Cyber Security Alliance
 
VPN site-to-site.pdf
VPN site-to-site.pdfVPN site-to-site.pdf
VPN site-to-site.pdfgorguindiaye
 
#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...
#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...
#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...NetSecure Day
 
Petit potam slides-rtfm-ossir
Petit potam slides-rtfm-ossirPetit potam slides-rtfm-ossir
Petit potam slides-rtfm-ossirLionelTopotam
 

Similaire à BSidesQuebec2013-ssl (20)

Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)
 
Cours HTTPS pour UnPointZero
Cours HTTPS pour UnPointZeroCours HTTPS pour UnPointZero
Cours HTTPS pour UnPointZero
 
Projet Pki Etapes Clefs
Projet Pki   Etapes ClefsProjet Pki   Etapes Clefs
Projet Pki Etapes Clefs
 
securite.ppt
securite.pptsecurite.ppt
securite.ppt
 
Push to the web - Websocket et SignalR
Push to the web -  Websocket et SignalRPush to the web -  Websocket et SignalR
Push to the web - Websocket et SignalR
 
cours-gratuit.com--CoursInformatique-id3180.pdf
cours-gratuit.com--CoursInformatique-id3180.pdfcours-gratuit.com--CoursInformatique-id3180.pdf
cours-gratuit.com--CoursInformatique-id3180.pdf
 
Réseau MiNET
Réseau MiNETRéseau MiNET
Réseau MiNET
 
technologie web
technologie webtechnologie web
technologie web
 
Rapport sécurité
Rapport sécuritéRapport sécurité
Rapport sécurité
 
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
 
EIGRP - Authentification
EIGRP - Authentification EIGRP - Authentification
EIGRP - Authentification
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdf
 
MariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentationMariaDB Paris Workshop 2023 - DARVA presentation
MariaDB Paris Workshop 2023 - DARVA presentation
 
haking wep
haking wep haking wep
haking wep
 
Alphorm.com Formation CEHV9 IV- partie 2
Alphorm.com Formation CEHV9 IV- partie 2Alphorm.com Formation CEHV9 IV- partie 2
Alphorm.com Formation CEHV9 IV- partie 2
 
Présentation Microsoft Advanced Threat Analytics | Deep-Dive - MSCloud Summi...
Présentation Microsoft Advanced Threat Analytics  | Deep-Dive - MSCloud Summi...Présentation Microsoft Advanced Threat Analytics  | Deep-Dive - MSCloud Summi...
Présentation Microsoft Advanced Threat Analytics | Deep-Dive - MSCloud Summi...
 
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
ASFWS 2013 - Rump session - Un serveur d'authentification forte pour $35! par...
 
VPN site-to-site.pdf
VPN site-to-site.pdfVPN site-to-site.pdf
VPN site-to-site.pdf
 
#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...
#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...
#NSD16 - le suivi des bonnes pratiques tls dans l’écosystème https - Maxence ...
 
Petit potam slides-rtfm-ossir
Petit potam slides-rtfm-ossirPetit potam slides-rtfm-ossir
Petit potam slides-rtfm-ossir
 

Plus de BSidesQuebec2013

Simplified security code review - BSidesQuebec2013
Simplified security code review - BSidesQuebec2013Simplified security code review - BSidesQuebec2013
Simplified security code review - BSidesQuebec2013BSidesQuebec2013
 
Making pentesting sexy ossams - BSidesQuebec2013
Making pentesting sexy ossams - BSidesQuebec2013Making pentesting sexy ossams - BSidesQuebec2013
Making pentesting sexy ossams - BSidesQuebec2013BSidesQuebec2013
 
L'information personnelle numérique - BSidesQuebec2013
L'information personnelle numérique - BSidesQuebec2013L'information personnelle numérique - BSidesQuebec2013
L'information personnelle numérique - BSidesQuebec2013BSidesQuebec2013
 
Investigating at the speed of compromise - BSidesQuebec2013
Investigating at the speed of compromise - BSidesQuebec2013Investigating at the speed of compromise - BSidesQuebec2013
Investigating at the speed of compromise - BSidesQuebec2013BSidesQuebec2013
 
How to VERISize v2 - BSidesQuebec2013
How to VERISize v2 - BSidesQuebec2013How to VERISize v2 - BSidesQuebec2013
How to VERISize v2 - BSidesQuebec2013BSidesQuebec2013
 

Plus de BSidesQuebec2013 (6)

Simplified security code review - BSidesQuebec2013
Simplified security code review - BSidesQuebec2013Simplified security code review - BSidesQuebec2013
Simplified security code review - BSidesQuebec2013
 
Making pentesting sexy ossams - BSidesQuebec2013
Making pentesting sexy ossams - BSidesQuebec2013Making pentesting sexy ossams - BSidesQuebec2013
Making pentesting sexy ossams - BSidesQuebec2013
 
L'information personnelle numérique - BSidesQuebec2013
L'information personnelle numérique - BSidesQuebec2013L'information personnelle numérique - BSidesQuebec2013
L'information personnelle numérique - BSidesQuebec2013
 
Investigating at the speed of compromise - BSidesQuebec2013
Investigating at the speed of compromise - BSidesQuebec2013Investigating at the speed of compromise - BSidesQuebec2013
Investigating at the speed of compromise - BSidesQuebec2013
 
How to VERISize v2 - BSidesQuebec2013
How to VERISize v2 - BSidesQuebec2013How to VERISize v2 - BSidesQuebec2013
How to VERISize v2 - BSidesQuebec2013
 
BSidesQuebec2013_fred
BSidesQuebec2013_fredBSidesQuebec2013_fred
BSidesQuebec2013_fred
 

BSidesQuebec2013-ssl

  • 1. SSL sur Internet : état 2013 Thomas Pornin 1er juin 2013 © Groupe CGI inc. CONFIDENTIEL
  • 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
  • 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. 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
  • 16. Certificats X.509 : chaînes 16
  • 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