SSL/TLS Présentation en Français.
•Télécharger en tant que ODP, PDF•
3 j'aime•7,136 vues
![Les acteurs... ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Dernier
Dernier (20)
SSL/TLS Présentation en Français.
- 1. Autour de SSL/TLS La sécurité par le petit s de https
- 3. Pourquoi TCP/IP seul n'est pas suffisant ?
- 4. Mon identifiant: 6719719 Mon code : 6789 Mon identifiant: 6719719 Mon code : 6789 Mon identifiant: 6719719 Mon code : 6789 Mon identifiant: 6719719 Mon code : 6789 Mon identifiant: 6719719 Mon code : 6789 Pourquoi HTTP seul n'est pas suffisant ? HTTP TCP/IP
- 9. Confidentialité / Chiffrement Chiffre Déchiffre Encipher/Encrypt Decipher/Decrypt PlainText CipherText En Clair Chiffré En Clair PlainText
- 10. Mon identifiant: 6719719 Mon code : 6789 Mon identifiant: 6719719 Mon code : 6789 TCP/IP HTTPS TLS
- 13. TLS : Le protocole n'est pas secret
- 14. C'est très simple... TLS - Réutilsation -
- 15. Handshake ClientHello ClientKeyExchange ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone ChangeCipherSpec Finished
- 16. Comment savoir si cela se passe vraiment ainsi ?
- 21. Détail de paquet Ipv6
- 22. ClientHello ClientHello CA CA CA NULL
- 23. ClientHello CA CA CA
- 26. CipherSuite
- 28. ServerHello ServerHello ClientHello CA CA CA NULL
- 30. Certificate Certificate CA CA CA CA ClientHello ServerHello
- 31. Les Certificats X509 CA
- 32. -----BEGIN CERTIFICATE----- MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L 05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0 ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5 u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6 z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw== -----END CERTIFICATE----- gmail.cert Fichier certificat au format PEM PEM Base64 Sauver un fichier certificat
- 35. openssl x509 -text -in gmail.cert Data: Version: 3 (0x2) Serial Number: 2f:df:bc:f6:ae:91:52:6d:0f:9a:a3:df:40:34:3e:9a Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA Validity Not Before: Dec 18 00:00:00 2009 GMT Not After : Dec 18 23:59:59 2011 GMT Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=www.google.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 CRL Distribution Points: URI: http://crl.thawte.com/ThawteSGCCA.crl X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto Authority Information Access: OCSP - URI:http://ocsp.thawte.com CA Issuers - URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt Signature Algorithm: sha1WithRSAEncryption 9f:...07:5f Certificat Texte
- 36. Autorité de Certification wget http://www.thawte.com/repository/Thawte_SGC_CA.crt openssl x509 -inform der -in Thawte_SGC_CA.crt -out Thawte_SGC_CA.crt.pem openssl verify -CAfile Thawte_SGC_CA.crt.pem -purpose any gmail.cert gmail.cert: OK CA CA
- 37. Chaine de confiance *.google-analytics.com Google Internet Authority Equifax Secure Certificate Authority Racine CA intermédiaire CA:TRUE CA:TRUE Serveur Eq Eq GIA Eq. g-a GIA
- 39. CA CA CA @dns
- 40. Echange de clés ... Pas si simple
- 43. One-Way function simple Extrêmement difficile / long Irreversible
- 44. Openssl sha1 -c <who.jpeg Openssl sha1 -c <whodot.jpeg fa:45:5c:49:ac:27:4f:b8:ee:d1:8d:68:b5:4e:d9:94:34:8f:a0:4c 12:d1:ce:26:5e:50:d7:e9:e5:2d:72:95:b9:0b:ac:25:42:93:ee:9c Dispersif
- 46. signature Chiffrement, échange de clefs Secret Utilisations Texte à signer Texte à signer Secret
- 47. openssl genrsa Generating RSA private key, 512 bit long modulus e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIIBOwIBAAJBAMBW/JaWqIoqAzouvlsqL4mlt4rc4JfOMfvs+8wUG0CljhFLIRzC 9AyWnEN2dKfNvcO23KRkC/pKOl1ZERDnP80CAwEAAQJBAL5WltoTN7CayNzQGzKu eaK26v6xfFTeCZrsN3YKw7lhI59625lmordLyBVPzfzx0iNWcrTfgm89cJLxbxiG KAECIQDw3K4OW/mDOa4nR3ia8CQ5jcTBPyLzrV7uRvVN/CEiAQIhAMxtnTkSdnoC aVNqmjRX/jZu4v4lH0cIfGE3NhB6tQXNAiAsvfGfPTqWQ8q0BTTEI0O3ZTxdYWsO tO/jd07uE53cAQIhAI+KNAg754a6JLyWsJoqYuxTpf0vkaut0K/uNX8SugLNAiBs ef1pKItH+8rB/FgY9Bz7om344BFVFyOX/vjCl/NQLg== -----END RSA PRIVATE KEY----- openssl rsa -inform pem -text -in rsa.key Private-Key: (512 bit) modulus: 00:de:5c:69:38:ff:68:9d:44:57:8e:28:f9:b6:b9: 6c:89:5f:f4:47:fb:02:c2:7d:f0:49:c0:47:bb:13: 5a:1a:e9:a1:fc:e0:ce:11:e9:b7:49:29:0f:69:33: 36:96:78:c5:d5:b7:9d:82:da:48:c8:90:c0:2a:6f: c1:21:f5:04:99 publicExponent: 65537 (0x10001) privateExponent: 5e:85:05:ad:56:d4:4f:55:87:aa:44:3c:b1:b1:6c: 33:90:f8:33:c8:bd:49:93:63:1a:d6:83:27:40:78: a2:cb:36:21:6a:74:1a:d7:d6:e7:0a:23:5f:fb:29: 24:32:bd:d8:fb:d1:5f:6a:af:24:be:53:c1:4c:5a: 9b:7a:39:21 prime1: 00:fa:2d:47:3e:86:32:a3:e5:24:0d:ec:3f:bb:e4: 3b:91:7c:40:57:63:6d:96:6b:3c:98:33:27:b7:49: 70:04:25 prime2: 00:e3:89:63:12:56:2d:87:bd:54:e0:75:c7:44:85: 65:45:26:7c:61:46:84:1b:38:b9:08:8f:4f:93:1e: 97:3a:65 exponent1: 7f:f6:02:d7:cf:2a:3d:bc:69:49:99:ca:2b:9f:9c: 7c:58:92:4c:60:75:e0:17:2f:a2:25:a0:2d:d6:a9: 2d:e5 exponent2: 00:d4:be:34:1f:84:eb:f5:2a:95:1d:79:81:e3:13: 46:68:ad:5f:46:24:84:88:5f:34:c2:48:1c:82:d5: eb:57:f1 coefficient: 00:a4:f0:22:13:4a:37:d6:c1:16:d2:8c:36:89:8b: 6e:76:df:cc:78:4a:4d:fd:c1:e6:9f:4b:72:f3:95: 45:f8:33 openssl rsa -inform pem -in rsa.key -pubout writing RSA key -----BEGIN PUBLIC KEY----- MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAN5caTj/aJ1EV44o+ba5bIlf9Ef7AsJ9 8EnAR7sTWhrpofzgzhHpt0kpD2kzNpZ4xdW3nYLaSMiQwCpvwSH1BJkCAwEAAQ== -----END PUBLIC KEY----- openssl rsa -text -inform pem -in rsa.pub -pubin Modulus (512 bit): 00:de:5c:69:38:ff:68:9d:44:57:8e:28:f9:b6:b9: 6c:89:5f:f4:47:fb:02:c2:7d:f0:49:c0:47:bb:13: 5a:1a:e9:a1:fc:e0:ce:11:e9:b7:49:29:0f:69:33: 36:96:78:c5:d5:b7:9d:82:da:48:c8:90:c0:2a:6f: c1:21:f5:04:99 Exponent : 65537 (0x10001) e,n d,n ( p,q,e ) RSA
- 50. Handshake CA ClientKeyExchange ServerHelloDone Certificate ClientHello ServerHello CA
- 52. Pre master secret CA ClientKeyExchange ClientKeyExchange CA @dns NULL
- 53. Pre master secret ClientKeyExchange CA CA @dns
- 54. Pre-master Secret Master Secret master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; (*) différent pour SSLv3 qui n'utilise pas un HMAC
- 55. Master Secret key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); Key Block
- 57. P_hash graine graine graine graine (...) (...) A(0) A(1) A(2) A(1) A(2) A(3) A(3) secret Hash : MD5, SHA1, SHA256... HMAC (hash)
- 58. HMAC http://tools.ietf.org/html/rfc2104 texte H(K XOR opad, H(K XOR ipad, text)) Clé K Hash : MD5, SHA1, SHA256... 0x36.. 0x5c..
- 60. Handshake ClientHello ClientKeyExchange ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone
- 62. = ? : @dns
- 63. Handshake ClientHello ClientKeyExchange ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone ChangeCipherSpec Finished
- 64. La réalité trahit la théorie ?
- 65. Session Ticket Extension ClientHello ClientKeyExchange ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone ChangeCipherSpec Finished NewSessionTicket
- 66. Durée de vie ticket NewSessionTicket Ticket (opaque) NewSessionTicket
- 68. = ? : Finished Finished @dns
- 70. Hanshake Finished ! ClientHello ClientKeyExchange ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone ChangeCipherSpec Finished NewSessionTicket Ticket (opaque)
- 73. Flot ou Bloc
- 74. Electronic Codebook ECB AES 128 ECB AES 128 ECB Openssl aes-128-ecb -e -in who.bmp -out whoaes.bmp -k password
- 75. Cipher Block Chaining CBC AES 128 CBC Openssl aes-128-cbc -e -in who.bmp -out whoaes.bmp -k password
- 76. Session struct { ProtocolVersion protocol_version; CipherSuite cipher_suite; CompressionMethod compression_method; opaque master_secret[48]; ClientIdentity client_identity; uint32 timestamp; } StatePlaintext; enum { anonymous(0), certificate_based(1), psk(2) } ClientAuthenticationType; struct { ClientAuthenticationType client_authentication_type; select (ClientAuthenticationType) { case anonymous: struct {}; case certificate_based: ASN.1Cert certificate_list<0..2^24-1>; case psk: opaque psk_identity<0..2^16-1>; /* from [RFC4279] */ }; } ClientIdentity; connection connection Session 1 Session 2 Réutilisation Renégotiation Reprise connection
- 77. Réutilisation ou reprise de session ClientHello ChangeCipherSpec Finished ServerHello ChangeCipherSpec Finished
- 79. Identification Client ClientHello ClientKeyExchange ChangeCipherSpec Finished ServerHello Certificate ServerHelloDone ChangeCipherSpec Finished CertificateRequest Certificate CertificateVerify
- 87. A chaque couche ses protocoles SSH TLS IPSec WEP WPA 802.1x Cryptographie Quantique PGP/GnuPG S/Mime Application openssl TCP – UDP -SCTP Session Transport Réseau Liaison Physique Présentation Application
Notes de l'éditeur
- La sécurité informatique est une affaire de confiance et de mathématiques.
- Dans cette présentation on utilisera Alice pour identifier le client et Bob pour le serveur. Sous le 's' de https se cache le protocole SSL/TLS Incontournable pour les sites marchands en ligne. ( petite clé du navigateur ) Raison historique de mise en place de SSL dans les navigateurs ( Netscape )
- Internet n'appartient à personne, aucune entité ni même gouvernement ne peut garantir que les paquets ne sont pas modifiés ni même qu'ils arrivent à destination Le contenu des données échangées non cryptées est lisible depuis toute capture de trafic Le trafic peut transiter n'importe où A l'ère d'HADOPI où l'on identifie les usagers par leur adresse IP, il y a un hic.
- HTTP fait circuler le contenu des pages et des requêtes en clair : il est très facile de reconstituer un contenu web en lisant les trames HTTP repose sur TCP directement et TCP sur IP. Aucun de ces protocoles ne garantie la confidentialité et l'authenticité des différentes parties.
- la communication s'effectue avec le bon intervenant. Identification / Authentification C'est bien google qui est derrière gmail.com, sinon vous venez de donner votre mot de passe à un autre site. la confidentialité est respectée Le mail que vous venez d'envoyer contenait le montant de votre salaire ( exhorbitant ), aujourd'hui il est en première page d'un magazine. Le contenu des informations n'est pas altéré, l'intégrité est respectée. La fin du contrat qui contenait une clause de non concurrence a purement été supprimée
- Vérifiez que le site est sécurisé... AVANT d'effectuer des actes qui nécessitent la confidentialité : AVANT de saisir vos identifiant AVANT de saisir votre numéro de carte bleue AVANT de fournir votre adresse courriel AVANT d'envoyer un mail contenant des informations personnelles
- Le chiffrement permet de conserver un contenu secret même si son contenu chiffré est visible publiquement. Le chiffrement assure la confidentialité. Il existe deux types de chiffrements, symétrique à clé secrète ou asymétrique à clé publique. En bon français il faut utiliser chiffrer et non crypter ( parce que décrypter c'est déchiffrer sans connaître la clé ) Il ne faut en aucun cas utiliser le terme encodage pour le chiffrement puisque l'encodage n'utilise pas de secret ( ex encodage ASCII/UTF-8 ).
- La surcouche TLS est fournie par des librairies partagées du système ou bien directement par le programme lui même. La façon dont TLS est utilisé est entièrement à la responsabilité des programmes ( Navigateur d'un côté, Serveur de l'autre ).
- Si https est si bien que ce que tu es en train de me vendre, dudulle, alors pourquoi tous les serveurs du monde ne sont pas en https ? Les certificats : une rente qui a permis à M. Shuttleworth de se payer un voyage à 20 Milliions de dollars dans l'espace...
- blinder la porte de devant en laissant ouverte la porte de derrière Avoir un coffre fort dernier cri et laisser la clé dessus Avoir un mot de passe extra fort mais laisser un papier sous le clavier Sur un site en https Cliquer sur le bouton qui permet de continuer la navigation « Acceptez vous le certificat... »
- Sécurité par l'obscurité Une tentation est de fournir de la sécurité en cachant la façon dont la sécurité est fournie C'est MAL : Cf Bruce Schneier L'inverse et de fournir en détail la façon dont la sécurité est fournie et assurée Les protocoles de sécurités disposant de normes accessibles et d'implémentations libres doivent être intrinsèquement surs. Cependant il n'est pas possible de fournir de la sécurité sans qu'une partie reste secrète : la clé.
- TLS fonctionne en deux phases : Le Handshake / « poignée de main »: vérification des intervenants et échange d'un secret partagé. Le trafic : chiffrer les données en se basant sur le secret partagé. Plus tard une nouvelle connection peut réutiliser le secret partagé en utilisant un handshake écourté.
- Comme on le voit le handshake nécessite l'échange de plusieurs messages. Le détail suit...
- Analyser le trafic : Capturer le trafic durant l'ouverture du navigateur et le chargement de la page de login Afficher le trafic d'une manière compréhensible Demander à un professionnel de me convaincre Consulter un oracle La sécurité repose sur la confiance : Confiance au logiciel Confiance au matériel Confiance aux hébergeurs Confiance aux « Autorités compétentes » Là où il n'y pas de confiance, alors il faut utiliser des protocoles qui assurent cette confiance
- Pourquoi ne pas lancer wireshark en tant que root et utiliser ses capacités de capture ? C'est beaucoup moins risqué de ne lancer que tcpdump en tant que root. Tcpdump -i eth0 -s0 -w eth0capture.pcap Il faut impérativement capturer l'intégralité du traffic ( -s0 tout le contenu de la trame ethernet ). Par défaut la taille est réduite Wireshark eth0capture.pcap
- Dans les préférences il est possible de rajouter au protocole SSL la définition des clés privés utilisées afin de déchiffrer le traffic. Pourquoi n'a t'on pas déchiffré le trafic avec google ? Parce que l'on n' a (heureusement) pas la clé privé du serveur de mail de google. On ne peut déchiffrer du trafic que des serveurs dont on a la clé, et encore ( Diffie Helman & Perfect Forward Secrecy ).
- On peut voir successivement les requètes dns pour obtenir l'adresse Ip(v6) de google le 3-ways handshake TCP ( SYN,SYN-ACK-ACK) poutr se connecter au port https de gmail Et finalement... une requète de handshake TLS : ClientHello qui circule dans la connection TCP établie précedemment.
- Indique les capacités du client / navigateur Contenu ProtocolVersion TLS v1 (0301) ... Random SessionID : length = 0 => aucune session. CipherSuite(s) 34 possiblités CompressionMethod : method null aucune compression.
- Alice / le navigateur créé une valeur aléatoire avec une date et l'envoi avec la liste de ces ciphersuites. Une ciphersuite est une liste de choix d'algorithmes de cryptographie. Nous verrons bientôt en détail ce qu'est une ciphersuite. Remarque : Le serveur possède une paire de clés asymétriques et un certificat contenant sa clé publique et prouvant son identité. Le client possède au moins un certificat de CA qui est l'autorité de certification à laquelle il accorde sa confiance.
- Le client et le serveur conservent les informations crées et échangés. Une fois le client hello reçu c'est au serveur de choisir la ciphersuite parmi ce qu'il supporte et ce qu'il considère le plus approprié dans les propositions du client. Si aucune des ciphersuites ne lui plait la communication s'arrête ici sur erreur. De façon générale le serveur ( par exemple un server apache ou tomcat ) choisit la ciphersuite la plus sûre.
- Générer un nombre vraiment aléatoire n'est pas une tâche aisée pour un ordinateur qui par définition fonctionne de façon totalement déterministe. Souvent un système conserve des événements externes qui lui permettent de construire un minimum de hasard, puis il se sert de ce hasard comme « seed » graine pour nourrir des générateurs pseudo aléatoires. L'entropie est la quantité de hasard nécessaire, et la crypto en demande beaucoup. Voir la différence entre /dev/random et /dev/urandom Lorsque le hasard n'est pas hasardeux, alors il peut se deviner, et la sécurité est compromise quelque soit la qualité des algorithmes de crypto utilisés.
- Une ciphersuite est une liste de choix d'algorithmes de cryptographie. Chacun de ces algorithme a une tâche particulière. La tâche principale est l'échange sécurisé d'un secret partagé, mais ce n'est pas la seule. Identification / Authentification : Signature / Certificat Confidentialité : Echange confidentiel de clés symétriques + Chiffrement Intégrité : Résumé chiffré, Empreinte numérique , fonction de hachage Tout est là : DH : Diffie Hellman DSS : Digital Signature Standard AES_256_CBC : Advanced Encryption Standard 256bits Cipher Block Chaining. RSA : Rivest Shamir Adleman fonctionne à la fois pour l'authentification et pour l'échange de clés SHA : Secure Hash Algorithm Intégrité (analogie cadenas/scellés) : on peut vérifie que le contenu n'a pas été altéré
- La combinaison possible des algorithmes est définie par la norme. Tous les algorithmes existant ne sont pas disponibles. Certaines CipherSuites sont obsolètes et/ou déconseillées, par exemple les suites pour l'export ne sont plus utilisées tout comme celles avec des clés trop faibles. À chaque nouvelle version de TLS des ciphersuites sont ajoutées. Export : Les protocoles de cryptographie à clés fortes on longtemps été restreints pour l'export hors des Etats Unis. Plusieurs méthodes ont été mises en place pour néanmoins fournir une sécurité accrue hors USA. Depuis Janvier 2000 les USA ont levé les limitations à l'export. XXX_EXPORT Certains pays ont néanmoins des restrictions locales ( la russie par exemple ).
- Oh çà ressemble beaucoup au ClientHello ! Mais il n'y a qu'une ciphersuite... Indique les choix du serveur Contenu ProtocolVersion TLS v1 (0301) ... Random SessionID : vide ! ( Elle sera fournie ultèrieurement TLS sous forme encryptée ) CipherSuite choisie CompressionMethod : method null aucune compression.
- Après avoir reçu le ClientHello qui indique entre autres au serveur les envies du client en matière de ciphersuite, le serveur transmet son choix au client, il y joint un nombre au hasard. Selon les versions de TLS et ses extensions il peut aussi fournir l'identificateur de session à ce moment là. Ce n'est pas le cas ici... nous verrons pourquoi plus tard.
- Le serveur envoie son certificat.
- Le certificat est envoyé en clair. Il n'y a aucune raison de protéger le certificat car il est public. Un certificat X509 ne contient pas de donnée secrète. Le certificat est signé par un CA. Remarque: Jusqu'ici tous le échanges ont été fait en clair, rien de ce qui été échangé jusqu'alors n'est secret... Hors sujet ... : On appelle parfois abusivement certificat client un fichier qui contient aussi des clé privées ( par exemple pour votre télédéclaration ), en fait ce fichier contient effectivement un certificat mais aussi des informations privées, ce fichier ne doit en aucun cas être fournis tel quel à quiconque, mais juste installé dans le navigateur.
- Mais que contient vraiment un certificat ? Le certificat électronique est un contenu numérique qui permet de relier des informations entre elles. Par exemple ils valident que tel nom de société correspond bien à tel site web. Ce certificat a été émis par une autorité de certification et contient la preuve cryptographique de cette émission.
- Sous ce navigateur on peut exporter le certificat du serveur, pour par exemple vérifier des informations. Voici le contenu du certificat lorsqu'on l'affiche en texte... quelques remarques : il ne contient que des caractères imprimables il commence par BEGIN et termine par END. Son contenu même sous forme textuelle est illisible C'est normal en fait un certificat est un contenu numérique encodé en DER qui est illisible, ici il est présenté en PEM avec un encodage Base64. Cette encodage permet de copier aisément le contenu d'un certificat dans un fichier texte et en particulier dans un mail.
- Hexdump -C affiche les octets du fichier sous forme hexadécimale et leur décodage en ASCII. Openssl base64 permet d'encoder ou de décoder du base64.
- Openssl vient avec un grand nombre d'outils pour chaque usage. X509 en est un. DER = sous ensemble BER avec une seule façon d'encoder une syntaxe. Encodage : Type Longueur Valeur Openssl asn1parse -in file Les Certificats sont encodés en DER un avantage de DER est d'être compact, un autre est de pouvoir décoder tout ce qu'on est en mesure de décoder même si l'on ne comprends pas certains types qui restent alors opaques. Savoir si l'on doit accepter de ne pas comprendre des parties ou si l'on doit tout comprendre est spécifié dans les rfc.
- Un tiers de confiance, l'autorité de certification, ( ie une société ) appose son tampon sur les requêtes de certificats provenant des sociétés après avoir vérifié que les informations de leur requête sont justes. Un certificat n'a de valeur que si les utilisateurs font confiance à l'autorité de certification qui l'a émise (ISSUER). Les navigateurs font tous confiance à une longue série d'autorités reconnues. Openssl verify permet de vérifier qu'un certificat est bon signé par un CA dont on a le certificat. Remarque: ici la vérification ne prouve rien puisque qu'on obtient le certificat de l'autorité par une simple requète http ce qui ne garanti en rien sa validité.
- L'idée majeure est de faire confiance à une entité qui assure que l'on peut faire confiance à une autre pour une activité particulière. Si l'activité particulière de l'autre c'est aussi d'assurer la confiance, alors la chaine peut s'étendre. Si l'activité particulière de l'autre n'est pas d'assurer la confiance, alors nous n'avons aucune raison de poursuivre la chaine.
- OCSP protocole de vérification en ligne de certificat Rfc2560 But : confirmer que le certificat n'est pas révoqué ou forgé.
- Maintenant le client a vérifié le certificat. C'est à l'application cliente de vérifié la validité du contenu du certificat. En particulier ici c'est le CN= www.google.com qui sera vérifié, on regarde si l'adresse IP distante est bien celle obtenue en résolvant l'adresse dns www.google.com . C'est une vérification importante mais elle n'est pas bullet proof puisqu'internet ne garanti pas que quelqu'un d'autre se soit mis en chemin.
- Le problème est le suivant : Comment échanger un secret entre le client et le serveur alors que n'importe qui peut voir et écouter le trafic...
- De jolis icône pour représenter la cryptographie symétrique à clé secrète ( clé rouge ) la cryptographie asymétrique à clé publique ( clé jaune = publique, marron = privée ) les nombres aléatoires ( dés ) les fonctions de hachage ( hachoir ! ).
- Les fonctions de hachage sont des fonctions qui ont comme propriété: de toujours renvoyer la même valeur lorsqu'elle sont appliquée sur les données ( une fonction quoi :- ) ) de retourner un nombre de taille fixe quelle que soit la valeur. Cependant si deux résultats sont identiques il n'est pas garanti que la valeur de départ soit la même. Vu la taille relativement grande de la valeur de hash il est cependant statistiquement rare de trouver de telles collisions. Les hash cryptographiques diffèrent des hash utilisé pour les bases de données en ce qu'il doit être très difficile de trouver une valeur dont ont connait le hash.
- Si cette propriété n'est pas respectée, ce hash ne sert à rien, il est alors facile de construite de toutes pièces des données qui seront vérifiés par le hash. La notion d'extrèmement difficile est elle même difficile à prouver, les mathématiques portant sur les espaces NP-Complets tentent d'y apporter une réponse. En pratique cela veut dire grosso-modo que l'ensemble des ordinateurs du monde entier regroupés pendant de très nombreuses années ne parviendraient pas à trouver une solution en tenant compte de la loi de moore ( sauf avec beaucoup de chance ou de bugs en tenant compte de la loi de murphy ). C'est un pari...
- Si on modifie ne serait-ce que très lègerement les données à hacher, le résultat est très différent...
- La crypto à clé publique n'a pas vocation à remplacer la crypto symétrique. Elle est vraiment beaucoup lente et elle met en oeuvre des mathématiques complexes. Cependant la crypto à clé asymétriques permet d'échanger des secrets entre deux parties, ce que ne permet pas la crypto à clé secrète qui nécéssite une partie tierce (ex : kerberos).
- Toute la force de la crypto à clé publique est ici. Lorsque que l'on chiffre avec la clé publique d'une personne, seul le possesseur de la clé privée associée peut déchiffer. Toute autre clé donnera un résultat incompréhensible. Il en va de même lorsqu'on utilise la clé privé, alors il n'y a que la clé publique qui puisse déchiffrer. Il n'est pas conseillé de chiffrer trop de données avec sa clé privé, cela l'expose à la cryptanalyse. En général on chiffre le résultat d'un hash sur les données d'origines.
- c'est des math ! Basé sur l'exponentiation modulaire. Openssl propose des outils pour générer les clés RSA, pour en extraire la partie publique et pour les formater sous diverses formes.
- Pas plus de détail que cela
- Pas mieux...
- Après cette longue digression sur la cryptographie à clé publique, nous voici près à aborder l'échange de clé par le client...
- Le message ClientKeyExchange n'est pas chiffré (ici on voit son type en clair et non un 'Encrypted Message' mais -heureusement- son contenu l'est.
- C'est donc le client qui génère la partie réellement secrète. Pour la génération le client fait appelle à ses libraires de génération de nombre aléatoire. Il est impératif que cette valeur ne puisse pas être devinée, et donc il faut qu'elle soit effectivement aléatoire. Et pour qu'elle reste secrète elle la chiffre avec l'algorithme d'échange de clés négocié en utilisant la clé publique fournie dans le certificat du serveur.
- Le serveur utilise sa clé privée pour extraire le morceau de clé qu'on appelle pre-master-secret Voilà, maintenant le serveur et le client partagent une valeur secrète que nul autre qu'eux ne connait.
- Cette valeur n'est pas utilisée directement mais elle est hachée avec les random clients et serveurs afin de fournir un master secret.
- Ce master secret n'est pas utilisé directement non plus mais étendu pour avoir assez de matériel cryptographique pour tous les messages. Les IV (Initial Vectors) sont des valeurs nécessaires aux algorithmes symétriques par bloc en mode chaîné que nous verrons bientôt.
- La version extraite de la RFC... pour le plaisir
- Pour le plaisir... un transparent qui m'a demandé beaucoup de temps et que nous passerons en ... moins de 5 secondes... Vous pourrez le relire à tête reposée... sans garantie d'exactitude...
- Encore un acte de bravoure ... cadeau pour les cours ...
- Il s'agit d'un message de Handshake chiffré, donc il n'est pas possible d'en voir le contenu sans le master secret ( ou la clé privé du serveur dans le cas RSA )... Tout ce qui suit un ChangeCipherSpec est chiffré... Croyez moi sur parole pour son contenu...
- On approche de la fin du handshake. Il reste encore au client et au serveru à s'assurer que les messages échangés n'ont pas été altéré en cours de route. Le Finished est réellement la validation de l'ensebmle du hanshake.
- Le client a utilisé un HMAC sur l'ensemble des messages de hanshake émis ou reçus. Ceci sert à vérifier l'intégrité de tout le processus de handshake jusqu'alors. Ce HMAC est le fameux PRF vu précédemment avec le master secret comme clé et le texte « client » comme seed. Le contenu du message Finished est chiffré avec la clé symétrique de client vers serveur comme tous les messages émis par le client après son envoi d'un ChangeCipherSpec.
- Le serveur a procédé au même calcul de son côté. Si les résultats concordent alors le handshake n'a pas été altéré.
- Bon on devrait arriver à la fin du hanshake... si tout va bien voici les paquets que l'on doit recevoir ....
- Mais ... C'est quoi ce paquet Encrypted Handshake avant ChangeCipherSpec ? Ne devait-on pas recevoir directement ChangeCipherSpec ? Oui... 1- Mais c'était sans compter une extension du protocole TLS qui s'appelle ... 2- C'est un bug de wireshark qui ne reconnaît le nouveau handshake type 4.
- Rfc5077 Cela permet au serveur d'éviter à avoir à conserver les informations de session client
- Le serveur envoi le Ticket de Session, il n'est pas chiffré, donc peut être réutilisé par n'importe qui à condition que celui soit à me de connaître le master secret... Le contenu du ticket de session est en fait un moyen pour le serveur de ne pas stocker chez lui toutes les informations de session du client. Il fait confiance à une clé secrète qu'il utilise et utilise donc le client comme une base de donnée chiffrée et distribuée. Cela dépasse le cadre de cette présentation...
- Derrière un ChangeCipherSpec il est normal que tout le trafic soit chiffré. Donc le Finished l'est.
- Et voilà c'était le dernier message de handshake ! Le client effectue la même vérification que le serveur précédemment. Le PRF utilise « server » comme seed.
- La partie « handshake » est terminée, chacune des partie est à même de chiffrer le trafic avec des clés symétriques. Mais comment fonctionne la crypto symétrique ?
- RC4 est un algorithme à flot, il génère une séquence ( infinie ) de bits qui peuvent être combinés avec des XOR sur le flot de donnée à chiffrer. Les algorithmes à bloc ne savent chiffrer que des blocks de taille fixe. Il est donc nécessaire pour les utuiliser de compléter le message pour qu'il soit de d'une taille d'une mutliple des blocs. Pour chiffrer un flot de donnée ils nécessitent d'être combinés avec un mode de chiffrement. Jusqu'à présent TLS utilise exclusivement CBC bien qu'il existe d'autres modes ECB, CBF, OFB ...
- Pour des raisons évidentes ce mode n'est pas utilisé par TLS. En effet les même blocs en entrée fournissent les même blocs chiffrés en sortie.
- En injectant le résultat chiffré du tour précedent avec un XOR sur le bloc suivant avant chiffrage on introduit suffisamment de modifications pour qu'il ne soit plus possible de reconnaître le message d'origine.
- La réutilisation d'une session et son partage pour plusieurs connections https est un grand classique. En effet les navigateurs ont l'habitude d'ouvrir de multiple connections simultanées vers un serveur pour lire en parallèles les différents sous-contenus d'une page ( principalement les images ). Réutiliser une session une fois le master secret connu permet d'éviter à avoir à faire un handshake complet et d'éviter d'utiliser la cryptographie à clé publique qui est très lente. La réutilisation et la renégotiation ont généré de nombreuses vulnérabilité qui ont été fixé par de nouvelles versions de TLS.
- Ce qu'il faut voir : Il n'y a pas d'échange de clé ni de certificats. Tout réside dans le Finished qui ne fonctionne que si le serveur et le client partagent le même master secret. Cependant les clés finales sont différentes étant donné que les random client et serveur sont différents et que le PRF est réutilisé à partir du master secret pour les générer.
- Ici on Utilise le Session Ticket pour réutiliser la connection, le SessionID peut être créé par le client.
- C'est dans ce cas préçis que le client doit disposer d'un certificat et aussi de la clé privée correspondante. Classiquement en https, tls est utilisé pour n'identifier que le serveur par son certificat L'identification du client n'est pas la même que celle du serveur elle requiert un échange particulier. Elle est optionnelle et nécessite que le client dispose d'une clé privée associée à son certificat. Il se peut même qu'aucun des deux ne soient identifiés ( diffie hellman ) tout en assurant la confidentialité mais c'est un cas particulier
- Ensemble de bibliothèques conçues pour supporter le développement multi-plates-formes d'applications clientes et serveurs sécurisées. Il supporte les certificats SSLv2 et v4, TLS, PKCS #5, #7, #11, #12, S/MIME, X.509 v3 et d'autres standards de sécurité. objdump -T /usr/lib/libnss3.so.1d
- Pour assurer la meilleure sécurité possible le protocole de sécurisation doit être le plus proche possible de la fonction qu'il sécurise. C'est pourquoi selon la fonction, tous les protocoles de sécurités ne sont pas égaux. Par exemple on privilégie souvent IpSec sur TLS pour les réseaux privés virtuels et Ipsec n'assure pas les services rendus par https... Ce que partagent les membre de la famille De façon générale la « cryptographie » Les algorithmes de chiffrement Les mécanismes généraux de signature et de résumés chiffrés (digest) Parfois ils utilisent la même librairie de crypto (openssh utilise la librairie libcrypt de openssl )