Des outils pour tester BEAST / CRIME qui ne sont PAS basés sur Internet?
Nous avons de plus en plus de pression pour identifier et corriger toute configuration de serveur HTTPS vulnérable aux BÊTES (CBC) et CRIMINALITÉ (compression). Nous devons réparer les serveurs qui sont accessibles à Internet en général, les serveurs qui ne sont accessibles qu'aux adresses IP des partenaires limités via Internet, et les serveurs qui sont internes.
Les serveurs disponibles sur Internet en général peuvent être analysés à l'aide du service Web Qualys 'SSL Labs . Il donne une indication claire de la vulnérabilité de BEAST, et probablement le paramètre "Compression" qui n'est pas un mauvais signe aujourd'hui se rapporte à CRIME et commencera à déclencher une alerte dans un proche avenir. Cependant , cela n'aide pas avec les sites qui ne sont généralement pas disponibles via Internet.
Je peux trouver toutes sortes d'informations sur la façon de tester les choses à la main - par exemple, discussion des chiffres pour BEAST et recettes openssl s_client pour tester la compression . Cependant, dans ma vieillesse, j'aime de plus en plus les outils - comme SSL Labs - qui me disent simplement, plutôt que d'avoir à déchiffrer les différentes chaînes de chiffrement openssl ("Pas de CBC, sauf s'il s'agit de TLS 1.1+, auquel cas CBC est d'accord, et n'oubliez pas mardi ").
J'apprends également que je ne suis pas en mesure d'obtenir un résultat indiquant la compression à l'aide de divers en-têtes HTTP openssl + codés à la main sur un serveur Web dont SSL Labs dit que la compression est activée. En qui je crois? Je suis plus enclin à faire confiance aux outils qu'aux recettes, car les outils sont généralement construits sur une recette qui est ensuite testée dans une grande variété de configurations et corrigée, tandis que les recettes fonctionnent souvent pour quelqu'un, quelque part, quelque part.
Donc, ce que je recherche, c'est un outil en ligne de commande comme sslscan que je peux exécuter sur tous mes serveurs, quelle que soit leur disponibilité sur Internet en général. (Oui, je me rends compte que sslscan imprime les chiffres, que je peux interpréter pour déterminer la vulnérabilité de BEAST - mais je veux un système expert (ou juste compétent!) Qui est moins faillible que moi pour regarder cette sortie et faire l'appel).
Edit (2012/09/23): Demandez et vous recevrez . TestSSLServer est un simple outil en ligne de commande que j'ai écrit ce week-end; il obtient d'un serveur SSL/TLS donné la liste des suites de chiffrement prises en charge, des versions de protocole et de la prise en charge de Deflate au niveau TLS. Il donne ensuite un résumé de la force du chiffrement et de la vulnérabilité aux attaques BEAST et CRIME. Il est écrit en Java et devrait fonctionner "partout" (je ne l'ai testé que depuis un client Linux/ppc, cependant).
(Notez que BEAST et CRIME ciblent le client, pas le serveur. Nous parlons ici des mesures que le serveur peut prendre pour "protéger" le client en ne lui permettant pas d'utiliser des combinaisons de fonctionnalités vulnérables.)
Réponse originale:
Pour la compression, il y a deux endroits où il peut être activé; le billet de blog que vous liez parle du mauvais endroit, celui sur lequel l'attaque CRIME est pas à propos.
CRIME utilise la compression qui est au niveau SSL/TLS: une compression négociée lors de la prise de contact, et qui s'applique à chaque octet envoyé dans le tunnel SSL/TLS. Dans un contexte HTTPS, cette compression opère à la fois sur les corps de requête/réponse HTTP et HTTP en-têtes (y compris les cookies, ce qui est le point de CRIME). La compression qui se produit au niveau [~ # ~] http [~ # ~] est celle qui est spécifiée avec [~ # ~] http [~ # ~] en-têtes (comme "Accept-Encoding") et qui s'applique à la demande/réponse corps uniquement. Ça la compression ne couvre pas les cookies (qui sont dans les en-têtes) et est donc, sans doute, sans CRIME.
(Cela n'exclut pas l'existence théorique d'une attaque de type CRIME qui abuse de la compression de niveau HTTP sur les corps, mais cela nécessiterait un corps de demande ou de réponse qui contient à la fois des données confidentielles et des données que l'attaquant peut choisir.)
Pour tester un serveur pour la prise en charge de la compression, utilisez ceci:
openssl s_client -connect www.theservername.com:443
Cela produira une sortie qui contient le certificat du serveur et se termine par un bloc de texte qui ressemble à ceci:
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1.1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 4B4110C44117BA0382CA6C3903A8185E0C156B253073E66B2D44F04B83611633
Session-ID-ctx:
Master-Key: C11D38EE064BE6549364D54BD60E216E367A52825E62FFCCBEFC4AC8DB97D07BD72B7355CB268B91E3AD176EB69446AA
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 4c f8 be c1 d1 0f cf 03-4a 99 89 8b 75 28 97 3c L.......J...u(.<
0010 - 3e cf 2a b8 0f f0 d1 b4-7d c7 83 16 03 2c f0 8a >.*.....}....,..
0020 - 1b a7 57 be dd 1b be a3-14 eb cf 34 42 99 e0 5a ..W........4B..Z
0030 - c5 96 43 da c7 d9 dd da-ed 4c e2 7c eb c1 8b a8 ..C......L.|....
0040 - ce 73 c8 22 43 10 88 d6-d2 f2 df 91 9d 47 71 70 .s."C........Gqp
0050 - 77 bb c0 55 cd 46 34 3b-44 26 36 a1 7f 37 64 cd w..U.F4;D&6..7d.
0060 - 72 64 66 89 cc f6 8b 23-17 9b 9a 91 23 6a f7 c2 rdf....#....#j..
0070 - 8a e2 8c 10 85 8f b7 6c-60 d2 b6 72 b3 13 98 8b .......l`..r....
0080 - 75 da 68 cc 2a ca 4f fb-ec 4c f2 db 91 4a f7 2a u.h.*.O..L...J.*
0090 - 40 eb 92 44 c7 7a f7 84-ef 65 ea 2c 96 aa c5 ba @..D.z...e.,....
00a0 - c3 b5 76 6d 52 03 85 c9-27 53 a2 a4 70 54 06 37 ..vmR...'S..pT.7
00b0 - 82 3e 09 93 21 6d f6 e7-eb cf c3 5e 26 19 e1 a2 .>..!m.....^&...
Compression: 1 (zlib compression)
Start Time: 1348073749
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Cela a été fait sur un serveur qui prend en charge la compression de niveau TLS. Tu vois "zlib compression "à trois endroits: la compression de dégonflage est en effet prise en charge par ce serveur. Notez qu'il n'y a pas un seul signe d'en-tête HTTP n'importe où! Tapez simplement la commande openssl et regardez la sortie. Pas besoin de entrez un en-tête HTTP.
Sur un serveur qui ne prend PAS en charge la compression de niveau TLS, les choses ressembleront à ceci:
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 59D609F13BEE9157D26318ADB12F4CF219EF7A1BC2C87AF84AD66773303F90A6
Session-ID-ctx:
Master-Key: 1DD9E0C306A86A7EC823561EF0B1F47B63E70B43D57F3B3FBB3D389863F540E3B4CCE5DE454E6D19811C24001E95777A
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - de c6 06 25 10 c9 22 38-c4 1f 82 d7 c7 b5 62 08 ...%.."8......b.
0010 - 01 c0 e1 26 e2 64 8a 62-99 74 85 bb 60 bf a8 e0 ...&.d.b.t..`...
0020 - 65 08 74 89 d5 62 45 e9-b4 f0 80 4e f7 bd ff d5 e.t..bE....N....
0030 - 6a 12 3b 90 97 ca 7a f4-d1 1b e1 0d 89 d2 52 49 j.;...z.......RI
0040 - 11 fe 92 82 94 70 ba 4b-5e 81 ff f2 12 62 f4 79 .....p.K^....b.y
0050 - 11 eb 74 7a d6 ee 10 4e-b5 6d 50 8d 1c 1c 8e 57 ..tz...N.mP....W
0060 - 19 46 67 91 89 2e 45 28-2e 49 94 8e c8 32 28 bf .Fg...E(.I...2(.
0070 - 7b 73 82 ab 63 c4 b7 8f-5c b3 1b 5c 74 59 3c 8d {s..c...\..\tY<.
0080 - ec 8a 6a 3a 28 c2 82 c1-d7 d5 4f ec 7e 79 e7 57 ..j:(.....O.~y.W
0090 - 4a f9 45 e7 J.E.
Start Time: 1348074257
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Le "Compression: NONE "montre que ce deuxième serveur rejette en effet l'utilisation de la compression au niveau TLS.
Notez également que le premier serveur a choisi DHE-RSA-AES256-SHA comme suite de chiffrement, c'est-à-dire une suite qui utilise le chiffrement par blocs AES en mode CBC. Ce premier serveur est alors potentiellement vulnérable à la fois à BEAST et à CRIME. Le deuxième serveur a sélectionné ECDHE-RSA-RC4-SHA, qui est immunisé contre les BEAST.
(Le premier serveur est le mien; comme je n'utilise aucun cookie sur celui-ci, je ne suis pas inquiet des attaques de vol de cookies. Le deuxième serveur est www.google.com.)
Si je trouve le temps, j'écrirai un outil qui donne de tels résultats plus facilement. Il n'est pas nécessaire de faire une négociation SSL/TLS complète, seulement pour envoyer un ClientHello et regarder le ServerHello qui revient.