Lights out Mobile im lokalen Netzwerk

[Neuro]

Hallo allerseits,

habe gerade versucht im lokalen Netzwerk Lights-Out Mobile für Windows Phone zu nutzen. Allerdings bekomme ich immer den Fehler 404. Z.B: https://192.168.0.2
Kann es sein, dass das Tool nur übers Web funktioniert, oder handelt es sich hier um nen Bug. Übrigens liegt es nicht am Server. Die Mac-Clients im Netzwerk laufen
ja über das gleiche Prinzip. Diese funktionieren.

[Martin]

Lights-Out Mobile erfordert zwingend eine SSL Verbindung und damit kannst du keine IP verwenden (da dann der Name nicht zum Zertifikat passt).
Du kannst immer den kostenfreien xxx.homeserver.com Namen verwenden, da dafür automatisch ein SSL Zertifikat erstellt wird.

Bei den Macs ist SSL optional.

Gruß
Martin

[Neuro]

Hallo Martin,

danke für die schnelle Antwort.

D.h. ich muss zwingend mein System nach "draußen" öffnen, um Lights-Out Mobile mit meinen Server im lokalen Netzwerk nutzen zu können?

[Martin]

Nein, musst du nicht. Wenn du kein Portforward im Router einrichtest ist der Zugriff von aussen gesperrt.

Gruß
Martin

[JoachimL]

Nein, musst du nicht. Wenn du kein Portforward im Router einrichtest ist der Zugriff von aussen gesperrt.

Das passt nicht ganz zusammen. Wenn die Nutzung der externen Domain (*.homeserver.com oder DynDNS) mit Zertifikat notwendig ist, dann muss Portforwarding offen sein, oder die interne Auflösung der externen Domain muss funktionieren. Das wiederum setzt entweder eine Manipulation der hosts Datei (geht das auf Mobilgeräten ohne Jailbreak oder Rooten?) oder einen entsprechend konfigurierten DNS Server voraus - und wer hat das? (ich hab zwar dnsmasq, aber so verbogen auch nicht.)
Gruß Joachim

[Martin]

Du hast natürlich Recht. Was geht, ist das Verlagern zu einem hohen Port, z.B. SSL auf 44443. Der WHS beschwert sich dann zwar dass die Webseite nicht erreicht werden kann, aber der Zugriff per Mobilgerät klappt dann (du musst die 44443 dann im WP dahinterhängen, z.B. xxxx.homeserver.com:44443

Gruß
Martin

[JoachimL]

Du hast natürlich Recht. Was geht, ist das Verlagern zu einem hohen Port, z.B. SSL auf 44443. Der WHS beschwert sich dann zwar dass die Webseite nicht erreicht werden kann, aber der Zugriff per Mobilgerät klappt dann (du musst die 44443 dann im WP dahinterhängen, z.B. xxxx.homeserver.com:44443

Das ist aber nur Obscurity, die Angriffsfläche bleibt die gleiche.
Gruß Joachim

[Neuro]

Das ist aber nur Obscurity, die Angriffsfläche bleibt die gleiche.

Genau so sieht's aus! Das ist für mich eine laienhafte aber keine akzeptable Lösung. Wie wäre es mit nem Update?

Wenn es schon im Windows-Phone Marketplace keine Testversion für diese Bezahlsoftware gibt, wäre ein Hinweis auf besagte Einschränkung (auf Kosten der Systemsicherheit) im Beschreibungstext mehr als wünschenswert.

[Martin]

Das Problem liegt in der Übertragung von Username/Passwort. Ohne SSL-Verschlüsselung kann das jeder mitlesen. Das der WHS die SSL Infrastruktur mitbringt war das eben erste Wahl. Ich wollte vermeiden dass sich ein "unbedarfter" Anwender da ein Sicherheitsloch aufmacht. Deshalb ist in der aktuellen Version kein http:// erlaubt.

Wie wäre es mit nem Update?

Was soll wie geändert werden?

Gruß
Martin

[JoachimL]

Was soll wie geändert werden?

Ideal wäre wenn Du bei der Installation ermöglichst einen weiteren Port im IIS mit der gleichen Funktionalität aber mit dem internen statt dem externen Zertifikat (z.B. "server" wenn der WHS als "\\server" erreichbar ist) zu verwenden. Dann kann man auf dem Mobile und sonstwo "https://server:port" eintragen und voila...leider nur wenn dieser Name dann auch im lokalen Netz aufgelöst wird - das hängt vom Router bzw. DNS Server ab.
Gruß Joachim

[Martin]

Unter WHS v1 gibt es zwei Zertifikate, das SSL Zertifikat von Go Daddy, das beim Einrichten der xxx.homeserver.com angelegt und in die Standardwebseite für Port 443 eingebunden wird.
Daneben gibt es ein selbst signiertes Zertifikat für SERVER, das für den WHS Connector auf Port 56000 verwendet wird. Das selbst signierte Zertifikat wird während der WHS Connectorinstallation am Client hinzugefügt.

Der Lights-Out Webservice ist unterhalb der Standardwebsite eingehängt, eben weil 80/443 darauf verweisen.
Natürlich könnte ich jetzt eine weitere Website anlegen und diese auf Port xyz legen, aber mit welchem Zertifikat?
Das selbst signierte Zertifikat für SERVER kann nicht verwendet werden, da das am Smartphone nicht akzeptiert wird.

Gruß
Martin

[JoachimL]

Das selbst signierte Zertifikat für SERVER kann nicht verwendet werden, da das am Smartphone nicht akzeptiert wird.

Ob die APIs das hergeben weiß ich nicht, aber analog zu SSH kann man dem Benutzer das Zertifikat (Fingerprint) einmalig anzeigen und fragen ob er es als (für die Zukunft) vertrauenswürdig einstuft.
Und wenn das nicht hilft, das Problem aber nur das unverschlüsselte Übertragen von User&Passwort ist: wie wäre es mit einem Zero-Knowledge-Protokoll.
Gruß Joachim

[Martin]

Das Smartphone erlaubt keine selbst signierten Zertifikate, das scheidet also aus, da gibt es auch kein API dafür da der Aussteller nicht in den Rootzertifikaten steht.
Der zweite Vorschläg ist ja ganz nett aber auch da gibt es keine fertigen Implementierungen, die man einfach so anwenden kann.

Das obige Problem betrifft ja nur ganz wenige, wenn ich mir dafür den Aufwand und Ertrag ansehe steht das in keinem Verhältnis (so in etwa Division durch Null )

Gruß
Martin

[JoachimL]

Das Smartphone erlaubt keine selbst signierten Zertifikate, das scheidet also aus, da gibt es auch kein API dafür da der Aussteller nicht in den Rootzertifikaten steht.

Aber es gibt sicher eine Möglichkeit das Rootzertifikat des WHS zu importieren? Was machen sonst Firmen die Ihre eigene PKI und Root-Zertifikate haben?

Der zweite Vorschläg ist ja ganz nett aber auch da gibt es keine fertigen Implementierungen, die man einfach so anwenden kann.

Vielleicht doch: ein Windows Phone sollte ja eigentlich auch Windows Authentication können, wenn Du eine IIS Site entsprechend konfigurierst könnte das gehen. Und m.W. ist Windows Authentication ein solches Protokoll.

Das obige Problem betrifft ja nur ganz wenige, wenn ich mir dafür den Aufwand und Ertrag ansehe steht das in keinem Verhältnis (so in etwa Division durch Null )

Das ist selbstverständlich ein valider Grund - wenn es keine triviale Lösung gibt.
Gruß Joachim

[Martin]

Vorschlag für das Problem: Bisher ist es so, dass die App den Präfix https erzwingt auch wenn der Anwender den löscht.
Ich würde die App so ändern, dass bei einem Namen ohne Domain (also ohne Punkte im Namen) http erhalten bleibt. Damit würde dann der Zugriff im lokalen Netz ohne SSL klappen.

Gruß
Martin