Solution de contournement OpenSSL 1.0.1 dans Ubuntu?

J’ai rencontré un bug sérieux dans OpenSSL 1.0.1 sur Ubuntu 12.04:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 <- daté du 3 octobre 2012!

L’essentiel est que je peux me connecter à certains serveurs mais pas à d’autres. Connexion à google works:

openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificatees.crt

... Protocol : TLSv1.1 Cipher : ECDHE-RSA-RC4-SHA Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397 Session-ID-ctx: Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD 0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.... 0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1. 0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6.. 0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon 0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$ 0090 - 3c f0 ca a5 <... Start Time: 1354063165 Timeout : 300 (sec) Verify return code: 0 (ok)

Mais la connexion à Facebook ne permet pas:

openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificatees.crt -cipher SRP-AES-256-CBC-SHA

 CONNECTED(00000003) SSL_connect:before/connect initialization write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40)) 0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB 0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D 0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h...... 0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#....... >>> TLS 1.1 [length 003b] 01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5 2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61 5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00 00 09 00 23 00 00 00 0f 00 01 01 SSL_connect:unknown state read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7)) 0000 - 15 03 02 00 02 02 28 ......( SSL3 alert read:fatal:handshake failure <<< TLS 1.1 [length 0002] 02 28 SSL_connect:error in unknown state 140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 64 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE

La connexion facebook se bloque lorsque le client envoie son tampon hello et ne reçoit jamais la réponse du serveur hello, ou renvoie un code d’erreur si je transmets un chiffre qu’il reconnaît. Cela se produit avec -tls1 et -ssl3. J’ai essayé tous les parameters pour openssl je peux penser.

apt-cache showpkg openssl

 ... Provides: 1.0.1-4ubuntu5.5 - 1.0.1-4ubuntu5.3 - 1.0.1-4ubuntu3 -

J’ai aussi essayé tous les parameters que je peux imaginer pour boucler mais sans succès, car il utilise openssl sous le capot.

Je crains que Ubuntu ne puisse pas établir de connexions sécurisées (une déclaration étonnante, je le sais). Après avoir passé deux jours à me battre contre ce problème, je prie pour que quelqu’un sache une solution. J’envisage une rétrogradation vers OpenSSL 1.0.0 ou l’utilisation de libcurl4-dev avec gnutls-dev à la place. Les deux solutions laissent un goût pourri dans ma bouche. Merci d’avance pour toute aide que vous pouvez fournir.

PS tout ce travail est pour que mon serveur puisse s’interfacer avec des API REST externes. Je considère cela comme une exigence fondamentale dans tout serveur Web aujourd’hui, aucune excuse.

UPDATE: Voici ma sortie sans passer un chiffre. Peu importe si je passe -CAfile ou non:

openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificatees.crt

 CONNECTED(00000003) SSL_connect:before/connect initialization write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2)) 0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj 0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.wfH. 0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f.. 0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8...... 0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............ 0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................ 0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....ED... 0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A.......... 0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................ 0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I....... 00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2......... 00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................ 00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................ 00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#..... 00e0 - 01 01 .. >>> TLS 1.1 [length 00dd] 01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62 19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8 c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02 01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 01 SSL_connect:unknown state

Pourquoi transmettez-vous -cipher SRP-AES-256-CBC-SHA lors de la connexion à graph.facebook.com ? Facebook ne supporte certainement pas SRP: http://srp.stanford.edu/ .

Est-ce que ça marche si tu ne passe pas ça?

Aussi, pouvez-vous donner l’adresse IP que vous obtenez? Avec 69.171.229.17, je peux reproduire l’exact ClientHello (modulo le nonce et avec RC4-SHA sont les seuls chiffrés sauf le SCSV) et j’ai une poignée de main réussie.

Enfin, avez-vous essayé de faire passer un tunnel SSH à un autre endroit? Malheureusement, lors du déploiement des fonctionnalités TLS dans Chrome, nous avons trouvé à plusieurs resockets du matériel réseau qui interrompt les connexions TLS. (Bien que je ne puisse pas penser à un cas où -ssl3 ne résoudrait pas le problème à moins que le matériel ne tente activement de censurer les connexions.)

Définir le MTU sur ma boîte Ubuntu de 1500 à 1496 (en raison de l’un des pare-feu trop bas) me permet de recevoir une réponse du serveur sans avoir à redémarrer (veillez à appeler ifconfig en premier et à écrire votre MTU original devrait être 1500):

 sudo ifconfig eth0 mtu 1496

J’ai découvert mon MTU en envoyant un ping avec des tampons de plus en plus grands (ajoutez 28 octets pour l’en-tête UDP):

Échoue pour 1472 + 28 = 1500:

 ping -s 1472 facebook.com PING facebook.com (66.220.158.16) 1472(1500) bytes of data. ...

Fonctionne pour 1468 + 28 = 1496:

 ping -s 1468 facebook.com PING facebook.com (69.171.229.16) 1468(1496) bytes of data. 1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms ...

Avec 1496, je suis maintenant capable de me tourner vers facebook.com:

 curl -v https://facebook.com * About to connect() to facebook.com port 443 (#0) * Trying 66.220.152.16... connected * successfully set certificatee verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using RC4-SHA * Server certificatee: * subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com * start date: 2012-06-21 00:00:00 GMT * expire date: 2013-12-31 23:59:59 GMT * subjectAltName: facebook.com matched * issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign * SSL certificatee verify ok. > GET / HTTP/1.1 > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 > Host: facebook.com > Accept: */* > < HTTP/1.1 301 Moved Permanently < Location: https://www.facebook.com/ < Content-Type: text/html; charset=utf-8 < X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0= < Date: Wed, 28 Nov 2012 19:52:25 GMT < Connection: keep-alive < Content-Length: 0 < * Connection #0 to host facebook.com left intact * Closing connection #0 * SSLv3, TLS alert, Client hello (1):

Personnellement, je pense que MTU ne devrait absolument rien avoir à voir avec ce que l’utilisateur voit au niveau du stream avec TCP, alors j’espère que les gens d’OpenSSL le feront. Je souhaite aussi que quelqu'un invente un système de soumission automatique de bogues pour les bogues qui sont profondément répandus et qui perdent du temps.