wie Zugriff über SSL-Proxy sicherstellen

[Bene]

Hallo,

ich habe folgendes Problem:
meine Domain ist auch erreichbar über einen SSL-Proxy. d.h. die Inhalte von meinen Webspace kann ich einmal über ssl-proxy.de/meinedomain.de und über meinedomain.de aufrufen. Jetzt will ich sicherstellen, dass der Zugriff auf die geschützten Bereiche nur über den SSL-Proxy erfolgt. Die Authentifizierung erfolgt über Apache Authentifizierung (.htaccess).
Am liebsten würde ich diese Überprüfung auf den Zugriff über SSL-Proxy auch durch den Apache machen lassen.

Habt ihr Tipps für mich?

Viele Grüße
Bene

[Sven Rautenberg]

Moin!

Am liebsten würde ich diese Überprüfung auf den Zugriff über SSL-Proxy auch durch den Apache machen lassen.

Der Proxy hat eine definierte IP oder einen definierten IP-Bereich, von dem er aus auf deinen Server zugreift.

Order allow,deny
allow from IP

Fertig.

- Sven Rautenberg

[wahsaga]

hi,

Am liebsten würde ich diese Überprüfung auf den Zugriff über SSL-Proxy auch durch den Apache machen lassen.

Der Proxy hat eine definierte IP oder einen definierten IP-Bereich, von dem er aus auf deinen Server zugreift.

Ich glaube, du hast dich von der unpassenden Bezeichnung "SSL-Proxy" in die Irre führen lassen.

Seine Seite lässt sich, wie bei vielen Shared-Hosting-Providern üblich, über
http://meinedomain.de
und
http(s)://ssl-proxy.de/meinedomain.de
erreichen.

Für eine SSL-Verbindung muss er natürlich über letztere Adresse gehen - IP zeigt nicht ausschließlich auf seine Domain, ergo bei SSL kein Ansprechen des VirtualHosts für meinedomain.de möglich.

Am liebsten würde ich diese Überprüfung auf den Zugriff über SSL-Proxy auch durch den Apache machen lassen.

Per mod_rewrite ermitteln, ob HTTPS verwendet wurde - wenn nein, expliziter Redirect auf https://...

Gruß,
wahsaga

[Sven Rautenberg]

Moin!

Am liebsten würde ich diese Überprüfung auf den Zugriff über SSL-Proxy auch durch den Apache machen lassen.

Der Proxy hat eine definierte IP oder einen definierten IP-Bereich, von dem er aus auf deinen Server zugreift.

Ich glaube, du hast dich von der unpassenden Bezeichnung "SSL-Proxy" in die Irre führen lassen.

Nein, glaube ich nicht.

Seine Seite lässt sich, wie bei vielen Shared-Hosting-Providern üblich, über
http://meinedomain.de
und
http(s)://ssl-proxy.de/meinedomain.de
erreichen.

Richtig.

Für eine SSL-Verbindung muss er natürlich über letztere Adresse gehen - IP zeigt nicht ausschließlich auf seine Domain, ergo bei SSL kein Ansprechen des VirtualHosts für meinedomain.de möglich.

Was macht denn der SSL-Proxy? Er ist ein eigenständiger Server mit anderem Domainnamen und anderer öffentlicher IP, der den Request analysiert und ihn auf die diversen Server des Providers durchreicht. Der Domainname ist deshalb für alle Kunden, die SSL nutzen wollen, identisch, weil man sich damit eine Menge Zertifikate spart, die Geld kosten. Der Request vom Proxy hin zum eigentlichen Webspace läuft ohne SSL. Und daher sieht der eigentliche Server dann einen simplen HTTP-Request von einer möglicherweise internen IP-Adresse (die nicht identisch sein muß mit der öffentlichen IP des SSL-Proxys), die eindeutig dem SSL-Proxy zuzuordnen ist.

Und wenn jeglicher unverschlüsselter Zugang zu einem Webverzeichnis unterbunden werden soll, dann darf der Zugang eben nur dem SSL-Proxy erlaubt werden.

Am liebsten würde ich diese Überprüfung auf den Zugriff über SSL-Proxy auch durch den Apache machen lassen.

Per mod_rewrite ermitteln, ob HTTPS verwendet wurde - wenn nein, expliziter Redirect auf https://...

Der Kundenserver sieht von SSL nichts.

Ich denke eher, du liegst ob der Funktionsweise des SSL-Proxys komplett falsch.

- Sven Rautenberg

[Bene]

Hallo,

erstmal Danke für eure Antworten.
Ich denke ich werde das mit der Verbot der IP-Adresse machen.
Jetzt ist bei mir noch ein neues Problem aufgetaucht:
Der SSL-Proxy leitet unglücklicherweise alle Aufrufe von ssl-proxy/meine-domain.de/meinOrdner weiter an meine-domain.de/meinOrdner.
Bei dem Aufruf von ssl-proxy/meine-domain.de/meinOrdner/ (also mit abschließenden Slash) erfolgt keine Weiterleitung.
Der Support hat mir gesagt, das der Server ohne den Slash nicht von einem Ordner ausgeht. Jetzt meine Frage: Ist dies prinzipiell mit mod rewrite lösbar.
Ich habe mir mal folgendes gedacht: Endet die URL nicht mit einem Slash und gibt es in Teil der URL nach dem letzten Slash kein Punkt, dann wird ein Slash angehängt.
Was haltet ihr von der Idee? Wäre das mit mod rewrite umsetzbar?

Danke und viele Grüße
Benedikt

[wahsaga]

hi,

Was macht denn der SSL-Proxy? Er ist ein eigenständiger Server mit anderem Domainnamen und anderer öffentlicher IP, der den Request analysiert und ihn auf die diversen Server des Providers durchreicht.

Warum sollte es ein anderer sein müssen?

AFAIK ist das "Problem" bei SSL und name-based Virtual Hosts doch, dass der Host-Header des Request zu spät entschlüsselt wird, um die Zuordnung treffen zu können.

Man kann darüber also gar keinen Virtual Host ansprechen, sondern nur den Server, der sich über die IP "per default" als erreichbar zeigt.

Der Domainname ist deshalb für alle Kunden, die SSL nutzen wollen, identisch, weil man sich damit eine Menge Zertifikate spart, die Geld kosten.

Und weil man bei name-based Virtual Hosts gar nicht für jede Domain eine eigene IP hat.

Ich denke eher, du liegst ob der Funktionsweise des SSL-Proxys komplett falsch.

Wenn es in Benes Fall wirklich ein Proxy ist, dann hatte ich ihn da missverstanden.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

Was macht denn der SSL-Proxy? Er ist ein eigenständiger Server mit anderem Domainnamen und anderer öffentlicher IP, der den Request analysiert und ihn auf die diversen Server des Providers durchreicht.

Warum sollte es ein anderer sein müssen?

Muß es nicht sein - aber es ist technisch schlauer, das so zu realisieren. Denn ein Domainhoster hat sicherlich mehrere tausend bis Millionen Domains von Kunden - und folglich auch mehrere hundert bis tausend Server mit ebensovielen IP-Adressen.

Damit also der generische Weg "ssl-proxy.de/kundendomain.de" funktioniert, müßte der DNS-Resolver erkennen, dass er jetzt die IP von kundendomain.de suchen und dort den SSL-Host "ssl-proxy.de" ansprechen soll - wie soll sowas funktionieren?

Und einfach alle IP-Adressen der Kundendomains im DNS auch auf "ssl-proxy.de" zu mappen scheitert an der Masse an IP-Adressen - ein DNS-UDP-Datenpaket kann nur begrenzt viele Daten aufnehmen, die Zahl der IP-Adressen ist also auch begrenzt.

Und außerdem: Was nützt es, wenn der falsche SSL-Proxyserver angesprochen wird, auf dem die Domain gar nicht original gehostet wird? Dann muß doch wieder ein HTTP-Request zum anderen Server vorgenommen werden - genau wie in meinem Szenario schon skizziert.

Also warum nicht gleich so?

AFAIK ist das "Problem" bei SSL und name-based Virtual Hosts doch, dass der Host-Header des Request zu spät entschlüsselt wird, um die Zuordnung treffen zu können.

Man kann darüber also gar keinen Virtual Host ansprechen, sondern nur den Server, der sich über die IP "per default" als erreichbar zeigt.

Es ist ein Irrglaube, dass SSL und Virtual Hosts nicht funktionieren oder zusammenpassen.

Das Problem in diesem Zusammenhang ist, dass das SSL-Zertifikat IP-und-Port-gebunden konfiguriert werden muß (mit Portangabe in der URL wäre also auch mehr als ein Zertifikat pro Server realisierbar - das versteht aber kein User umzusetzen). In diesem Zertifikat ist die gültige Domain enthalten. Diese Domain kann aber auch ein Wildcardzeichen enthalten, d.h. es ist ohne Probleme möglich, für eine ganze Gruppe von Subdomains einer im Zertifikat genannten Hauptdomain auf nur einem einzigen Server virtuelle Hosts anzulegen. Das Zertifikat bescheinigt den korrekt signierten Verbindungaufbau zu "*.example.com", und danach setzt im Apache die VHost-Konfiguration ein, entscheidet sich nach Host-Header für den richtigen VHost, und der hat dann zwingend auf die Endung ".example.com" zu hören. "sub1.example.com" und "sub2.example.com" sind mit SSL problemlos realisierbar.

Nur: "www.example.com" und "www.example.org" auf dem gleichen Server - das geht nicht, weil dann die Zertifikatprüfung meckert (wenn man die Meckerei ignoriert, würde es aber trotzdem funktionieren). Aber welcher User würde das guten Gewissens erlauben - und welcher Providerkunde würde sich mit solch einer Krücke für seine SSL-Präsenz zufrieden geben?

Wenn es in Benes Fall wirklich ein Proxy ist, dann hatte ich ihn da missverstanden.

Ich denke, es gibt rein technisch keinerlei Alternativen, mit einem gemeinsamen Zertifikat für alle Kunden SSL zu realisieren, als über die Lösung mit einem echten Proxy vor dem Originalserver - und ggf. unverschlüsselter Übertragung "hinter" dem Proxy, geschützt nur durch die Vertraulichkeit des internen Netzes des Providers.

Mit anderen Worten: Diese "shared SSL-Proxy"-Lösung ist zwar hinsichtlich des Internets so sicher, wie SSL sein kann, die Strecke hinter dem Proxy allerdings ist unverschlüsselt und potentiell angreifbar, auch wenn der Provider durch entsprechende Sicherheitsmaßnahmen (Netztrennung im Switch etc.) die Abhörbarkeit durch mögliche Randlauscher (z.B. Rootserver, die mit tcpdump arbeiten und mit arp-Spoofing den Switch zu sich umleiten) relativ sicher ausschließen kann. Nicht zuletzt ist der Zielserver ja ohnehin eine Shared-Hosting-Umgebung und deshalb schon mal ein wenig kritischer zu sehen. Wer weiß denn schon genau, ob jeder VHost bestmöglich gegen jeden anderen abgeschottet ist. Aber das sind doch wohl eher theoretische Überlegungen.

- Sven Rautenberg

[wahsaga]

hi,

Damit also der generische Weg "ssl-proxy.de/kundendomain.de" funktioniert, müßte der DNS-Resolver erkennen, dass er jetzt die IP von kundendomain.de suchen und dort den SSL-Host "ssl-proxy.de" ansprechen soll - wie soll sowas funktionieren?

ssl-proxy.de und kundendomain.de werden auf die gleiche IP aufgelöst - es ist also erst mal egal, was im Host-Header steht, ich lande immer auf der gleichen Maschine.

Und einfach alle IP-Adressen der Kundendomains im DNS auch auf "ssl-proxy.de" zu mappen scheitert an der Masse an IP-Adressen

Mein Provider bietet für jeden seiner Server, auf dem er x Kundendomains hostest, Zugriff über www{i}.ssl-domain.xy an.
Für Server eins also www1.ssl-domain.xy, für Server zwei www2.ssl-domain.xy, etc.
Gut, damit kommt er nicht mehr mit einem einzigen SSL-Zertifikat für alle Kunden aus - er braucht halt pro Server eins.

Es ist ein Irrglaube, dass SSL und Virtual Hosts nicht funktionieren oder zusammenpassen.

Danke, in dem Punkt war ich unzureichend informiert.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

ssl-proxy.de und kundendomain.de werden auf die gleiche IP aufgelöst - es ist also erst mal egal, was im Host-Header steht, ich lande immer auf der gleichen Maschine.

Woher weißt du das im konkreten OP-Fall? Die wahre Domain wurde nicht angegeben, IIRC.

Mein Provider bietet für jeden seiner Server, auf dem er x Kundendomains hostest, Zugriff über www{i}.ssl-domain.xy an.
Für Server eins also www1.ssl-domain.xy, für Server zwei www2.ssl-domain.xy, etc.
Gut, damit kommt er nicht mehr mit einem einzigen SSL-Zertifikat für alle Kunden aus - er braucht halt pro Server eins.

Eben nicht. Einfach ein einziges SSL-Zertifikat auf "*.ssl-domain.xy" ausstellen lassen, das kann dann auf allen Servern installiert werden. Es ist ja nicht IP-basiert erzeugt, sondern domainnamenbezogen. Man spart sich dann den Proxy, erzeugt aber die Notwendigkeit, dass alle Server auch das SSL-Modul installiert haben und CPU-Leistung für Verschlüsselung bereitstellen.

Es ist eine Frage der Abwägung diverser Faktoren, ob sich der eine oder der andere Weg rechnen - auch im Hinblick auf weiteres Wachstum.

- Sven Rautenberg

[wahsaga]

hi,

ssl-proxy.de und kundendomain.de werden auf die gleiche IP aufgelöst - es ist also erst mal egal, was im Host-Header steht, ich lande immer auf der gleichen Maschine.

Woher weißt du das im konkreten OP-Fall?

Das war nicht auf den Fall bezogen, sondern mein Beispiel.

gruß,
wahsaga

[Christian Seiler]

Hallo Sven,

Es ist ein Irrglaube, dass SSL und Virtual Hosts nicht funktionieren oder zusammenpassen.

Das Problem in diesem Zusammenhang ist, dass das SSL-Zertifikat IP-und-Port-gebunden konfiguriert werden muß (mit Portangabe in der URL wäre also auch mehr als ein Zertifikat pro Server realisierbar - das versteht aber kein User umzusetzen).

Nein, das stimmt so nicht mehr, man kann heutzutage auch beliebige namensbasierte VHosts mit TLS einsetzen. RFC 3546 (Transport Layer Security (TLS) Extensions) definiert eine TLS-Erweiterung, die es ermöglicht, den Server-Namen schon im TLS-Handshake auszuhandeln, das ganze nennt sich SNI (Server Name Identification). Opera kann's aber Version 7.6, Firefox ab Version 2.0, der IE ab Version 7.0, Konqueror wird's aber Version 4.0 können. mod_ssl für den Apache kann es noch nicht, mod_gnutls dagegen schon (allerdings raten die mod_gnutils-Leute selbst noch von einem Produktiveinsatz ab). Das ganze kann man unter https://sni.velox.ch/ testen (man bekommt allerdings ne Menge Warnungen außer "selbstsigniertes Zertifitkat", wenn der Browser, wie z.B. Firefox 1.5, noch kein SNI kann).

Das ganze ist noch recht neu, aber da es in allen Mainstream-Browsern heute bereits implementiert ist (bzw. so gut wie implementiert ist) sowie die mod_ssl-Leute beim Apache dran arbeiten, bleibt zu hoffen, dass sich das in einigen Jahren sogar für den Produktiveinsatz anbietet.

Viele Grüße,
Christian

[Johannes Zeller]

Hallo Sven,

Was macht denn der SSL-Proxy? Er ist ein eigenständiger Server mit anderem Domainnamen und anderer öffentlicher IP, der den Request analysiert und ihn auf die diversen Server des Providers durchreicht. Der Domainname ist deshalb für alle Kunden, die SSL nutzen wollen, identisch, weil man sich damit eine Menge Zertifikate spart, die Geld kosten. Der Request vom Proxy hin zum eigentlichen Webspace läuft ohne SSL. Und daher sieht der eigentliche Server dann einen simplen HTTP-Request von einer möglicherweise internen IP-Adresse (die nicht identisch sein muß mit der öffentlichen IP des SSL-Proxys), die eindeutig dem SSL-Proxy zuzuordnen ist.

Was ich mich jetzt frage: Handelt es sich bei dem SSL-Proxy um einen öffentlichen Proxy, der lediglich Seiten über SSL an den Benutzer weiterleitet oder holt er sich die Daten auf internem Weg von dem Webserver, auf dem die eigentliche Webseite liegt.

Ersteres hat natürlich keinen Sinn, weil die Daten schlussendlich doch unversclüsselt übertragen werden. Aber da ich nicht weiß, wer den SSL-Proxy administriert möchte ich das nicht 100%-ig  ausschließen. ;-)

Soweit ich das sehe ist es zur richtigen Beantwortung der Frage notwendig zu wissen, wie genau der SSL-Proxy funktioniert, d.h. über welchen Kanal er die Daten vom Webserver bekommt. Nur dann lässt sich ermitteln, wie man überprüfen kann, ob der Zugriff über selbigen erfolgt. Ohne dies kann man höchstens Vermutungen anstellen.

Schöne Grüße,

Johannes

[Sven Rautenberg]

Moin!

Was ich mich jetzt frage: Handelt es sich bei dem SSL-Proxy um einen öffentlichen Proxy, der lediglich Seiten über SSL an den Benutzer weiterleitet oder holt er sich die Daten auf internem Weg von dem Webserver, auf dem die eigentliche Webseite liegt.

Der Proxy ist "öffentlich" in dem Sinne, dass er von außen erreichbar ist. :) Da er im Netz des Providers steht, holt er sich die Daten nicht über das Internet, sondern natürlich direkt über das Intranet des Providers. Der unverschlüsselte Weg der Daten wird also enorm verkürzt und kann dort auch recht zuverlässig gegen Mitlauschen von Providerkunden geschützt werden.

Die Gefahr, dass der Provider lauscht, ist aber natürlich immer gegeben - auch dann, wenn SSL direkt auf dem VHost installiert wäre.

Soweit ich das sehe ist es zur richtigen Beantwortung der Frage notwendig zu wissen, wie genau der SSL-Proxy funktioniert, d.h. über welchen Kanal er die Daten vom Webserver bekommt. Nur dann lässt sich ermitteln, wie man überprüfen kann, ob der Zugriff über selbigen erfolgt. Ohne dies kann man höchstens Vermutungen anstellen.

Ein Blick in das access_log sollte eigentlich Aufschluß genug bieten.

- Sven Rautenberg

[Johannes Zeller]

Hallo Sven,

Der Proxy ist "öffentlich" in dem Sinne, dass er von außen erreichbar ist. :) Da er im Netz des Providers steht, holt er sich die Daten nicht über das Internet, sondern natürlich direkt über das Intranet des Providers. Der unverschlüsselte Weg der Daten wird also enorm verkürzt und kann dort auch recht zuverlässig gegen Mitlauschen von Providerkunden geschützt werden.

So etwas hatte ich auch vermutet.

Die Gefahr, dass der Provider lauscht, ist aber natürlich immer gegeben - auch dann, wenn SSL direkt auf dem VHost installiert wäre.

Sofern man nicht seinen eigenen Server in seinem eigenen Rechenzentrum stehen hat, muss man dem Provider zwangsmäßig vertrauen.

Ein Blick in das access_log sollte eigentlich Aufschluß genug bieten.

Woraus sich dann das notwendige Wissen ergibt ;-)

Schöne Grüße,

Johannes