[PATCH] - HttpUtils - Support von HTTP Digest Authentifizierung

[Markus Bloch]

Hallo zusammen,

anbei ein Patch für HttpUtils um Digest-Authentifizierung zu unterstützen. Ich habe eine IP-Kamera, die keine Basic-Authentifizierung akzeptiert sondern nur Digest. Daher habe ich Digest nach RFC2069 & RFC2617 implementiert.

Dazu ist es notwendig die Antwort mit der Challenge zu empfangen und dann den Request samt Challenge-Response erneut zu schicken.  Dieses Schema habe ich auch für die Basic-Authentifizierung analog umgesetzt, damit nicht Passwörter einfach auf Dumm immer mitgesendet werden die dann jeder mit etwas Know-How einsehen kann. Der Server sagt nun, was er haben will (Basic/Digest) und der Request wird dann erneut mit der gewünschten Methode abgesetzt. Da kann man jetzt drüber streiten ob das gut ist oder sinnlose Zeit/Performance frisst.

Das Ergebnis wurde gegen einen eigenen Apache getestet (mit und ohne "qop"-Parameter), sowie gegen http://httpbin.org/ (funktioniert nur, wenn ein Cookie "fake=fake_value" mit gesendet wird)

Im Anhang gibt es einmal ein Diff, sowie eine volle HttpUtils.pm. Basic Authentifizierung funktioniert ebenfalls.

Viele Grüße

Markus

[rudolfkoenig]

Nach diesen Aenderungen wird bei gesetzten Benutzername/Passwort der erste Request ohne Authorization: im Header geschickt, damit es an der Antwort des Servers die gewuenschte Authorisierungsmethode (basic oder digest) rausgefunden werden kann.

Das fuehrt zur Verdoppelung des bisherigen Aufwandes bzw. Laufzeit bei Requests mit Basic-Auth. Normalerweise weiss mann, welche Authentifizierung gewuenscht wird, deswegen ist mir das zu teuer.

Um den Code lesbar zu halten, schlage ich vor diese Behandlung in einer separaten Funktion zu implementieren.

[Markus Bloch]

Nach diesen Aenderungen wird bei gesetzten Benutzername/Passwort der erste Request ohne Authorization: im Header geschickt, damit es an der Antwort des Servers die gewuenschte Authorisierungsmethode (basic oder digest) rausgefunden werden kann.

Das fuehrt zur Verdoppelung des bisherigen Aufwandes bzw. Laufzeit bei Requests mit Basic-Auth. Normalerweise weiss mann, welche Authentifizierung gewuenscht wird, deswegen ist mir das zu teuer.

Bei Digest muss man die Antwort des Servers abwarten um die Challenge-Daten zu erhalten. Da führt kein Weg dran vorbei.

Bei Basic geht es mir darum nicht gleich das Passwort auf den Präsentierteller zu legen.

Ob Digest oder Basic notwendig ist, wissen wir als Entwickler durchaus, aber ein normalsterblicher User in der Regel nicht. Der weis nur: "ich brauch ein Username/Passwort um die URL aufzurufen".

Alternativ würde ich sonst vorschlagen bei gesetzten User/Passwd den Basic-Header sofort im Request zu schicken. Sollte der Server ein 401 mit Digest-Challenge senden, dann den Request mit Challenge-Response erneut zu schicken.

Um den Code lesbar zu halten, schlage ich vor diese Behandlung in einer separaten Funktion zu implementieren.

OK, ich werde den Patch nochmal entsprechend ändern.

[Markus Bloch]

Anbei der Patch mit folgenden Anpassungen:

- Basic wird wieder mitgesendet (wie bisher auch)
- Sollte der Server Digest verlangen, wird der Header durch HttpUtils_DigestHeader() generiert und in $hash->{header} gesetzt/angehangen und neu abgesetzt
- Sollte dennoch ein 401 kommen, wird die Fehlermeldung "wrong authentication" zurückgemeldet.

Getestet mit Basic, Digest ohne qop sowie Digest mit qop und keine Authentifizierung.

Viele Grüße

Markus

[rudolfkoenig]

Habs mit ganz leichten Aenderungen eingecheckt.

[fhainz]

Hallo!

Anscheinend gibt es mit dem Patch ein Problem mit dem Pushbullet Modul (klick). Nach dem Aufruf bekomme ich diese Fehlermeldung.

Code Auswählen Erweitern

POST requests require a <code>Content-length</code> header.

Global verbose 5

Code Auswählen Erweitern

2015.10.29 19:57:11.204 5: Cmd: >set pushbullet message fsa<
2015.10.29 19:57:11.205 4: HttpUtils url=https://APIKEY: @api.pushbullet.com/v2/pushes
2015.10.29 19:57:11.406 4: https://APIKEY: @api.pushbullet.com/v2/pushes: HTTP response code 411
2015.10.29 19:57:11.406 4: HttpUtils https://APIKEY: @api.pushbullet.com/v2/pushes: Got data, length: 1564
2015.10.29 19:57:11.406 3: Something gone wrong
2015.10.29 19:57:11.406 5: Triggering pushbullet (1 changes)

Der Aufruf sieht so aus:

Code Auswählen Erweitern

$json = JSON->new->latin1->encode($jsonHash) if( $jsonHash );
   
  ($err,$data)    = HttpUtils_BlockingGet({
    url           => $url,
    method        => $method,
    header        => "Content-Type: application/json",
    data          => $json
  });
 

Ich kann mir das nicht so richtig erklären. Die content-lenght wird doch durch die HttpUtils gesetzt.
Jemand eine Idee?

Grüße

[betateilchen]

Es gibt noch mehr Probleme mit dem Patch.

http://forum.fhem.de/index.php/topic,43199

[rudolfkoenig]

Da offensichtlich Probleme gibt, ich sie aber weder reproduzieren kann, noch eine Idee habe wie ich sie fixen soll, und Digest nur von Markus verwendet wird, habe ich den Patch entfernt, und wieder die alte Version fuers update zur Verfuegung gestellt.

Es waere wichtig eine einfache Testmethode zur Verfuegung zu stellen, damit wir das Problem reproduzieren und fixen koennen.

[Markus Bloch]

@fhainz: Kann ich dir eine Version von HttpUtils.pm mit Digest-Implementierung und ein paar zusätzlichen Logausgaben geben, damit wir dem Problem auf die Spur kommen können?

Vielen Dank

Gruß
Markus

[fhainz]

Klar, kein Problem!

[Markus Bloch]

Hallo zusammen,

anbei eine Version von HttpUtils mit meiner Digest-implementierung sowie mit Logausgaben was an HTTP Daten gesendet und empfangen wurde.

Es wäre toll, wenn ihr diese mal ausprobieren könnt, mit den Geräten/URL's die nicht funktionieren. Damit ich sehen kann, wieso und weshalb.

Bitte darauf achten, dass in Zeilen mit "Authorization: Basic [XXX]" das [XXX] unkenntlich gemacht ist, da sich dahinter der Username+Passwort in BASE64 verbirgt, welches sich entschlüsseln lässt.

Vielen Dank

Gruß
Markus

[fhainz]

Hallo!

Hier die Logs

Code Auswählen Erweitern


2015.11.01 19:05:45.841 3: HttpUtils sent: POST /1/users/validate.json HTTP/1.0
Host: api.pushover.net
User-Agent: fhem
Content-Length: 72
Content-Type: application/x-www-form-urlencoded
2015.11.01 19:05:46.363 3: HttpUtils received: HTTP/1.1 200 OK
Date: Sun, 01 Nov 2015 18:05:46 GMT
Content-Type: application/json; charset=utf-8
Connection: close
Status: 200 OK
X-UA-Compatible: IE=Edge,chrome=1
ETag: "dd288bf11d7eaab2f9d198cd66e9e5dd"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 2c5a0ce7381a82ced16408f7daefc384
X-Runtime: 0.009382
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000

{"status":1,"group":0,"devices":["iPad","iPhone"],"request":"2c5a0ce7381a82ced16408f7daefc384"}
2015.11.01 19:06:06.795 3: HttpUtils sent: POST /v2/pushes HTTP/1.0
Host: api.pushbullet.com
User-Agent: fhem
Authorization: Basic [XXX]

Content-Type: application/json
Content-Length: 61

2015.11.01 19:06:06.842 3: HttpUtils received: HTTP/1.0 411 Length Required
Content-Type: text/html; charset=UTF-8
Content-Length: 1564
Date: Sun, 01 Nov 2015 18:06:06 GMT
Server: GFE/2.0

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 411 (Length Required)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>411.</b> <ins>That's an error.</ins>
  <p>POST requests require a <code>Content-length</code> header.  <ins>That's all we know.</ins>



Grüße

[Markus Bloch]

Vielen Dank. Fehler gefunden.

Grund war der Aufruf von encode_base64. Ich hatte den zweiten Parameter nicht gesetzt, so wie es bisher auch war. Bei meinem Perl scheint hier "" Standard zu sein, bei anderen ist es "\n"

alt:

Code Auswählen Erweitern

  $hdr .= "Authorization: Basic ".encode_base64($hash->{auth})."\r\n"

neu:

Code Auswählen Erweitern

  $hdr .= "Authorization: Basic ".encode_base64($hash->{auth}, "")."\r\n"

Anbei der korrigierte Patch.

Gruß
Markus

[fhainz]

Funktioniert wieder! Danke!

[rudolfkoenig]

Habe den Patch ohne Aenderungen uebernommen und eingecheckt.

[Markus Bloch]

Hallo Rudi,

in http://forum.fhem.de/index.php/topic,48112.msg397788.html#msg397788 und http://forum.fhem.de/index.php/topic,46627.msg383571.html#msg383571 zeigt sich, dass die Funktion md5_hex() nicht verfügbar ist.

Dazu muss in HttpUtils.pm die Zeile 9 geändert werden in:

Code Auswählen Erweitern

use Digest::MD5 qw(md5_hex);

Kannst du das bitte ändern?

Vielen Dank

Gruß
Markus

[rudolfkoenig]

Habs gemacht.
Kannst du bitte erklaeren, warum das so besser ist?
Ich habe nur eine wage Theorie, und keine Zeit es zu verifizieren.

[Markus Bloch]

Wenn man bei use ... nicht angibt, welche Funktionen man in den aktuellen Namespace importieren möchte, stehen die Funktionen nur im ursprünglichen Namespace zur Verfügung (in dem Falle Digest::MD5::md5_hex(..) ).

Bei mir tritt dieser Fehler nicht auf, da ein Import auf den Namespace "main" bereits durch andere Module, die bei mir geladen sind, vollzogen wurde.

Gruß
Markus

[Loredo]

Wie genau muss ich denn Digest Auth jetzt anwenden?
Wenn ich es richtig verstehe, dann kann ich einfach wie bei BasicAuth die URL http://user:pass@server/path verwenden und in der Annahme, dass der Server in seiner Antwort dann Digest Auth fordert, wird die selbe Anfrage dann einfach nochmal als DigestAuth geschickt? Auch wenn das "teuer" ist, wäre das zunächst einmal ein Ansatz. Wie würde ich denn direkt ohne Umwege eine Digest Auth Anfrage senden? Und: Wie sollte ich das Session Handling machen? Kann ich dazu einfach etwas aus der ersten Antwort im Device Hash merken und beim nächsten Mal wieder mit übergeben?


Ich werde aus all dem leider nicht so ganz schlau bisher... :-/

[Markus Bloch]

Hallo Loredo,

Digest kann man nicht proaktiv von vornherein "einfordern" vom Server aufgrund der Art und Weise wie Digest funktioniert. Der Client ruft eine Seite auf und der Server fordert vom Client ein sich zu authentifizieren. Der Server teilt in diesem Zuge mit, dass das Verfahren "Digest" zu nutzen ist samt dem Nonce den der Client für die Berechnung der Challenge-Response benötigt. Der Client ist bei der initialen Authentifizierung auf die Antwort des Servers angewiesen um die Challenge-Response zu generieren und kann nicht bereits proaktiv eine Digest Authentifizierung vorab durchführen ohne den Nonce zu kennen.

Sobald der Client sich einmalig authentifiziert hat ist es vom Standard her vorgesehen alle weiteren Anfragen direkt mit Digest zu authorisieren. Dabei muss je nach Quality-Of-Protection ("qop") der Digest bei jedem folgenden Request neu berechnet werden, da ein Nonce-Count bei jedem Request um 1 erhöht wird, welcher in die Berechnung der Antwort mit einfließt. Dadurch können alle weiteren Anfragen an den Server direkt authentifiziert werden, da die jeweiligen Nonce (server-, als auch clientseitig) bekannt sind.

HttpUtils.pm geht hierbei etwas anders vor. Sobald man einen HTTP-Request mit Authentifizierung durchführt wird immer proaktiv eine Basic-Authentifizierung durchgeführt. Sollte der Server auf Digest bestehen, würde in der Antwort (401 Authentication Required) ein entsprechender WWW-Authenticate-Header enthalten sein, der eine Digest-Authentifizierung einleitet. HttpUtils wird darauf dann eine entsprechende Challenge-Response generieren und den Request erneut durchführen.

Die aktuelle Implementierung erlaubt es aktuell nicht, die Authentifizierung im Rahmen von Keep-Alive aufrecht zu erhalten. Dazu müssten entsprechende Daten im Parameter-Hash gespeichert werden, wodurch HttpUtils.pm bei allen folgenden Requests entsprechend der bekannten Nonce-Daten immer einen neuen Digest-Header erzeugt um alle weiteren Requests zu authentifizieren.

Viele Grüße

Markus

[Loredo]

Hallo Markus,


danke für die Erläuterung.


Ich weiß leider nicht, welche Abwandlung genau vom Gerät verwendet wird, da ich es auch selbst nicht besitze.
Ich habe in 70_PHTV lediglich die Möglichkeit eingebaut Username+Passwort mit zu hinterlegen, welches sich die User zuvor beim Pairing separat erstellt haben. Aber offenbar funktioniert die Abfrage mit diesen dann hinterher nicht.


Mal sehen, vielleicht liefert ja einer der User noch ein Logfile nach...




Gruß
Julian

[Loredo]

Hi Markus,

wir sind nun soweit, dass wir das Pairing soweit im Griff haben und nun eigentlich mit gültigen Zugangsdaten authentifizieren würden.
Allerdings scheint das nicht zu funktionieren.

Ich habe daraufhin in HttpUtils einmal die request und response Header beim Zugriff auf einen HTTP Digest Auth Beispielserver mitgeloggt:

Code Auswählen Erweitern


2017.02.20 10:03:22.187 4: HttpUtils url=https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd
2017.02.20 10:03:22.557 4: https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd: HTTP request header:
GET /digest-auth/auth/user/passwd HTTP/1.1
Host: httpbin.org
User-Agent: fhem
Connection: Close
Authorization: Basic dXNlcjpwYXNzd2Q=
Content-Type: application/json

2017.02.20 10:03:22.671 4: https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd: HTTP response header:
HTTP/1.1 401 UNAUTHORIZED
Server: nginx
Date: Mon, 20 Feb 2017 09:03:22 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: close
WWW-Authenticate: Digest nonce="65bb11ffe99d63178408c558c26699e0", opaque="099659c62506db1df8051a741085637f", realm="me@kennethreitz.com", qop=auth
Set-Cookie: fake=fake_value
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
2017.02.20 10:03:22.672 4: https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd: HTTP response code 401
2017.02.20 10:03:22.672 4: HttpUtils url=https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd
2017.02.20 10:03:23.059 4: https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd: HTTP request header:
GET /digest-auth/auth/user/passwd HTTP/1.1
Host: httpbin.org
User-Agent: fhem
Connection: Close
Content-Type: application/json
Authorization: Digest nonce="65bb11ffe99d63178408c558c26699e0", response="ce9327f84102be913f67f7615b46822a", uri="/digest-auth/auth/user/passwd", realm="me@kennethreitz.com", nc=00000001, opaque="099659c62506db1df8051a741085637f", cnonce="37d7694490628422aec92a9819f37b08", username="user", qop="auth"

2017.02.20 10:03:23.264 4: https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd: HTTP response header:
HTTP/1.1 401 UNAUTHORIZED
Server: nginx
Date: Mon, 20 Feb 2017 09:03:23 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: close
WWW-Authenticate: Digest nonce="d34a64f81d3894e41f57baf9ef86ac36", opaque="b4fdc941e867d9037097bb220abdff62", realm="me@kennethreitz.com", qop=auth
Set-Cookie: fake=fake_value
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
2017.02.20 10:03:23.264 4: https://user:passwd@httpbin.org:443/digest-auth/auth/user/passwd: HTTP response code 401


Es scheint so, als wenn auch hier die Authentifizierung nicht funktionieren würde. Im Browser funktioniert es allerdings.
Hast du eine Idee, was hier fehlt?


Gruß
Julian

[Markus Bloch]

Bei httpbin.org funktioniert dies explizit nicht, weil das gesetzte Cookie bei der Authentifizierung nicht durch FHEM mitgeschickt wird. Hier muss man explizit das Cookie mitsenden, damit der Request authorisiert wird.

Gruß
Markus

[Loredo]

Hm, true 

[Loredo]

Hi Markus,


also der Server schickt wohl auf eine Basic-Auth Anfrage keinen 401 Fehler, sondern einen permanenten 403 Fehler (siehe hier). Soweit ich das verstehe ist das eigentlich kein RFC konformes Verhalten, ist aber wohl nunmal so...


Ich werde einmal schauen diesen Teil so zu erweitern, man im Hash angeben kann, ob bei der ersten Anfrage Basic-Auth verwendet werden soll oder nicht. Ich gehe davon aus, dass dann jeder Webserver dann auch korrekt einen 401 zurückschickt und der Rest dann wie gehabt funktionieren kann.




Gruß
Julian

[Loredo]

Hallo Rudi,


anbei ein klitzekleiner Patch, damit man als Modulautor explizit sagen kann, dass HTTP Digest Auth verwendet werden soll.
Es wäre prima, wenn du den Patch übernehmen könntest.




Danke & Gruß
Julian

[rudolfkoenig]

Eingecheckt

[Markus Bloch]

Hallo Rudi,

im Rahmen von https://forum.fhem.de/index.php/topic,74872.0.html wurde ein Problem mit der Digest-Implementierung in HttpUtils.pm gefunden. Anbei ein Patch zur Behebung mit der Bitte um Änderung.

Code Auswählen Erweitern

Index: FHEM/HttpUtils.pm
===================================================================
--- FHEM/HttpUtils.pm   (revision 14892)
+++ FHEM/HttpUtils.pm   (working copy)
@@ -545,7 +545,7 @@
   my ($hash, $header) = @_;
   my %digdata;

-  while($header =~ /(\w+)="?([^"]+?)"?(?:,\s+|$)/gc) {
+  while($header =~ /(\w+)="?([^"]+?)"?(?:\s*,\s*|$)/gc) {
     $digdata{$1} = $2;
   }

Viele Grüße

Markus

[rudolfkoenig]

Danke, habs eingecheckt.