Httpie: HTTPie ignoriert Systemzertifikate

Wäre es sinnvoll, ssl.get_default_verify_paths () zu verwenden, um die Standardpfade abzurufen?

Ich würde folgendes Verhalten vorschlagen:

Wenn --verify einen anderen Parameter als no oder yes übergibt, übergeben Sie den Parameter an Anforderungen.

Wenn --verify auf yes gesetzt ist:
1) Wenn REQUESTS_CA_BUNDLE festgelegt ist, übergeben Sie True an Anforderungen zur Überprüfung.
2) elif Umgebungsvariable ssl.get_default_verify_paths (). OpenSsl_cafile_env ist gesetzt, übergeben Sie diese an Anforderungen überprüfen
4) elif Umgebungsvariable ssl.get_default_verify_paths (). OpenSsl_capath_env wird übergeben, um Anforderungen zu überprüfen
5) elif ssl.get_default_verify_paths (). Capath ist nicht None. Übergeben Sie dies an die Überprüfungsanforderungen
6) sonst True an Anforderungen zur Überprüfung übergeben

Beachten Sie jedoch, dass ssl.get_default_verify_paths erst seit python3.4 verfügbar ist

@luv ist nicht nur nur in 3.4+ und 2.7.10+ verfügbar, sondern funktioniert auch nicht auf jeder Plattform. Aus diesem Grund arbeiten Anfragen an einem eigenen Problem, um dieses Problem für die Benutzer zu lösen. Bitte hören Sie auf, httpie ständig zu kommentieren. Dies ist ein Problem, das bei Anfragen und nicht bei httpie IMO auftritt.

@ sigmavirus24 wtf man? Keine Ahnung, was du mit ständigem Kommentieren meinst, aber was auch immer, ich sehe, du bist nicht einmal ein httpie-Mitwirkender. Ich nehme nur einen dummen Troll an: /

Ein kurzer Blick auf den Curl-Quellcode, um zu sehen, wie eine funktionierende Implementierung aussieht.

Wenn man all diese Amiga- und VMS-ifdefs ignoriert und viele verschiedene SSL-Bibliotheken unterstützt, ist das eigentlich ziemlich dumm und es werden keine openssl X509_ * -Suchmethoden verwendet (wie sie beispielsweise in get_default_verify_paths () im Python-SSL-Modul verwendet werden).

Stattdessen iteriert Curl zum Zeitpunkt der Kompilierung einfach über eine Reihe bekannter Speicherorte (siehe diese m4dness https://github.com/curl/curl/blob/master/acinclude.m4#L2560) und unterstützt dann explizit das Überschreiben mit (CURL_CA_BUNDLE und ) Umgebungsvariablen SSL_CERT_DIR und SSL_CERT_FILE zur Laufzeit (wiederum ohne Verwendung von Dingen wie X509_get_default_cert_file_env ()). Das ist es.

Wie wäre es also mit der Implementierung des gleichen Ansatzes in reinem Python? (Ja, es sieht verdammt schnell und schmutzig aus, aber es funktioniert für Curl!) Aber es wird Unterstützung für Windows (ssl.enum_certificates?) Und OS X hinzugefügt (hier nicht sicher, aber Python scheint die von Apple bereitgestellte OpenSSL-Bibliothek unter OS X 10.6+ zu verwenden das sollte also schon gut gehen!).

@luv danke für den Bericht, aber bitte seien Sie anderen Mitgliedern gegenüber respektvoller. @ sigmavirus24 ist ein Hauptentwickler von Anfragen, auf die sich httpie für alle HTTP stützt und ohne die es nicht einmal existieren würde.

Bitte beachten Sie, dass dies in Anfragen erst in Version 3.0.0 behoben wird. Aufgrund möglicher Kompatibilitätsprobleme wird nicht einmal SSL_CERT_FILE unterstützt. https://github.com/kennethreitz/requests/pull/2903

Übrigens. Ich wollte nicht respektlos sein, ich dachte wirklich, er / sie trollt :) Ich habe alles getan, um eine Lösung für ein Problem zu finden, und jemanden, der nicht einmal zu dem Projekt beigetragen hat (ich habe die Mitwirkenden von HTTPie überprüft, weil ich war wirklich überrascht von solch einer feindlichen Reaktion) sagte mir im Grunde, ich solle den Mund halten: /

@luv Ich habe dir nicht

Schließlich sind Code-Beiträge nicht der einzige Beitrag zu einem Projekt. Wenn Sie alle Beiträge zu einem Projekt anzeigen möchten, können Sie ein Projekt wie @jkbrzt geantwortet, weil sie nicht die Zeit haben, die Entwicklung der Anfragen zu verfolgen. Wenn ich hier einen Fehler im Zusammenhang mit Anfragen sehe, antworte ich, weil er in 99% der Fälle bereits behoben ist. Zum Glück für @jkbrzt wurde ich zuvor als schlecht (und ein paar Mal schlechter) behandelt, sodass ich eine dickere Haut habe.

Als Randnotiz ist "sie" so viele Zeichen wie "er / sie" und weitaus allgemeiner anwendbar, da es verwendet werden kann, um sich auch auf eine einzelne Person zu beziehen.

Werden wir das beheben?

@jkbrzt Ich würde dies eine Funktion nennen, keinen Fehler. Es ist beabsichtigt, dass Requests unter Windows, * nixes und BSDs identisch funktioniert. Tatsächlich entfernen viele Systemverteilungen von Requests dieses Verhalten aktiv und verweisen auf den Systemzertifikatsspeicher / das Systemzertifikatspaket. Wenn Benutzer dieses Verhalten benötigen, können sie die Version von Requests verwenden, die von ihren Systemdistributoren mit HTTPie (und möglicherweise das vom System gepackte HTTPie) gepackt wurden.

Was "Fixing" betrifft, hängt dies von Ihrer Definition von Fixed ab. Dies ist eine Funktion, die zu Anfragen hinzugefügt wird. Ab diesem Zeitpunkt erhält HTTPie das Verhalten kostenlos. Wenn HTTPie dies stattdessen für eine höhere Priorität hält (was @jkbrzt nach eigenem Ermessen tun kann), können sie den Entwicklungsaufwand duplizieren, um eine Version zu erstellen, die dies früher tut.

Da Sie anscheinend Linux, @luv , verwenden, können Sie die Tatsache nutzen, dass Ihre Linux-Distribution mit ziemlicher Sicherheit eine Version von Requests enthält, die heute den Systemzertifikatsspeicher verwendet. Anfragen sind in jeder von mir überprüften Linux-Distribution enthalten, und so gut wie jede dieser Distributionen verwendet ihren Systemzertifikatsspeicher. Wenn dies nicht der Fall ist, sollten Sie möglicherweise einen Fehler beim Requests-Paketbetreuer dieser Distribution melden.

gleiches Problem mit HTTPie über apt installiert (Ubuntu 14.04lts)

@luv das ist überraschend, weil ich sicher weiß, dass Anfragen am 14.04 und 16.04 den Systemzertifikatsspeicher verwenden. Wie haben Sie Requests installiert?

Ich habe alle "Anfragen" - und "httpie" -Versionen gelöscht, um zu überprüfen, ob die Ubuntu-Verteilung von httpie verwendet wird, und Sie haben Recht, ich habe immer noch httpie von PyPI verwendet. Ubuntu httpie schlägt mit "ImportError: Name is_windows kann nicht importiert werden" fehl, was ein bekanntes Problem ist.

Ich glaube, ich habe vergessen, "pip3 uninstall" auszuführen und nur "pip uninstall" auszuführen, da ich Python3 verwenden musste, um SSL überhaupt zum Laufen zu bringen.

Ich entschuldige mich bei 761 Personen, um sie mit einer Beschreibung meines httpie-Setups zu "spammen".

Ich verwende Gentoo Linux, httpie-0.9.9 und request-2.18.4 (neueste Version in Gentoo), die systemweit vom Paketmanager installiert wurden, keine anderen Versionen installiert (ich habe nicht einmal pip installiert). Andere Tools (openssl s_client, sslclient, curl) erkennen das installierte lokale CA-Zertifikat und funktionieren einwandfrei, aber httpie schlägt fehl:

$ openssl s_client -quiet -connect localhost:8082                                              
depth=1 CN = Local CA home.lan
verify return:1
depth=0 CN = localhost
verify return:1
^C
$ http -v https://localhost:8082/                                                              

http: error: SSLError: HTTPSConnectionPool(host='localhost', port=8082): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),)) while doing GET request to URL: https://localhost:8082/

Soll ich etwas aktualisieren, damit es funktioniert?

@powerman Das ist eine passendere Frage für die Gentoo-Weiterverteiler dieser Pakete.

@ sigmavirus24 Warum ist das so? Meine Frage ist, ob diese Anfragen / httpie-Versionen die System-CA-Liste verarbeiten sollen oder nicht. Wenn ja, dann ist wahrscheinlich etwas auf meinem System falsch konfiguriert oder es liegt ein Fehler vor. Wenn nein, welche Version brauche ich, damit es funktioniert?

@powerman nichts hat sich geändert. Keiner unterstützt Ihre Systemzertifikat-Bundles, aber wenn Sie beide über den Paketmanager Ihrer Distribution installiert haben, haben sie wahrscheinlich die Software gepatcht, um sie zu verwenden. Wenn Sie die in Gentoo verfügbaren Pakete verwendet haben und diese keine Systemzertifikate verwenden, liegt ein Gentoo-Problem vor.

Ich möchte nur einen zusätzlichen Kommentar dazu hinzufügen: Ich verwende einen Proxy, der speziell dafür ausgelegt ist, dass bei SSL-Anforderungen ein sicherer Tunnel zwischen Ihnen und dem Proxy und dann ein weiterer zwischen dem Proxy und dem Ziel hergestellt wird. Auf diese Weise kann ich den Datenverkehr über meinen Proxy sicher überwachen, um sicherzustellen, dass niemand versucht, etwas Böses zu tun und es zu verbergen. Dies bedeutet leider, dass das Zertifikat, das httpie zurückerhält, nicht vertrauenswürdig ist (da es sich im Systemstamm befindet, httpie es jedoch nicht verwendet).

Ich kann das gleiche Problem tatsächlich unter NixOS reproduzieren.

4+ Jahre später ...