Transparenter Proxy für HTTPS-Verbindungen

  • Hallo,


    ich habe mal wieder eine ganz spezielle Frage, die - wenn gelöst - sicher in die Rubrik Tipps & Tricks passt:


    SNI ist ja ganz nett, aber es gibt Fälle, da benötigt eine Domain eine exklusive IP. Und exklusive IPs werden langsam knapp. Um die mit Sicherheit aufkommende Rückfrage gleich zu beantworten, warum nicht nur SNI, hier ein ganz spezieller Fall: WebDAV! Der WebDAV-Client in Windows 7 (und folgende) kommt mit WebDAV-Verbindungen auf HTTPS auf SNI nicht zurecht. Der Rest darf ergoogled werden.


    Ich habe mir nun folgendes überlegt, um Kunden exklusive SSL-Verbindungen zu ermöglichen und dabei die wertvollen IPs zu sparen. Ich bin mir aber nicht wirklich sicher, wie ich das umsetzen kann, noch ob es überhaupt einen Weg gibt. Nach mehreren Stunden Google-Verhör frage ich mal hier in die Runde, da ich mir vorstellen kann, dass die Kollegen und Mitbewerber ggf. ähnliche Ideen haben.


    Meine Idee war nun, dass ich einen Proxy vorschalte und den DNS-Record der Domain auf eben diesen Proxy zeigen lasse. Der Proxy soll dann - abhängig vom angeforderten Hostnamen - in das interne Netz auf die entsprechende, private IP weiterleiten. Per HTTP funktioniert das auch ausgezeichnet. Ein Apache mit mod_proxy* nimmt die Anfragen an. Die .conf dazu sieht so aus:


    (wir nehmen an, 12.34.56.78 ist die IP des Proxy und auch der SubDomain proxytest.test.xy. Die IP 10.1.1.8 ist die IP, die in LiveConfig dem Kunden und der Domain zugeordnet ist)


    Code
    <VirtualHost 12.34.56.78:80>
    	ServerName proxytest.test.xy
    	ProxyPreserveHost On
    	ProxyPass / http://10.1.1.8:80/
    	ProxyPassReverse / http://10.1.1.8:80/
    </VirtualHost>


    Rufe ich jetzt also die Domain auf, bekomme ich die Seite angezeigt.


    Aber via HTTPS bekomme ich das nicht hin. Ich habe es so verstanden, dass mod_proxy_connect genau dafür da ist, solche Verbindungen quasi zu tunneln und dem Client das vom Zielserver ausgelieferte Zertifikat zu servieren. Ich kann auch per netstat -ant sehen, das eine Verbindung auf Port 443 vom Browser zum Proxy aufgebaut wird, aber keine Verbindung vom Proxy zu 10.1.1.8. Nöscht! Null!


    Die letzte Version meiner zahllosen Versuche und Variationen sieht so aus:



    Hat vielleich jemand eine Idee?

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Möglicherweise, aber auch dafür finde ich keine Lösung und auch nicht für SQUID. Aber zumindest mit dem Apache bin ich jetzt doch schon ein ganzes Stück weiter und habe eine SSL-Verbindung zustande gebracht. Bin aber noch nicht zufrieden, das ist alles noch sehr suboptimal. Ich bleibe dran ... falls es wen interessiert.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • Zitat

    Hat vielleich jemand eine Idee?



    Ja: lass es. Man kann so keine IPs "sparen", es geht schlichtweg nicht.


    Kurz: der TLS-Handshake mit Zertifikats-Austausch erfolgt bei Clients, die kein SNI können, auf dem Server nur anhand der Server-IP, bevor der Server überhaupt eine Unterscheidung auf den HTTP-Hostname durchführen kann.



    Länger:


    Ohne SNI wird der erste vHost (sowohl Nginx als auch Apache) selektiert, dessen IP/Port-Kombination zur Anfrage passt (bei nginx: "listen ... default").


    Aus diesem vHost wird dann das SSL-Zertifikat genommen und dem Client präsentiert, der dann daraufhin den TLS-Handshake durchführt.


    Zu diesem Zeitpunkt ist dem Webserver über die tatsächlich gewählte Domain ("ServerName") nichts bekannt, die Auswahl erfolgt wirklich nur anhand von Server-IP/Port. Erst nach dem erfolgreichen TLS-Handshake sendet der non-SNI-Browser dann den HTTP-Request, der im "Host:"-Header den letztendlichen vHost/Server-Name enthält. Dessen SSL-Konfiguration ist dann aber hinfällig, da ja die Verbindung bereits verschlüsselt wurde.


    Somit kann - ob nun "Proxy" oder nicht - nur ein einziges SSL-Zertifikat je IP/Port überhaupt an Clients ausgeliefert werden, die kein SNI können.


    => es wird auch weiterhin für jedes SSL-Zertifikat eine eigene IP benötigt, sobald SNI nicht eingesetzt werden kann.



    Weitere Details siehe Wikipedia:


    - OSI-Layer:
    - TCP
    - TLS
    - HTTP
    - RFC 3546

  • Ergänzung:


    Einzige Abhilfe, wenn mehrere Domains abgedeckt werden soll: ein Zertifikat erwerben, das alle Domains beinhaltet (Multi-Domain-Zertifikat).


    Ist natürlich nur möglich, wenn es finanzierbar ist (die kosten mehr als Single-Domain-Zertifikate) und vom Datenschutz her machbar ist (da die anderen abgedeckten Domains im Zertifikat aufgelistet werden müssen).

  • Moin,


    antondollmaier: Hasse rääsch! Ich hatte mich mit der Problematik schon einmal befasst und erfolgreich verdrängt, dass der Host erst dann aufgelöst wird, wenn eine HTTPS-Verbindung hergestellt wurde. Bis dahin gibt es das Standard-SSL-Zertifikat und danach erst kann mit SNI das richtige, passende Zertifikat ausgeliefert werden. Mein Plan ist damit für die Tonne. Darum habe ich erstmal ein Wildcard-Zertifikat auf dem entsprechenden Server und wenn ein Kunde eine eigene Domain wünscht, dann muss er halt eine eigene IP bekommen und für das passende Zertifikat halt selbst bezahlen.


    Mogwais: Danke für den Hinweis, aber wie Antondollmaier schon schreibt, der Handshake ist der Knackpunkt.


    In meinem wirren Programmierer-Hirn habe ich eine unscharfe Idee, die ich aber aufgrund der Auftragslage in diesem Leben wohl nicht mehr umsetzen kann:


    Ein Deamon, der HTTPS Anfragen entgegennimmt und cached. Anhand einer Liste interner IPs wird diese Anfrage nacheinander an alle internen IPs gesendet und der Handshake wird getestet. Passt das ausgelieferte Zertifikat, sorgt der Deamon fur ein Forwarding (via iptables oder so) des Clients zum richtigen Zielhost für die Dauer der Session...

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

  • antondollmaier: Hasse rääsch! Ich hatte mich mit der Problematik schon einmal befasst und erfolgreich verdrängt, dass der Host erst dann aufgelöst wird, wenn eine HTTPS-Verbindung hergestellt wurde. Bis dahin gibt es das Standard-SSL-Zertifikat und danach erst kann mit SNI das richtige, passende Zertifikat ausgeliefert werden.


    Mit SNI sendet der Client im TLS-Handshake den Hostname mit, für den er eine TLS-Verbindung aufbauen will - somit kann der Server (soweit der die SNI-Erweiterung unterstützt) _direkt_ das richtige SSL-Zertifikat selektieren und verwenden.


    Das "Standard-Zertifikat" kommt nur noch zum Einsatz, wenn ein Client kein SNI kann:


    > https://sni.velox.ch/




    Zitat

    Darum habe ich erstmal ein Wildcard-Zertifikat auf dem entsprechenden Server und wenn ein Kunde eine eigene Domain wünscht, dann muss er halt eine eigene IP bekommen und für das passende Zertifikat halt selbst bezahlen.


    Genau.


    Kunden haben zwei Optionen:


    - SNI nutzen
    - eigene IP zusätzlich bezahlen


    Beides ist ja vom SSL-Zertifikat an sich unabhängig.



    Zitat

    In meinem wirren Programmierer-Hirn habe ich eine unscharfe Idee, die ich aber aufgrund der Auftragslage in diesem Leben wohl nicht mehr umsetzen kann:


    Ein Deamon, der HTTPS Anfragen entgegennimmt und cached. Anhand einer Liste interner IPs wird diese Anfrage nacheinander an alle internen IPs gesendet und der Handshake wird getestet. Passt das ausgelieferte Zertifikat, sorgt der Deamon fur ein Forwarding (via iptables oder so) des Clients zum richtigen Zielhost für die Dauer der Session...


    Ok, das ist ... spooky.


    Aber wie gesagt: wird nicht klappen. Woher weiß dein "Proxy" denn, nur anhand der Client-IP(!), was denn nun das "richtige" Zertifikat auf der "richtigen" Backend-IP sein soll?


    Ich bin mir sicher: wenn das Problem gelöst wäre, wäre kein (großer...) Bedarf für SNI gewesen.

  • Ich bin mir sicher: wenn das Problem gelöst wäre, wäre kein (großer...) Bedarf für SNI gewesen.


    Auch wenn das hier schon ein paar Tage her ist; Du hast natürlich Recht und ich hatte einen Knoten in meinem Denkprozess.


    Mittlerweile hat sich das ursprüngliche Problem, nämlich das der WebDav-Client in Windows nicht auf SNI-SSL-Verbindungen eingeht, erledigt. Zumindest unter Win10 läuft das nun.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!