it-swarm.com.de

curl kann HTTPS-Inhalt nicht abrufen: Fehler: 14094410: SSL-Routinen: ssl3_read_bytes: sslv3-Alarm-Handshake-Fehler

Ich versuche, mit Curl unter Windows 10 und Ubuntu 16.04 auf die Website https://www.lawsociety.com.au Zuzugreifen. Es funktioniert unter Ubuntu, schlägt jedoch unter Windows mit der Meldung error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure Fehl. Ich bin mir nicht sicher, was falsch ist und wie ich es beheben kann.

Hier ist die Curl-Ausgabe auf einem Windows-Computer:

> curl -i -v -I https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* TCP_NODELAY set
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: D:\dev\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, Server hello (2):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

curl-Version:

curl 7.57.0 (x86_64-pc-win32) libcurl/7.57.0 OpenSSL/1.1.0g (WinSSL) zlib/1.2.11 WinIDN libssh2/1.8.0 nghttp2/1.28.0
Release-Date: 2017-11-29
Protocols: dict file ftp ftps Gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL    

Gleicher Befehl auf Ubuntu-Box:

$ curl -I -v https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.0 / RSA_3DES_EDE_CBC_SHA1
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: *.lawsociety.com.au (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=AU,postalCode=2000,ST=NSW,L=Sydney,street=170 Phillip Street,O=THE LAW SOCIETY OF NEW SOUTH WALES,OU=PremiumSSL Wildcard,CN=*.lawsociety.com.au
*        start date: Fri, 17 Mar 2017 00:00:00 GMT
*        expire date: Mon, 16 Apr 2018 23:59:59 GMT
*        issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Organization Validation Secure Server CA
*        compression: NULL
* ALPN, server did not agree to a protocol
> HEAD / HTTP/1.1
> Host: www.lawsociety.com.au
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Tue, 26 Dec 2017 09:04:02 GMT
Date: Tue, 26 Dec 2017 09:04:02 GMT
< Server: Oracle-Application-Server-11g
Server: Oracle-Application-Server-11g
< Cache-Control: no-cache
Cache-Control: no-cache
< Content-Length: 36272
Content-Length: 36272
< Set-Cookie: JSESSIONID=kGs3hCQCW7FPhQ2Lh0JvKn9JvXhhHCK2GQKXvLps308Ww1D70pMp!1826685759; path=/; HttpOnly
Set-Cookie: JSESSIONID=kGs3hCQCW7FPhQ2Lh0JvKn9JvXhhHCK2GQKXvLps308Ww1D70pMp!1826685759; path=/; HttpOnly
< X-Oracle-DMS-ECID: 005OJeGQSZb9xWGayxQ_MG0007Z60000EU
X-Oracle-DMS-ECID: 005OJeGQSZb9xWGayxQ_MG0007Z60000EU
< X-Powered-By: Servlet/2.5 JSP/2.1
X-Powered-By: Servlet/2.5 JSP/2.1
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8

<
* Connection #0 to Host www.lawsociety.com.au left intact

Ich habe den Befehl openssl s_client Unter Windows ausprobiert:

> openssl s_client -connect www.lawsociety.com.au:443
CONNECTED(00000224)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=AU/postalCode=2000/ST=NSW/L=Sydney/street=170 Phillip Street/O=THE LAW SOCIETY OF NEW SOUTH WALES/OU=PremiumSSL Wildcard/CN=*.lawsociety.com.au
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
... <removed to save space> ...
-----END CERTIFICATE-----
subject=/C=AU/postalCode=2000/ST=NSW/L=Sydney/street=170 Phillip Street/O=THE LAW SOCIETY OF NEW SOUTH WALES/OU=PremiumSSL Wildcard/CN=*.lawsociety.com.au
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 5683 bytes and written 621 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 8198FE887E4FC12D68E2388D4C052ABF
    Session-ID-ctx:
    Master-Key: 93688C15A75E3E9F596AF96DFF72B557AD28A3FEF8764401CBD12D1F432EAF4D216595D74338AF24498AB29FF5ABE759
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1514278771
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Die Verbindung scheint also in Ordnung zu sein. Das Öffnen der URL in einem Browser funktioniert ebenfalls einwandfrei.

Was vermisse ich?

UPDATE

1. Eines der möglichen Probleme ist, dass die Website eine veraltete RC4-SHA-Verschlüsselung verwendet. Ich habe versucht, es explizit mit Curl zu aktivieren, aber Curl lehnt es ab:

> curl -i -v -I --ciphers "RC4-SHA" https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* TCP_NODELAY set
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* failed setting cipher list: RC4-SHA
* Closing connection 0
curl: (59) failed setting cipher list: RC4-SHA

2. Ein weiteres potenzielles Problem besteht darin, dass Root-Zertifikate möglicherweise nicht verfügbar sind. Curl wird jedoch mit dem neuesten Mozilla CA-Bundle (curl-ca-bundle.crt) Geliefert, daher glaube ich, dass korrekte Zertifikate verwendet werden.

Ich habe auch alle öffentlichen Zertifikate von der funktionierenden Ubuntu-Box auf den Windows-Computer kopiert und den Parameterpfad zum Einrollen mit dem Parameter --capath Angegeben - das hilft nicht.

. Der Vollständigkeit halber habe ich es mit dem neuesten Python 3.6.4:

import urllib.request
with urllib.request.urlopen('https://www.lawsociety.com.au/') as u:
    print(u.read())

Python SSL sollte Windows-Funktionen für HTTPS verwenden. Es schlägt jedoch mit demselben Fehler fehl:

ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:777)
...
During handling of the above exception, another exception occurred:
...
urllib.error.URLError: <urlopen error [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:777)>

Es sieht also so aus, als ob das Problem nicht beim fehlenden Zertifikat liegt, sondern irgendwo früher auftritt. Ich bin kein SSL-Experte, daher kann ich mich irren.

LÖSUNG

Die Hauptursache des Problems ist das veraltete SSL-Protokoll + die von der Website verwendeten Chiffren. Damit Curl funktioniert, habe ich es auf die Version heruntergestuft, die OpenSSL 1.0.2 verwendet, das weiterhin RC4-Chiffren unterstützt. Danach funktioniert alles einwandfrei.

Für diejenigen, die Python Lösung:

import ssl
import urllib.request

ctx = ssl.SSLContext(protocol=ssl.PROTOCOL_SSLv3)
ctx.set_ciphers('SSLv3')
# alternatively, for this particular website:
#ctx.set_ciphers('RC4-SHA:RC4-MD5')

with urllib.request.urlopen('https://www.lawsociety.com.au/', context=ctx) as u:
    print(u.read())
5
Alex Blekhman

Ich glaube, dass es hier tatsächlich zwei sich etwas überschneidende Probleme gibt, die beide damit zusammenhängen, dass der Server anscheinend veraltet ist oder wahnsinnig betrieben wird. Analyse von ssllabs zeigt, dass nur SSLv3- und TLSv1.0-Protokolle und nur vier Chiffresuiten unterstützt werden:

TLS_RSA_WITH_DES_CBC_SHA (0x9)   INSECURE   56
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK  112
TLS_RSA_WITH_RC4_128_MD5 (0x4)   INSECURE   128
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE   128

(die im OpenSSL-Namensschema DES-CBC-SHA, DES-CBC3-SHA, RC4-MD5 und RC4-SHA sind).

Erstens ist der Server, wie von SSLLabs festgestellt, "version intolerant"; Wenn Sie es ClientHello-Angebotsversionen über 1.0 in einem Datensatz mit Version 1.0 (und ansonsten akzeptabel) senden, wird bis zu 1.0 verhandelt, wie es sollte *, aber wenn Sie dieses Angebot mit Datensatzversion 1.1 oder senden 1.2 Wie bei einigen Softwareprogrammen (jedoch nicht bei AFSSIC) hat der Server mit der Warnung close_notify abgebrochen (was für diesen Status nicht korrekt ist). (*: Nun, da es vorausgesetzt sollte, dass es überhaupt 1.0 unterstützt)

Zweitens werden nur die vier oben genannten Chiffrensuiten unterstützt. Neuere Versionen von OpenSSL und speziell 1.1.0g unterstützen Single-DES (überhaupt) nicht mehr, da es vollständig defekt ist, und unterstützen RC4 oder Triple-DES nicht standardmäßig wegen - verschiedene Vorurteile und der generische Geburtstagsangriff ; Wenn also OpenSSL verwendet wird, gibt es keine gemeinsamen Chiffresuiten, und der Server bricht mit der Warnung handshake_failure korrekt ab. Es sollte jedoch möglich sein, RC4 und/oder TDES zu aktivieren, es sei denn, sie wurden zum Zeitpunkt der Erstellung (Kompilierung) konfiguriert. Ich stelle fest, dass Ihre Windows-Version (WinSSL) zusätzlich bis OpenSSL/1.1.0g; Ich weiß nicht, ob dies bedeutet, dass hier (oder überhaupt) Schannel verwendet wird. In diesem Fall könnte dies der Grund sein --ciphers RC4-SHA (unter Verwendung des OpenSSL-Namensschemas) hat nicht funktioniert.

Hinweis: Bei Windows-Programmen, insbesondere bei "Importen" wie Curl und OpenSSL, werden Bibliotheken normalerweise nicht gemeinsam genutzt, wie dies bei Unbuntu und den meisten Linux-Versionen (und anderen Unix-Versionen) der Fall ist. Sie könnten versuchen, openssl version auf Ihrem Windows OpenSSL, um zu sehen, um welches es sich handelt; Ich wette, es ist nicht das Neueste, und wenn Sie das Neueste erhalten, wird das gleiche Problem über die Befehlszeile angezeigt.

Ubuntu 16.04 (ich nehme an, LTS?) Blutet Edge nicht und es ist sinnvoll, weiterhin Chiffren zu unterstützen, die erst kürzlich veraltet waren.

5

Das Problem liegt im Hash-Algorithmus und der Verschlüsselung der Websites. Zumindest RC4 wurde vor langer Zeit für unsicher erklärt, so dass viele Programme die Verwendung ablehnen. Außerdem sind einige SHA - Algorithmen ebenfalls nicht sicher. Der eigentliche Chiffriercode wurde möglicherweise vollständig aus der Software entfernt.

--- Vorherige falsche Antwort ---

In Ihrer Windows OpenSSL-Version fehlen die vertrauenswürdigen Stammzertifikate, mit denen das TLS-Zertifikat des Remoteservers überprüft wird.

Dies ist die Zeile von Windows CURL, in der die Überprüfungszertifikate geladen werden:

* successfully set certificate verify locations:
*   CAfile: D:\dev\curl\bin\curl-ca-bundle.crt

Und ähnlicher Eintrag in Linux:

* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs

Dies liegt daran, dass Windows OpenSSL den Windows-Zertifikatspeicher nicht unterstützt. Sie müssen die Zertifikate dort manuell installieren.

https://maulwuff.de/research/ssl-debugging.html#hdr3. enthält einige Informationen zu diesem Problem und dessen Lösung.

0
Tero Kilkanen

Ich hatte so ein Problem. Dieser Nachrichtenfehler " cURL-Fehler 35: Fehler: 14094410: SSL-Routinen: ssl3_read_bytes: sslv3-Alarm-Handshake-Fehler (http_request_failed) " wird in WordPress angezeigt.

Ich habe versucht, Jetpack von WordPress zu konfigurieren und habe Cloudflare verwendet.

Ich konnte das Problem beheben, indem ich auf die Schaltfläche Enalbe Universal SSL in CloudFlare klickte.

0
Saulo Souza