ssl.md

X.509 / TLS

OpenSSL

• Implémenté en C
• Boîte à outils de chiffrement
  • bibliothèques cryptographie générale
  • bibliothèques implémentant le protocole SSL
  • commande en ligne
• Supporte SSL 2.0, SSL 3.0 et TLS 1.0
• Actuellement TLS 1.2
• Distribué sous une licence de type Apache

GnuTLS

• Conforme aux spécifications de l'IETF
• Permet l'authentification via les certificats
  • X509
  • PGP
• A la différence d'OpenSSL, GnuTLS est compatible avec les licences GPL

X.509

• Norme Pour

  • certificats à clé publique
  • listes de révocation de certificats
  • attributs de certificat
  • algorithme de validation du chemin de certification

• UIT (agence de l'ONU le développement spécialisé dans les TIC )

  • v1: 1988, v2: 1993, v3: 1996

X.509

• Système hiérarchique d'autorités de certification
  • certification authority - CA
    • une CA attribue un certificat liant
      • une clé publique
      • un nom distinctif
        • Distinguished Name - DN

X.509 DN

• C: Country
• L: Locality
• ST: State
• O: Organisation
• SO: Organizational Unit
• CN: Common Name
• Street: Adress
• E: Mail

Anatomie

• Version de la norme
• Serial
• Algorithme de signature du certificat
• Issuer le signataire (DN de la CA)
• Validty début fin de validité
• Subject name DN identifié par le certificat
• Subject Public Key
• Extensions (ajouté en v3)
  • paires clé / valeur

Le tout signé par la CA

Extensions

Informations ou contraintes d'utilisation

• Key Usage
• Subject Key Identifier
• keyEncipherment Algorithme de signature du certificat
• rfc822Name email address
• dNSName DNS name for a machine
• uniformResourceIdentifier URL
• iPAddress

Générer une clé RSA

$ openssl genrsa -out ca.key 4096

• 4096 représente la taille de la clé
• ca.key contient la clé privée ET la clé publique

$ openssl rsa -in ca.key -pubout

• Permet d'extraire la partie publique uniquement

Générer un certificat

$ openssl req -new -x509 -days 1826 \
            -key ca.key -out ca.crt \
            -subj '/CN=m4z3.me'

$ cat ca.crt
-----BEGIN CERTIFICATE-----
MIIC/zCCAeegAwIBAgIJAM4FANszQweWMA0GCSqGSIb3DQEBCwUAMBYxFDASBgNV
BAMMC2V4YW1wbGUuY29tMB4XDTE3MTAzMTExMzEzNFoXDTE3MTEzMDExMzEzNFow

différences entre certificats

Certificat auto-signé

• Issuer et Subject identiques
• Tout le monde peut en fabriquer
• Rejeté par défaut par les navigateurs

Faire parler un certificat

local

$ openssl x509 -text -noout -in ca.crt

distant

$ openssl s_client -connect isima.fr:443 -showcerts -servername isima.fr

• Using OpenSSL’s s_client command with web servers using Server Name Indication (SNI)

usage du certificat

$ openssl x509 -purpose -in ca.crt  -inform PEM

Faire parler un certificat

• Avec son navigateur en cliquant sur le cadenas

Faire parler un certificat

Autorité de certificaiton (CA)

• Tiers de confiance
• Recueille les demandes de certifications
  • Vérifie la validité de la demande
    • Vérifie l'identité
      • Preuve par contrôle des domaines
• Signe les certificats
• Gère les révocations

Autorité de certificaiton (CA)

• CA de confiance
  • importées par défaut dans le navigateur
    • Tout supprimer?
  • Etre importée dans les navigateurs
    • payer (le navigateur)

Known good signers

Root CA

Certificat racine

• clés publiques non signées, ou auto-signées
  • le sommet de la pyramide de confiance
  • Un certificat est rarement signé par une CA racine
  • La CA racine créée plusieurs CA intermédiaires
    • sous scellés / déconnectés / sortis (autre CA)
    • auto signé

Chain of trust

Chaînes de certification

• Les CA intermédiaires signent
  • les certificats des clients
  • d'autres CA intermédiaires
    • il faut alors fournir la chaîne de certification
      • au cas où l'intermédiaire ne soit pas dans le navigateur

CA connues

• digicert
  • verisign
• Comodo
• Gratuites
  • StartSSL free
  • CAcert (not known good signers)
  • Let's Encrypt fondé par l'EFF et Mozilla

CA & Firefox

CA & Chrome

Différentes causes

• Certificat différent du nom de domaine
  • wildcard
    • https://amendes.gouv.fr
• Certificats expirés
• Autorités de certification non importée
• ...

Certificate Sign Request

(CSR)

$ openssl req -new -newkey rsa:2048 -sha256 \
            -nodes -out user.csr -keyout user.key \
            -subj '/CN=example.com'

• Générer un requête de certification
• Un CSR est auto-signé (pour vérifier l'intégrité)

$ openssl req -in user.csr -text -noout

• Lire le CSR

$ openssl req -text -noout -verify -in user.csr

• Vérifier le CSR

Création d'un certificat à partir d'un CSR

$ openssl x509 -req -days 365 \
       -CA ca.crt -CAkey ca.key \
       -CAcreateserial -CAserial serial \
       -in user.csr -out user.crt \

• Génèrer un certificat à partir d'un CSR
  • la CA vérifie qu'elle gère le domaine
  • la CA ajoute quelques informations
  • la CA signe avec sa clé privée
    • la CA protège sa clé privée

note:

• https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs

Vérification de la signature

$ openssl verify -CAfile ca.crt user.crt
user.crt: OK

$ openssl x509 -text -noout -in user.crt
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            f0:61:f4:c1:96:86:21:07
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=m4z3.me
        Validity
            Not Before: Jan 18 17:27:54 2018 GMT
            Not After : Jan 18 17:27:54 2019 GMT
        Subject: CN=example.com

note:

• https://stackoverflow.com/questions/25482199/verify-a-certificate-chain-using-openssl-verify

Certificate Revocation List (CRL)

Révocation de certificats

• Contient une liste de certificats valides à révoquer
  • utile en cas de compromission / décommissionnement
    • informer la CA
    • la CA ajoute le certificat à sa liste de certificats révoqués
    • cette liste est signée par la CA
• Souvent la clé qui signe les certificats signe les CRL
• Quand que le navigateur interroge-t-il les CRL ?

Certificate Revocation List (CRL)

• Serial
• Algorithme de signature de la CRL
• Issuer le signataire (DN de la CA)
• **Update date **
• Next Update date
• CRL
  • revoked 1 ...
  • revoked 1
• Extensions
  • paires clé / valeur

note:

• next update parce que CRL delta

Certificate Revocation List (CRL) extensions

• reasonCode 0. Unspecified
  1. KeyCompromise
  2. CACompromise
  3. AffiliationChanged ...

Online Certificate Status Protocol (OCSP)

Protocole d’interrogation de validité pour un certificat

• peu déployé
  • si l'OCSP n'est pas disponible pour le certificat firefox accepte le certificat
    • s'il est valide

SSL / TLS

• Crée un canal de communication authentifié, protégé en confidentialité et en intégrité
• Utilise des certificats X.509
  • délivrés par des CA
• Utilise un système de chiffrement asymétrique
  • pour échanger une clé pour le chiffrement symétrique
• Protocole initialement pensé pour sécurisé HTTP
  • étendu à d'autres services (SMTP, LDAP, VPN, ...)

TLS dans le modèle TCP/IP

• Couche intermédiaire car indépendante du protocole utilisé

Versions SSL

Secure Socket Layer

• 1.0 par Netscape en 1994, pas de public release
• 2.0 par Netscape en Février 1995, The SSL Protocol Version 2.0
• 3.0 par Netscape en Novembre 1996, The SSL Protocol Version 3.0

Versions TLS

Transport Layer Security

• 1.0 released en janvier 1999, RFC 2246
  • TLS 1.0 = SSL 3.1 IETF
• 1.1 released en Avril 2006, RFC 4346
• 1.2 released en Août 2008, RFC 5246

Connexion SSL/TLS (1)

Le serveur

• Envoie son certificat au client

Connexion SSL/TLS (2)

Le client

• Reçoit un certificat
• Vérifie sa validité (domaine, date, émetteur, révocation?)
• Génère une clé de chiffrement symétrique (secret partagé)
• Chiffre le secret partagé avec la clé publique du serveur
• Envoie le secret partagé chiffré au serveur (ClientKeyExchange)

Connexion SSL/TLS (3)

Le serveur

• Reçoit le secret partagé chiffré généré par le client
• Déchiffre le secret partagé avec sa clé privée

#### La suite de la communication est chiffrée symétriquement

Connexion SSL/TLS

• Le client a authentifié le serveur

  • mais le serveur n’a aucune information sur le client
    • possibilité d'avoir un certificat côté client

• Les paramètres de chiffrements

  • sont négociés et « jetables »

4 sous-protocoles

* **Handshake** * authentification mutuelle du client et serveur * négociation des algorithmes de chiffrement et de hachage * échange de la clé symétrique assurant le chiffrement * **Change Cipher Spec** * validation de la négociation préalable * vérifie que deux partis se sont bien accordés quant à la clé maîtresse et aux algorithmes à employer * **Alert** * protocole informatif de l'état de la liaison * **Record** * protocole d'acheminement des données de la communication * ce protocole peut encapsuler tout protocole * le rend ainsi sécurisé

Handshake

Handshake - ClientHello

• ClientHello
  • propose les suites cryptographiques qu'il sait gérer
    • pour
      • établir les éléments secrets de session
      • authentifier les parties
      • chiffrer les données applicatives
      • protéger les données applicatives en intégrité

$ openssl ciphers -v

• valeur aléatoire ClientRandom pour la dérivation des clés

Handshake - ServerHello

• Aucune des propositions du client n'est jugée acceptable
  • message de type Alert
    • fin de la connexion
• ServerHello fait état du choix de la suite cryptographique parmis celles proposées
  • première suite cryptographique préférée et proposée par le client
    • comportement IIS par défaut
    • directive SSLHonorCipherOrder pour forcer ce comportement pour apache
      • première suite proposée par le client et supportée par défaut
• Certificate contient le Certificat du serveur
• ServerHelloDone attente de réponse du client
• valeur aléatoire ServerRandom pour la dérivation des clés
  • Les données échangées par la suite entre le client et le serveur sont chiffrées et authentifiées à l'aide de clés dérivées
• Deuxième phase: authentificaiton du client
  • optionnelle

Note:

• Why does the SSL/TLS handshake have a client and server random?
  • master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
    • Why not just use the pre-master?
      • This would mean that the entire key generation routine was based on client generated values
        • If a Man-In-The-Middle attacker replayed the handshake, the same pre-master secret would be sent and then used for the connection.
        • Having the server generate a random value (ServerHello.random) will mean that the MAC (message authentication code) secret is different if the ClientHello.random is repeated, and therefore the MAC and encryption keys will be different, preventing any replay attack.

Handshake - cypher suite TLS_RSA_WITH_RC4_128_MD5

• RSA

  • authentification du serveur
  • établissement des secrets de session
    • quand le client a reçu le certificat du serveur
      • génération d'une pre-master secret : secret de session
        • chiffrer en utilisant la clé publique du certificat
          • ClientKeyExchange contient l'aléa chiffré que seul le serveur pourra déchiffrer
            • la communiation est chiffré de manière symétrique

• RC4_128 algorithme de chiffrement RC4 avec clé de 128 bits

  • pour chiffrer le canal de communication

• MD5

  • protection de l'intégrité du canal de communication via HMAC MD5

Note:

• Why does the SSL/TLS handshake have a client and server random?
  • master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
    • Why not just use the pre-master?
      • This would mean that the entire key generation routine was based on client generated values
        • If a Man-In-The-Middle attacker replayed the handshake, the same pre-master secret would be sent and then used for the connection.
          • Having the server generate a random value (ServerHello.random) will mean that the MAC (message authentication code) secret is different if the ClientHello.random is repeated, and therefore the MAC and encryption keys will be different, preventing any replay attack.

Handshake - Finished

• Le client vérifie la chaîne de certification du certificat

  • chaîne de certification invalide
    • fin de la connexion
  • chaîne de certification valide
    • le client renvoie le pre-master sercet chiffré dans ClientKeyExchange
      • le pre-master secret, le ClientRandom et le ServerRandom sont connus du client et du serveur
        • ces éléments partagés sont alors dérivés pour générer les clés symétriques utilisés par
          • RC4 pour la confidentialité du trafic
          • HMAC MD5 pour l'intégrité du trafic

• les messages ChangeCiperSpec sont échangés pour indiquer l'activation des algorithmes et des clés

• les messages finished

  • premiers messages chiffrés
  • contiennent un condensat de tous les messages échangés
    • intégrité de la négociation

• déroulement des échanges ssl en détail

Suite cryptographique

• https://fr.wikipedia.org/wiki/Suite_cryptographique

## Perfect Forward Secrecy (PFS)

• En français : confidentialité persistante Si la clé privée du serveur est compromise, qu’en est-il des transactions passées ? La PFS introduit un ServerKeyExchange

• obligatoire pour la certification A+ (à vérifieir et creuser les catégories de certification).

• on voit passer que c'est du jaune

• mais ce ne donne pas d'avanatage

  • la couleur finale est impossible à trouver même en sachant qu'elle utilise du jaune

  • problème np complet (voir avec Pascal)

Vulnérabilité TLS_RSA_WITH_RC4_128_MD5

• si la clé privée est récupérée
  • le pre master secret est récupérable aussi
    • on peut obtenir les clés de session
      • toutes les communications sont alors déchiffrables
        • passées
        • futures

Diffie-Hellman éphémère

Diffie-Hellman exchange

Diffie-Hellman éphémère

• DHE ou ECDHE
  • échange de clé Diffie-Hellman
    • éléments secrets éphémères
    • ne transitent pas en vérité
      • la connaissance de la clé privée n'est d'aucun intérêt
        • PFS (Perfect Forward Secrecy): la connaissance de la clé privée n'apporte pas d'avantage pour déchiffrer
  • Authentification du serveur explicite
    • ServerKeyExchange
      • signature RSA
        • paramètres Diffie-Hellman
        • aléas (ClientRandom ou ServerRandom)

Handshake - SSLv2

• Il n'y a pas de message finished
  • finished protège l'échange en intégrité
  • corrigé à partir de SSLv3

Handshake - SSLv2 - MIM

Note:

• attaque man in the middle permet de faire baisser la sécurité des méthodes supportés par le client ou le serveur
  • pas de déchiffrement à la volée
  • mais possible avec un peu de temps
• SSLv2 est aussi vulnérable parce que
  • utilise MD5 dasn toutes ses cyphersuites
  • utilise la même clé pour protéger le fulx en intégrité et en confidentialité
  • pas de mécanisme de signalement de fin de connexion
    • attaques par "troncature" du flux
• SSLv2 ne doit pas être utilisé

Renégociation sécurisée

• en cas de

  • rafraichaissement des clés
  • en cas d'authentification du client
    • le serveur initie une renégociation
      • demande le certificat client (pour un accès à du contenu protéger)

• à l'intiative du client ou du serveur

Renégociation - TLS

Renégociation - TLS - MIM

Vulnérabilités multiples

• [mai 2015] - Weak Diffie-Hellman and the Logjam Attack

  • permet de forcé les connexions TLS à 512-bit export-grade cryptography
  • Freack Attack réminiscence

• [octobre 2014] - Poddle

  • POODLE test

• [mars 2014] - Heartbleed

  • lecture de la mémoire du serveur via un heartbeat

• OpenSSL vulnerabilities

• GnuTLS security

Note:

• La négociation de la cypher suite browser / server
  • Le forçage du choix mininmum est à considérer

en cas de compromission

• la clé privée est compromise
• elle permet donc déchiffrer ce qui a été chiffré avec la clé publique
• le secret de connexion est donc retrouvable à tous les coups

Chiffrer pour plusieurs destinataires

On ne veut pas envoyer n messages distincts, ni un message chiffré avec n clés différentes

1. On chiffre le message avec un algorithme symétrique et une clé aléatoire
2. On chiffre cette clé n fois pour les n destinataires
3. On envoie le message chiffré symétriquement et la clé partagée chiffrée pour chaque destinataire

Chaque destinataire peut déchiffrer la clé partagée avec sa clé privée et déchiffrer le message

Certificats clients

• Un client peut présenter un certificat au serveur
• Le serveur vérifie si le certificat est signé par une CA de confiance
• Le serveur peut utiliser ces informations pour authentifier l’utilisateur
• Le certificat peut être stocké dans un périphérique (e.g. Yubikey), une carte à puce (e.g. CPS), ... vérifier avec le CNRS

Certification Authority Authorization (CAA)

• Une CA peut vérifier si elle est autorisée à émettre un certificat pour un domaine via le DNS (enregistrement CAA)

• Devenu obligatoire le 8 septembre 2017

• Le 9 septembre 2017, Comodo s’est fait pincer pour ne pas le respecter : Comodo Caught Breaking New CAA Standard One Day After It Went Into Effect (à vérifier masi c'est le cas ou un domaine est déjà enregistré chez un CA let's encrypt par exmple (il a l'enregsitrement) mais comodo n'en a pas tenu compte)

• Validation par les CA

DNS-Based Authentication of Named Entities (DANE)

• Publication du certificat dans un enregistrement TLSA du DNS, protégé par DNSSEC

• Validation par les clients

On peut se passer des CA

HTTPS

• HTTP + SSL/TLS = HTTPS assure

  • Confidentialité
    • Session Hijacking
      • les dangers du wifi
        • firesheep
  • Intégrité
  • Authentification (via les certificats)

• Open SSL

  • mod_ssl

• GnuTLS

  • mod_gnutls

Que "chiffre" https

• On ne voit pas l'url dans le traffic
  • mais on voit l'hôte
• Anonimisation complète via un proxy https ou VPN
  • obfusquent complètement le traffic

Note:

• Attention les proxy
  • surtout anonymes sont de faux amis
  • ce n'est pas un vpn
  • pose des problèmes de certificats
    • proxy https = MITM

Autres vulnérabilités

• Public Key Infrastructure (PKI)

  • certificats
    • rarement testés par le navigateur
      • Online Certificate Status Protocol (OCSP)
        • abandonner côté client en cas de certififcat révoqué
        • maintenir un cache de réponse valide côté serveur
      • Approche par log publique de création révocation
      • Google's Certificate Transparency project
    • peut on faire confiance aux certificats valides?
      • Certificate authorities issue SSL certificates to fraudsters
  • peut on faire confiance à toutes les PKI?
    • celles qui délivrent des certificats systématiquement autorité de certifications

• cypher suite

  • New RC4 Encryption Attacks Reduces Plaintext Recovery Time
  • A freestart collision example for SHA-1
  • MD5 vulnerable to collision attacks

Note:

• Repose sur la confiance dans les autorités de conifance
  • Honnêteté et sécurité des autorités de certification
  • signé par une autorité de confiance, chaine valide
    • on calcule le hash avec la clé publique de l'autorité et on la compare au hash du certificat

Quelques outils

• Obtenir un certificat SSL valide
  • letsencrypt.org entièrement gratuit (à renouveler tous les 90 jours)
  • startssl.com 1 domaine + 1 sous domaine gratuits
  • gandi.net 1 domaine ou sous domaine gratuit par non de domaine acheté chez gandi
• Tester un certificat SSL
  • https://ssldecoder.org/
  • https://certificatemonitor.org/
• Tester une configuration SSL
  • Qualys
  • Comodo ssl analyzer
  • OpenSSL Decoder avec son post de blog
• Tester son navigateur
  • SSL Cipher Suite Details of Your Browser
  • How's my SSL?
  • Toggle Cipher Suites, Toggle Cipher Suites
  • Calomel SSL validator
• Comprendre son navigateur
  • Chrome, Firefox et recherches Google : passage en force du HTTPS

Note:

• aspect arbitraire de la notation notamment qualys
  • méfiance quand il y aquelque chose à vendre
• SSL en fait TLS on est d'accord

Se protéger

• Seules les implémentations conformes à TLSv1 et supérieures doivent être employées
• Les cyphersuites offrant la PFS doivent être favorisées
• Anssi - SSL/TLS: état des lieux et recommandations
• Apache tips
  • Chiffrement fort SSL/TLS : Mode d'emploi
  • Hardening Your Web Server’s SSL Ciphers
  • ssllabs.com's own Apache SSL Config Directives
  • Apache web server SSL best practices
• Nginx tips
  • HTTPS on Nginx: From Zero to A+ (Part 1)
  • HTTPS on Nginx: From Zero to A+ (Part 2)

Se protéger

• Multi server tips
  • https://cipherli.st/ pour une conf sécurisée
    • Modifier tous les vhosts pour nginx!!
  • fixer le weak Diffie-Hellmani (aka logjam Attack)

 openssl dhparam -out dhparams.pem 2048 

• suivre les recommandations de l'ANSSI

dans tous les cas

bien regarder la date ...

car valable jusqu'à la prochaine faille!!!

Note:

• Désactiver tout services non sécurisés
  • préférer sftp à ftp, ssh à telnet ou rlogin ...

http://www.cypherpunks.to/~peter/T2a_X509_Certs.pdf