LWP und wget Option
Ferry Bolhar
das Tool wget (Web-Client) bietet eine Option --no-check-certificate, mit
der man den Check server-seitiger Zertifikate unterdr�cken kann. Wenn diese
Option gesetzt ist, kann ich eine URL, bei der ansonsten "401 Access Denied"
zur�ckkommt, fehlerfrei abfragen.
Ich habe eine Testumgebung zum Abfragen von Web-Seiten und verwendet dazu
LWP. Ich br�uchte jetzt eine M�glichkeit, das Verhalten von
wget --no-check-certificate in LWP nachzubilden. Oder ist das spezielle
Logik in wget, die ich nachprogrammieren m�sste? Falls ja, wie?
Danke im Voraus f�r alle Antworten & LG,
Ferry
--
Ing. Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolh...@wien.gv.at
Wolf Behrenhoff
> Hallo,
>
> das Tool wget (Web-Client) bietet eine Option --no-check-certificate, mit
>
> Ich habe eine Testumgebung zum Abfragen von Web-Seiten und verwendet dazu
Hallo Ferry,
hast du Net::SSLeay installiert? Zumindest wenn das installiert ist,
kann ich die https-Seiten ohne Zertifikatcheck lesen - einen Check des
Zertifikats habe ich dagegen noch nicht gemacht.
Wenn SSLeay installiert ist, kannst du einfach schreiben:
perl -e 'use LWP::Simple; getprint("https://...")'
Wolf
Peter J. Holzer
> das Tool wget (Web-Client) bietet eine Option --no-check-certificate, mit
> der man den Check server-seitiger Zertifikate unterdr�cken kann. Wenn diese
> Option gesetzt ist, kann ich eine URL, bei der ansonsten "401 Access Denied"
> zur�ckkommt, fehlerfrei abfragen.
Das ist eigenwillig. Wenn der Client Zertifikate pr�ft und der Server
kein passendes Zertifikat anbieten kann, dann schickt der Client gar
keinen Request. Also kann der Server auch nicht antworten (worauf auch?)
und schon gar nicht "401 Access Denied". Das ist entweder ein Bug in
wget oder in Deiner Schilderung fehlt ein wichtiges Detail.
> Ich habe eine Testumgebung zum Abfragen von Web-Seiten und verwendet dazu
> LWP. Ich br�uchte jetzt eine M�glichkeit, das Verhalten von
> wget --no-check-certificate in LWP nachzubilden. Oder ist das spezielle
> Logik in wget, die ich nachprogrammieren m�sste? Falls ja, wie?
Pr�ft LWP denn Zertifikate? Das w�re mir noch nicht aufgefallen, und ich
bin mir ziemlich sicher, dass ich es im Lauf der Jahre immer wieder f�r
Websites mit self-signed certificates, unbekannten CAs etc. eingesetzt
habe.
hp
Manuel Reimer
> hast du Net::SSLeay installiert? Zumindest wenn das installiert ist,
> kann ich die https-Seiten ohne Zertifikatcheck lesen - einen Check des
> Zertifikats habe ich dagegen noch nicht gemacht.
LWP nutzt Net::SSLeay nicht, bzw. nur �ber den Umweg IO::Socket::SSL.
Du meinst wohl Crypt::SSLeay?
CU
Manuel
--
Alle wollen zur�ck zur Natur - aber keiner zu Fu�
Der Mensch erfand Maschinen, um sich damit die Arbeit zu erleichtern.
Nur leider hat er vergessen, rechtzeitig damit aufzuh�ren...
Beitr�ge mit *X-No-Html Header* kann ich weder lesen, noch beantworten!
Wolf Behrenhoff
> Wolf Behrenhoff wrote:
>> hast du Net::SSLeay installiert? Zumindest wenn das installiert ist,
>> kann ich die https-Seiten ohne Zertifikatcheck lesen - einen Check des
>> Zertifikats habe ich dagegen noch nicht gemacht.
>
> LWP nutzt Net::SSLeay nicht, bzw. nur �ber den Umweg IO::Socket::SSL.
> Du meinst wohl Crypt::SSLeay?
Hm, vermutlich ja ;-)
Warum hei�en die auch so �hnlich?
Wolf
Ferry Bolhar
> hast du Net::SSLeay installiert? Zumindest wenn das installiert ist, kann
> ich die https-Seiten ohne Zertifikatcheck lesen - einen Check des
> Zertifikats habe ich dagegen noch nicht gemacht.
Ja, Crypt::SSLeay (das ist es, was du meinst) ist installiert.
Ich kann auch problemlos mittels client-seitigem Zertifikat auf andere
https://... Verweise zugreifen.
Nur der Check server-seitiger Zertifikate funktioniert nicht.
Ferry Bolhar
> Das ist eigenwillig. Wenn der Client Zertifikate pr�ft und der Server
> kein passendes Zertifikat anbieten kann, dann schickt der Client gar
> keinen Request. Also kann der Server auch nicht antworten (worauf auch?)
> und schon gar nicht "401 Access Denied". Das ist entweder ein Bug in
> wget oder in Deiner Schilderung fehlt ein wichtiges Detail.
Um ein serverseitiges Zertifikat pr�fen zu k�nnen, muss der Client ja
erstmal daf�r einen Request an den Server schicken, damit er von diesem
das Zertifikat �bermittelt bekommt.
Vielleicht hilft es, wenn ich den wget Befehl und dessen Ausgabe poste:
$ wget --user=... --password=... https://ntlm.gs.magwien.gv.at/...
ERROR: Certificate verification error for ntlm.gs.magwien.gv.at:
unable to get local issuer certificate
To connect to ntlm.gs.magwien.gv.at insecurely, use
`--no-check-certificate'.
Unable to establish SSL connection.
$ wget --user=... --password=... --no-check-certificate https://...
WARNING: Certificate verification error for ntlm.gs.magwien.gv.at:
unable to get local issuer certificate
HTTP request sent, awaiting response... 401 Access Denied
Reusing existing connection to ntlm.gs.magwien.gv.at:443.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to ntlm.gs.magwien.gv.at:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 296 --.--K/s
08:09:46 (1.95 MB/s) - `x.out' saved [296]
In x.out findet sich der erwartete Inhalt.
> Pr�ft LWP denn Zertifikate? Das w�re mir noch nicht aufgefallen, und ich
> bin mir ziemlich sicher, dass ich es im Lauf der Jahre immer wieder f�r
> Websites mit self-signed certificates, unbekannten CAs etc. eingesetzt
> habe.
Ja, das ist es eben - ich vermute, dass so eine Pr�fung nicht durchgef�hrt
wird. LWP (eigentlich Crypt::SSLeay) unterst�tzt mittels der
HTTPS_CA_DIR und HTTPS_CA_FILE Environment Variable
CA Zertifikate, was wir an anderer Stelle auch verwenden. Dass es
Server-Zertifikate _pr�ft_, w�re mir auch neu.
Aber hier geht es darum, dieser Pr�fung zu umgehen, d.h., sie soll ja gar
nicht erst stattfinden. Ich m�sste eben wissen, was genau wget macht/nicht
macht, wenn die Option --no-check-certificate gesetzt ist.
Mit LWP bekomme ich bei demselben Request als Antwort nur
401 Access Denied
zur�ck. d.h. dieselbe Antwort, die wget auch beim ersten Versuch erh�lt.
Wie man aber in der obigen Ausgabe sieht, macht wget dann trotzdem
noch weiter; es schickt insgesamt drei Requests, von denen der dritte
dann funktioniert. Nur: _WAS_ schickt es da?
Peter J. Holzer
> "Peter J. Holzer":
>
>> Das ist eigenwillig. Wenn der Client Zertifikate pr�ft und der Server
>> kein passendes Zertifikat anbieten kann, dann schickt der Client gar
>> keinen Request. Also kann der Server auch nicht antworten (worauf auch?)
>> und schon gar nicht "401 Access Denied". Das ist entweder ein Bug in
>> wget oder in Deiner Schilderung fehlt ein wichtiges Detail.
>
> Um ein serverseitiges Zertifikat pr�fen zu k�nnen, muss der Client ja
> erstmal daf�r einen Request an den Server schicken, damit er von diesem
> das Zertifikat �bermittelt bekommt.
Du bringst hier die Protokoll-Ebenen durcheinander. Das Zertifikat wird
w�hrend des SSL-Handshakes �bertragen. HTTP-Requests k�nnen erst
�ber die SSL-Verbingung geschickt werden, wenn diese steht.
> Vielleicht hilft es, wenn ich den wget Befehl und dessen Ausgabe poste:
Ja.
> $ wget --user=... --password=... https://ntlm.gs.magwien.gv.at/...
>
> ERROR: Certificate verification error for ntlm.gs.magwien.gv.at:
> unable to get local issuer certificate
> To connect to ntlm.gs.magwien.gv.at insecurely, use
> `--no-check-certificate'.
> Unable to establish SSL connection.
Wie Du hier siehst, bricht er w�hrend des SSL-Handshakes ab und kommt
gar nicht dazu, einen HTTP-Request zu senden.
> $ wget --user=... --password=... --no-check-certificate https://...
>
> WARNING: Certificate verification error for ntlm.gs.magwien.gv.at:
> unable to get local issuer certificate
Hier kann der Client das Zertifikat (das er sehr wohl vom Server
bekommen hat - das ist im SSL-Protokoll mandatory) zwar auch nicht
verifizieren, sieht das aber nicht als fatal an und macht trotzdem
weiter.
> HTTP request sent, awaiting response... 401 Access Denied
Der HTTP-Request wurde gesendet, als Antwort kommt "401 Access Denied"
> Reusing existing connection to ntlm.gs.magwien.gv.at:443.
> HTTP request sent, awaiting response... 401 Unauthorized
Also probiert er es noch einmal, vermutlich mit etwas anderen Parametern
und bekommt wieder "401 Access Denied".
> Reusing existing connection to ntlm.gs.magwien.gv.at:443.
> HTTP request sent, awaiting response... 200 OK
Und dann noch einmal, und jetzt bekommt er "200 OK".
Worin sich diese drei Requests unterscheiden, w�re jetzt nat�rlich
interessant. Ich vermute, dass da verschiedene Arten der
Authentifizierung durchprobiert wurden: Gar keine, Basic, MD5, NTLM, ...
Leider scheint wget keine Option zu haben, um die Request-Header zu
dumpen.
>> Pr�ft LWP denn Zertifikate? Das w�re mir noch nicht aufgefallen, und ich
>> bin mir ziemlich sicher, dass ich es im Lauf der Jahre immer wieder f�r
>> Websites mit self-signed certificates, unbekannten CAs etc. eingesetzt
>> habe.
>
> Ja, das ist es eben - ich vermute, dass so eine Pr�fung nicht durchgef�hrt
> wird. LWP (eigentlich Crypt::SSLeay) unterst�tzt mittels der
> HTTPS_CA_DIR und HTTPS_CA_FILE Environment Variable
> CA Zertifikate, was wir an anderer Stelle auch verwenden. Dass es
> Server-Zertifikate _pr�ft_, w�re mir auch neu.
>
> Aber hier geht es darum, dieser Pr�fung zu umgehen, d.h., sie soll ja gar
> nicht erst stattfinden.
Du widersprichst Dir. Oben hast Du noch geschrieben "ich vermute, dass
so eine Pr�fung nicht durchgef�hrt wird". Wenn sie ohnehin nicht
durchgef�hrt wird, dann findet sie ja nicht statt - was willst Du dann
�ndern?
> Ich m�sste eben wissen, was genau wget macht/nicht
> macht, wenn die Option --no-check-certificate gesetzt ist.
>
> Mit LWP bekomme ich bei demselben Request als Antwort nur
>
> 401 Access Denied
Also das gleiche wie bei wget --no-check-certificate. Die Pr�fung wurde
nicht durchgef�hrt, LWP sendet den Request an den Server und bekommt
ebenso wie wget einen 401 Response zur�ck. Das ist ganz exakt das
gleiche Verhalten, also ist das Zertifikat nicht das Problem.
Das Problem ist, dass LWP dann im Gegensatz zu wget abbricht und nicht
solange verschiedene Authentifikationsmethoden durchprobiert, bis eine
funktioniert. Das kann entweder daran liegen, dass es keine weiteren
beherrscht, oder daran, dass Du daf�r nicht die notwendigen Parameter
�bergeben hast (ich habe LWP nie mit was anderem als Basic verwendet -
keine Ahnung, ob es weitere Methoden beherrscht, und wenn ja, wie man
die verwendet).
Die daf�r notwendigen Informationen m�ssten aber im Header der Response
stehen, wenn Du Dir den ausgeben l�sst, siehst Du vermutlich klarer.
hp