No-Ip.com DNS Group update

[night4awk]

Du musst Username und Passwort aus der url weglassen, das ergänzt die Fritzbox automatisch.

Das funktioniert genauso wenig...

Nochmal zur Erinnerung:
Folgender String funktioniert, aber eben nicht mehr, wenn ich versuche <b64>-Tags einzufügen:

https://dynupdate.no-ip.com/dns?username=<username>&password=<pass>&hostname=<domain>&ip=<ipaddr>&group=groupname

 

[PeterPawn]

Kannst Du noch einmal klarstellen, was denn nun mit der Base64-kodierten URL nicht klappt?

Wenn das Zusammenstellen eines "ordentlichen" Requests nicht funktionieren würde, läge das Problem in der FRITZ!Box.

Wenn no-ip.com mit einer Base64-kodierten URL (oder Base64-kodierten QueryStrings) nichts anfangen kann, kann ja die FRITZ!Box nichts dafür.

Was passiert denn, wenn Du bei no-ip.com mit einer "handgefertigten" URL mit irgendwelchen B64-kodierten Parametern ein Update versuchst?

Wenn das auch nicht geht, ist wohl der Request an sich falsch.

Wo siehst Du denn in der Hilfe-Seite von no-ip.com die Möglichkeit entdeckt, eine Base64-kodierte URL zu verwenden? Ich finde da nichts dazu ... vielleicht bin ich aber auch nur zu blöd. Also bitte den Link inkl. des Zitats, wenn das kein "anchor" auf der Zielseite ist.

Die <b64>-Tags des FRITZ!OS haben jedenfalls nichts mit einer Base64-Kodierung im "Authorization"-Header eines HTTP-Requests zu tun ... da hättest Du etwas fundamental falsch verstanden, wenn Du das annehmen solltest.

Vielleicht kannst Du ja noch einmal genau beschreiben, was Du mit

No-IP.com sagst selbst, dass Base64 unterstützt wird.

nun eigentlich meinst ... das ist - sorry für die deutlichen Worte - im Moment "etwas wirr".

Der Bezug zu Base64 auf der von Dir verlinkten no-ip.com-Seite heißt jedenfalls nicht, daß irgendwo in der URL die Parameter "username" und/oder "password" auftauchen sollen und diese dann Base64-kodiert sein sollen. Eigentlich sind diese zwei Parameter bei denen so gar nicht beschrieben (die Angabe am Beginn der URL - also vor dem Host - hat eine vollkommen andere Funktion und diese Syntax funktioniert tatsächlich bei neuerer Firmware nicht mehr ... hatten wir an anderer Stelle schon), wie Du sie in #21 verwendest.

Die Base64-Kodierung für den Authorization-Header macht der ddnsd des FRITZ!OS schon von alleine richtig, wenn Du das nicht glaubst, mußt Du eben mal einen HTTP-Request (nicht HTTPS) mitschneiden.

Mein Eindruck: Du bringst da einiges mächtig durcheinander.

Meine Frage: Was willst Du eigentlich erreichen?

Wenn es nur darum geht, daß die Daten nicht im Klartext übertragen werden, dann reicht die Verwendung von HTTPS ja bereits aus und die korrekte URL sieht (nach den Angaben in der von Dir verlinkten Seite) dann so aus:

https://dynupdate.no-ip.com/nic/update?hostname=<domain>&myip=<ipaddr>

Der myip-Parameter kann/muß entfallen (inkl. dem Ampersand davor), wenn die Box hinter einem anderen Router in einer Kaskade betrieben wird und ihrerseits nur eine interne Adresse hinter diesem Router kennt.

Wenn Du unbedingt das Pendant zum AVM-Eintrag in der ar7.cfg verwenden willst als URL, solltest Du vielleicht auch noch den richtigen Port aus der ar7.cfg in der URL angeben und die sähe dann am Ende so aus:

http://dynupdate.no-ip.com:8245/ducupdate.php?update=<b64>username=<username>&pass=<pass>&h[]=<domain>&ip=<ipaddr></b64>

Ob allerdings no-ip.com auf diesem Port überhaupt TLS-Verbindungen akzeptiert (und Du dort eventuell auch HTTPS verwenden könntest) oder nicht, kann (und will) ich Dir auch nicht sagen ... der AVM-Client macht dort jedenfalls nur HTTP-Updates. Für mich sieht das eben wie ein komplett anderes Interface aus ... ob das nun neuer oder älter oder "nur für zertifizierte Hersteller" oder irgendetwas anderes ist, bleibt ja auch offen.

Ansonsten ist es sicherlich bei allen diesen no-ip.com-URLs so, daß der vermutlich dahinterliegende PHP-Code irgendwelche Query-Parameter mit nicht benötigten Namen einfach nur still ignoriert, weil er sie gar nicht erst zur Kenntnis nimmt - so z.B. auch Deine zusätzlichen Angaben in der URL in #21, die ja nach Deiner Angabe funktioniert. Das dürfte in der Form auch nur für das FRITZ!Box-GUI gelten, dann wenn Du diese URL von Hand im Browser verwendest, kommt entweder direkt 401 oder der Browser fragt vorher noch bei Dir den Benutzernamen und das Kennwort ab, bevor er einen zweiten Anlauf unternimmt. Wenn meine Vermutung stimmt, kannst Du dem auch beliebige andere unbekannte Parameter mit auf den Weg geben.

 

[night4awk]

Der eigentliche Sinn ist, dass ich noch einen gefritzen Speedport W 701V habe, der beim DDNS-Update kein https unterstützt.
Und daher wollte ich hier zumindest eine Base64-Codierung einfügen.

Früher war ich bei ChangeIP.com und hier hatte es mit diesem benutzerdefinierten String funktioniert:

http://nic.ChangeIP.com/nic/update?<b64>u=<username>&p=<pass></b64>&hostname=<domain>&myip=<ipaddr>&set=1

Und jetzt wollte ich das auch bei NO-IP.com machen.
Aber vielleicht unterstützt das eben NO-IP.com nicht wie ich mir das vorstelle.

Da ich bei NO-IP.com ein "Group Udpate" machen will, muss ich ja die benutzerdefinierte Eingabe nutzen, da bei der Vorgabe der FritzBox zu NO-IP.com kein "group name" abgefragt wird.

 

[PeterPawn]

Ich komme mir zwar etwas veralbert vor:

Ich habe auf meiner FritzBox 7390 folgenden String erfolgreich getestet

Meine FritzBox läuft übrigens auf v6.30.

Der eigentliche Sinn ist, dass ich noch einen gefritzen Speedport W 701V habe, der beim DDNS-Update kein https unterstützt.

... aber ehe hier am Ende etwas Falsches stehenbleibt, was dann spätere Leser wieder verwirrt, fasse ich das noch einmal zusammen. Du (@night4awk) solltest Dich in "Literatur" zum HTTP-Protokoll vertiefen und "ja", nach der Dokumentation bei no-ip.com unterstützt man das dort in einer passenderen Form - solange man nicht zwischen der "HTTP authorization" und den Credentials für einen DynDNS-Account unterscheiden muß und/oder will.

Bis zur Version 06.30 (m.W. sogar einschließlich, lege ich aber jetzt die Hand nicht für ins Feuer) versteht die AVM-Firmware (mithin auch das, was auf einem W701V mit AVM-Firmware laufen würde) die Syntax mit der Angabe von Benutzernamen und Kennwort innerhalb einer entsprechenden URI (RFC 3986, Punkt 3.2). Nachteil dieser Form ist es, daß Benutzername und Kennwort dann direkt angegeben werden müssen (zumindest bei meinem letzten Test in dieser Richtung), weil offenbar die Ersetzungen der "<irgendwas>"-Werte erst nach dem Aufsplitten der URI in ihre Bestandteile erfolgen und dann wohl nur auf den Teil nach dem Servernamen angewendet werden. Diese direkt angegebenen Daten stehen dann wieder im Klartext in einem Export-File, weil so eine URI nicht verschlüsselt gespeichert ist - ich rate mal wild und sage, daß AVM deshalb dieses Format der URI (mit "userinfo subcomponent") abgeschafft hat.

Auf diese Weise in einer URI angegebene Credentials werden schon automatisch nicht wirklich in der URL eines HTTP-Requests übermittelt (also als Parameter im "GET"-Request), sondern in einem entsprechenden "Authorization"-Header im Rahmen des HTTP-Protokolls, spätestens wenn der Server das erste Mal mit "401 Unauthorized" geantwortet hat, weil er eine Anmeldung erwartet.

Es gibt zwei standardisierte Verfahren an dieser Stelle (RFC 2617), das Microsoft-Verfahrem der "ntlm auth" ist proprietär und verwendet ebenfalls (wie "digest auth") einen Hash-Wert (früher sogar "unsalted" wie bei der ersten Implementierung des "LAN managers" von IBM/Microsoft), "ntlm auth" wird auf der Client-Seite i.d.R. nur vom Internet Explorer und anderer Windows-Software (unter Verwendung der winhttp.dll) unterstützt. Auf der Serverseite gibt es allerdings auch für den Apache2 entsprechende Implementierungen, damit der in Intranets mit Windows ordentlich zusammenarbeiten kann. Aber das nur der Vollständigkeit halber ...

Zurück zum RFC 2617 ... bei "basic auth" werden der Benutzername und das Kennwort - durch einen Doppelpunkt getrennt (deshalb darf auch der Benutzernamen keinen Doppelpunkt enthalten, das Kennwort (theoretisch) allerdings schon) - mit Base64 kodiert und das Ergebnis landet nach dem Schlüsselwort "basic" im Text des Headers. Das ist also bereits eine Base64-kodierte Übertragung dieser Daten, wobei es kein Problem ist, diese zurückzugewinnen.

Bei "digest auth" sendet der Server mit der Aufforderung zur Authentifizierung einen zufälligen Wert (nonce), der zusammen mit dem Benutzernamen und dem Kennwort durch eine kryptographische Hash-Funktion gejagt wird und das Ergebnis dieser Operation sind dann bei einem MD5-Hash (der Server gibt bei der Aufforderung zur Authentifizierung auch das Hash-Verfahren vor, ohne Angabe ist es eben MD5) 128 Bit == 16 Byte, die als 32 ASCII-Zeichen aus dem Vorrat 0-9 und A-F jeweils für ein Halbbyte (vulgo "hexadezimale Darstellung", aber ohne irgendwelche Späße wie "0x" davor) dargestellt werden. Da aus diesem Hash-Wert nicht mehr auf den Ausgangswert geschlossen werden kann (der auch noch mittels des "nonce"-Werts "gesalzen" (engl. "salted") ist, also einen weiteren zufälligen Faktor enthält), müssen für dieses Verfahren auf dem Server die Daten des Benutzers (Name und Kennwort) allerdings im Klartext vorliegen bzw. in einer Form, aus der wieder dieser Klartext gewonnen werden kann ... denn der Server muß nun seinerseits ebenfalls hingehen und genau dasselbe Verfahren wie der Client anwenden, um aus dem bekannten Benutzernamen, dem Kennwort und dem "nonce"-Wert seinerseits diesen Hash-Wert zu berechnen. Stimmen diese beiden Werte überein, hatte der Client die richtigen Daten als Ausgangswert und ist wohl der Berechtigte.

Diese "digest auth" unterstützt der DynDNS-Client des FRITZ!OS offenbar nicht bzw. nicht richtig, denn die passenden Zeichenketten wären sogar vorhanden im Binary ... aber offenbar (der Mitschnitt ist schon etwas länger her) sendet der Client von Beginn an (auch ohne vorherige Antwort "401" vom Server, die bei "digest auth" aber unbedingt benötigt wird, weil man sonst keinen "nonce"-Wert hat) einen Header mit "basic auth" mit und schließt dann aus einer 401-Antwort nicht auf das falsche Verfahren, sondern auf die falschen Credentials. Mir ist es jedenfalls auch noch nicht gelungen (bis einschließlich 06.30), die FRITZ!Box (weder als "benutzerdefinierter" Eintrag noch durch Hinzufügen eines eigenen Providers) zur Verwendung von "digest auth" in Kombination mit einem entsprechend konfigurierten Apache2-Server zu bewegen und der Quelltext des AVM-DynDNS-Clients ist "closed source".

Irgendwelche zusätzlichen Kopfstände mit irgendwelchen "<b64>"-Tags in der URL sind bei no-ip.com also gar nicht notwendig, die Credentials werden immer Base64 kodiert in einem "Authorization"-Header übertragen, solange sie nicht als "query"-Komponente der URI (RFC 3986, Punkt 3.4) angegeben werden, was nach der Dokumentation bei no-ip.com gar nicht erfolgen kann (bzw. dort angegebene zusätzliche Werte werden offenbar einfach ignoriert, weil vom PHP-Code nicht berücksichtigt - schließlich verwendet night4awk nach eigenem Bekunden ständig irgendwelche kruden URLs und es funktioniert - ohne b64-Tags - wohl trotzdem). Eine sichere Übertragung ist das allerdings auch nicht, solange dabei keine Transportverschlüsselung (Transport Layer Security - TLS) für die HTTP-Verbindung zum Einsatz kommt, denn trotz der Base64-Kodierung ist das immer noch - aus kryptographischer Sicht - Klartext (plain text), eben nur anders kodiert für den Transport und daraus kann man die Daten jederzeit wieder im Original extrahieren.

Da der DynDNS-Client des FRITZ!OS wohl nur HTTP-Requests für solche Aktualisierungen unterstützt (sowohl beim MS-Verfahren in jedem aktuellen Windows-System als auch bei dynamischen Aktualisierungen für die häufig verwendete "bind9"-Serversoftware mit ihrem "nsupdate" werden andere Verfahren verwendet), muß man sich bei dessen Konfiguration also weniger mit DNS und DynDNS auskennen, als vielmehr mit den HTTP-Grundlagen. Die bereits erwähnten Protokolle (/var/tmp/ddnslog_?.txt, es gibt in der Regel mehr als eine Datei) findet man beim FRITZ!OS von AVM in den Support-Daten (oder bei Obi Telnet), mit ihnen ist in aller Regel eine exakte Eingrenzung des Problems möglich, solange es eben nicht auf der Serverseite liegt und der dann zu allem Überfluß eventuell auch noch falsch antwortet (hatten wir gerade erst in einem anderen Thread zu "change-ip.com", wo offenbar am letzten Wochenende etwas auf Providerseite geändert wurde).

So, das sollte als Klarstellung/Erläuterung reichen ...