Shell-In-A-Box Problemchen

[meiser79]

Shell-in-a-box verwendet SSLv23_server_method(), somit sollte auch TLS gehen. Zudem hat Firefox 35.0.1, den ich verwende, SSL standardmäßig deaktiviert, also verhandelt er auch nur mittels TLS.

 

[bilbo_b]

Dann versteh ich es nicht :-( Aber wie gesagt, da es über reverse_proxy geht, lass ich es erst mal so. Vielleicht schau ich es mir am WE noch mal an.

 

[bilbo_b]

Whoopie hat recht, SSL funktioniert. Allerdings nur, wenn man direkt auf die Box geht. Ich hab den Port 4200 über die Portfreigabe einer anderen Box freigegeben und versuche nun das Ding so von "außen" zu erreichen. Das geht wohl nicht. Soll heißen: Auf der Kiste mit Shell in a Box installiert, lauscht es auf Port 4200. Auf der Box davor habe ich ebenfalls den Port 4200 auf 4200 zur Box dahinter freigegeben. Dann greife ich von außen mit meiner DynDNS Adresse zu (https://some.dyndns.org:4200/). Damit klappt der Zugriff nicht. Warum, weiß ich nicht. Gehe ich aber auf https://192.168.178.205:4200/ im internen Netz, gibts keine Probleme.

Ich lass es jetzt so, passt schon.

 

[PeterPawn]

@Bilbo_b:
Mein Tipp dazu wäre, daß Dein Browser es nicht mag, wenn von derselben IP-Adresse auf unterschiedlichen Ports auch unterschiedliche Zertikate präsentiert werden (eines von jeder Box, je nachdem, wo man "anruft"). Tritt das Problem auch in einer "frischen" Browser-Sitzung auf, wenn vorher kein Kontakt zu 443 (oder wohin auch ímmer Du den verbogen hast) stattgefunden hat?

 

[bilbo_b]

Ich kann auch mittels InPrivate nicht zugreifen. Damit hab ich ja immer eine neue Session. Wenn ich das Zertifikat mit lighttpd verwende, kann ich dieses dort mit beliebigen Ports verwenden. Hätte mich auch ein wenig gewundert, wenn der Port dabei eine Rolle spielt. Andererseits verwenden wir hier einen Zwangsproxy und ich nehme einfach an, das dieser das Problem verursacht.

 

[PeterPawn]

Ich kann auch mittels InPrivate nicht zugreifen. Damit hab ich ja immer eine neue Session.

:gruebel:
Was willst Du damit sagen? Wenn Du mit "InPrivate" tatsächlich nur den "Porno"-Modus des Internet-Explorers (oder eines anderen Browsers) meinst, was hat das mit dem (möglichen) Problem unterschiedlicher Zertifikate für Zugriffe auf das FRITZ!Box-GUI und auf Shell-in-a-Box zu tun, solange Du nicht das FRITZ!Box-Zertifikat auch für Shell-in-a-Box benutzt? Und von was für einer Session schreibst Du in diesem Zusammenhang überhaupt?

Andererseits verwenden wir hier einen Zwangsproxy und ich nehme einfach an, das dieser das Problem verursacht.

Das kann natürlich auch sein, wobei dann mit etwas Pech schon dieser Proxy sich an unterschiedlichen Zertifikaten für dieselbe Adresse stößt und Du das mit einer "frischen" Browser-Session gar nicht mehr in der Hand hast.

Um Mißverständnisse zu vermeiden, ich meine mit "Browser-Session" eine komplett neu gestartete Instanz. Das ist auch nicht das, was man bei der Verwendung des "Porno-Modus" bei einem normalen Browser erhält ... denn im Gegensatz zu Inhalten der Kommunikation werden andere Daten, wie DNS-Auflösungen und eben auch SSL-Zertifikate, durchaus für die Dauer der "Sitzung" im Browser gespeichert und ggf. wiederverwendet.

Das geht sogar so weit, daß eine noch im Speicher verfügbare Instanz - selbst wenn sie keine aktiven Fenster mehr hat - den Start einer neuen Instanz verhindern kann, wie sicherlich fast jeder schon mal anhand eines Firefox-Browsers erleben durfte, wenn den irgendetwas am "tatsächlichen Beenden" hinderte und die nächste Instanz dann mit einer entsprechenden Fehlermeldung den Start verweigerte.

 

[bilbo_b]

Aha. Ich war immer der Meinung, das wenn ich den sogenannten "Porno"-Modus starte, ich immer mit einem quasi neuen, cleanen Profil starte und einer neuen leeren Session (mal abgesehen davon, das die offline Daten wieder entfernt werden, beim Schließen des Fensters). Ich verwende diesen Modus eigentlich immer dann, wenn ich auf einer Seite zwei unterschiedliche Logins gleichzeitig brauche. Hat bisher immer geklappt.

Daher bin ich davon ausgegangen, das ich mit einem solchen Fenster auch immer eine neue (http) Session habe. Klar, er nutzt dann die im Browser hinterlegten Zertifikate und den DNS Cache des Systems.

 

[PeterPawn]

ich immer mit einem quasi neuen, cleanen Profil starte und einer neuen leeren Session [...]. Ich verwende diesen Modus eigentlich immer dann, wenn ich auf einer Seite zwei unterschiedliche Logins gleichzeitig brauche. Hat bisher immer geklappt.

Das funktioniert genau dann, wenn die Session-Verwaltung (und das meint jetzt die serverseitige Session, innerhalb der Du Dich ggf. authentifiziert hast), mit Cookies (egal ob permanent - wird ohnehin anschließend gelöscht - oder nur für die Sitzungsdauer) arbeitet, da ja die dort abgelegten Daten nicht "überleben". Aber bei DNS-Abfragen und SSL-Zertifikaten sieht man das offenbar nicht so eng (in diesem Fall wieder explizit der FF, andere mögen das ein wenig anders handhaben) und verzichtet lieber auf den Overhead mehrfacher DNS-Abfragen und ggf. auch mehrfacher Zertifikatüberprüfungen mit OCSP oder was auch immer.

Daher bin ich davon ausgegangen, das ich mit einem solchen Fenster auch immer eine neue (http) Session habe.

Das ist auch tatsächlich so, aber es hat mit dem (angenommenen) Problem der unterschiedlichen Zertifikate für ein- und dieselbe Adresse nicht unbedingt etwas zu tun. Man braucht ja bloß mal von einer anderen Stelle aus (da, wo der Zwangsproxy nicht mehr dazwischen ist) erst die eine und dann die andere Seite (also FRITZ!Box-GUI und Shell-in-a-Box) aufrufen und die Reaktion des Browsers auf das geänderte Zertifikat checken ... dann weiß man genau, ob in diesem Szenario sich der eigene Browser an einem geänderten Zertifikat stört. Als FRITZ!Box-Besitzer trifft man gerne mal auf diese Situation, wenn man per Fernwartung eine Einstellung ändert, die auf ein neues Zertifikat hinausläuft (also DynDNS- oder MyFRITZ!-Einstellungen) ... dann weigert sich mein Firefox auch immer, den Inhalt bei geändertem Zertifikat anzuzeigen und sogar der "pfeif drauf"-Button fehlt in so einem Fall in der Regel.

 

[bilbo_b]

Verstehe. Das trifft in meinem Fall ja nicht zu, da meine DynDNS Adresse meine eigene Domain ist. Diese ist bei Strato abgelegt. Strato wird ja direkt von der FritzBox asl Anbieter für DynDNS unterstützt (Gottseidank). Somit konnte ich bei StartSSL ein richtiges Zertifikat für diese Domain ausstellen lassen und habe dieses auf der FritzBox, in lighttpd und nun eben auch Shell-In-A-Box hinterlegt. Der Domainanteil im URL ist also (bis auf den Port) immer gleich. Der Teil nach der Domain ist dann unterschiedlich. Egals, was solls...

 

[PeterPawn]

Ok, das stand seit #14 bisher nirgendwo.

Und wenigstens als Hinweis oder Erklärung eines möglichen Problems für spätere Leser taugt es dann immer noch ...