Ich habe einen schwerwiegenden Fehler in OpenSSL 1.0.1 auf Ubuntu 12.04 festgestellt:
Ссылка & lt; - vom 3. Oktober 2012!
Das Wichtigste ist, dass ich mich mit einigen Servern verbinden kann, aber nicht mit anderen. Verbindung zu Google funktioniert:
openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
%Vor%Aber die Verbindung zu Facebook funktioniert nicht:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC-SHA
%Vor%Die Facebook-Verbindung bleibt entweder hängen, nachdem der Client seinen hallo-Puffer gesendet hat, und empfängt niemals die Hallo-Antwort des Servers oder gibt einen Fehlercode zurück, wenn ich eine Chiffre übergebe, die er erkennt. Dies geschieht mit -tls1 und -ssl3. Ich habe versucht jeden Parameter zu öffnen, den ich mir vorstellen kann.
apt-cache showpkg openssl
%Vor%Ich habe auch jeden Parameter ausprobiert, den ich mir vorstellen kann, aber ohne Erfolg, weil er openssl unter der Haube verwendet.
Ich bin besorgt, dass Ubuntu keine sicheren Verbindungen aufbauen kann (eine erstaunliche Aussage, merke ich). Nach zwei harten Tagen, an denen ich meinen Kopf gegen dieses Problem geschlagen habe, bete ich im Grunde, dass jemand einen Workaround kennt. Ich erwäge ein Downgrade auf OpenSSL 1.0.0 oder benutze stattdessen libcurl4-dev mit gnutls-dev. Beide Lösungen hinterlassen einen faulen Geschmack in meinem Mund. Vielen Dank im Voraus für Ihre Hilfe.
P.S. All dies ist so, dass mein Server mit externen https-REST-APIs interagieren kann. Ich halte dies für eine grundlegende Anforderung in jedem Webserver heute, keine Ausreden.
UPDATE: Hier ist meine Ausgabe, ohne eine Chiffre zu übergeben. Es spielt keine Rolle, ob ich auch -CAfile überlasse oder nicht:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
%Vor% Warum gibst du -cipher SRP-AES-256-CBC-SHA weiter, wenn du dich mit graph.facebook.com verbindest? Facebook unterstützt SRP leider nicht: Ссылка .
Funktioniert es, wenn Sie das nicht bestehen?
Können Sie auch die IP-Adresse angeben, die Sie erhalten? Mit 69.171.229.17 kann ich genau dieses ClientHello reproduzieren (modulo das Nonce und mit RC4-SHA sind die einzigen Chiffren die SCSV speichern) und bekomme einen erfolgreichen Handshake.
Zuletzt, haben Sie versucht, über einen SSH-Tunnel nach woanders zu gehen? Leider haben wir bei der Bereitstellung von TLS-Funktionen in Chrome wiederholt Netzwerkhardware gefunden, die TLS-Verbindungen unterbricht. (Obwohl ich nicht an einen Fall denken kann, in dem -ssl3 es nicht beheben würde, wenn die Hardware nicht aktiv versucht, Verbindungen zu zensieren.)
Wenn ich die MTU auf meiner Ubuntu-Box von 1500 auf 1496 setze (weil eine unserer Firewalls zu niedrig eingestellt ist), kann ich eine Antwort vom Server erhalten, ohne dass ich neu starten muss ursprüngliche MTU, die 1500 sein sollte):
%Vor%Ich habe meine MTU durch Pingen mit immer größeren Puffern entdeckt (addiere 28 Bytes für den UDP-Header):
Fehlt für 1472 + 28 = 1500:
%Vor%Arbeiten für 1468 + 28 = 1496:
%Vor%Mit 1496 kann ich mich nun auf facebook.com einrollen:
%Vor%Ich persönlich denke, dass MTU absolut nichts mit dem zu tun haben sollte, was der Benutzer auf der Stream-Ebene mit TCP sieht, also hoffe ich, dass die OpenSSL-Leute das beheben. Ich wünschte auch, dass jemand einen Automagic-Bug-Submitter für Bugs erfinden würde, die zutiefst verbreitet und zeitaufwendig sind.