Frage zu HTTPS reverse Proxy auf Apache

Ich frage Mal in die Runde, weil ich so etwas selbst noch nie gemacht habe. Ich habe einen Apache Server, gelinked gegen ein etwas zu altes OpenSSL (sodaß manche moderne Browser mittlerweile davor warnen).

Meine Idee: HTTPS in Apache komplett abdrehen, Reverse Proxy davorsetzen (z.B. mit stunnel), den kompiliere und linke ich selber gegen ein neueres OpenSSL, weil simpel genug. Dann Verbindungen mit stunnel auf Port 443 in sicheres TLS packen, und danach auf den HTTP Server auf Port 80 umleiten.

Also so:

Client, der HTTPS anfordert --sicheres HTTPS über Internet--> stunnel TLS server/proxy, Port 443 --plain local HTTP--> Apache HTTPd, Port 80.

stunnel würde ich hier auf derselben Maschine wie den Webserver setzen, dann ginge der Plaintextverkehr zwischen Reverse Proxy und Webserver eben direkt über localhost und nicht über ein LAN.

Die Frage ist jetzt, ob Apache sowas mag, speziell was mod_rewrite Regeln angeht, die dann z.B. gewisse URLs auf HTTPS umschreiben, falls ein Client versucht per plain HTTP auf eine Seite zuzugreifen, die Verschlüsselung erfordert. Ich meine, soweit ich das Setup verstehe müßte das schon weiterhin gehen, aber vielleicht hat ja jemand mit dieser Art von Reverse Proxy (negative?) Erfahrungen, und weiß worauf man achten muß. Bisher habe ich sowas nur für Mailserver und simple in Python geschriebene Webserver gemacht.

btw., "Hau weg, eh alles viel zu alt und unsicher" => Verstehe es, wenn jemand sowas postet, hilft mir aber nicht weiter, weil in dem Fall keine Option.

Danke!

Wenn keiner etwas weiß, probier' ich das halt irgendwann einfach Mal aus.

Zerts handle ich bereits über ein Skript von mir. Das is Let's Encrypt in meinem Fall, die erneuere ich, und im selben Zug werden alle TLS-enabled Server neu gestartet, fertig.

Mit Nginx habe ich allerdings überhaupt keine Erfahrungen, bin da halt an Apache gebunden und stunnel ist recht winzig und flott..

Bei dir geht's wahrscheinlich um die Performance wegen TLS Handshaking? Bei mir geht's mehr darum einen rostigen alten Kahn mit Duct Tape zu flicken.

Fuer ziemlich genau solche Faelle gibt es (limitierte) Intelligenz in Reverse Proxies, die HTTP Response Header parsen und nach bestimmten Regeln editieren, und z. B. Redirects des Origin vom http- auf das https-scheme umschreiben. Aus diesem Grund wuerde ich auch nicht nur mit primitivem TLS Unwrapping (via stunnel, und danach plain L4/TCP weiter zu deinem Apache httpd) arbeiten, sondern mit einem ausgewachsenen, RFC-konformen HTTPS Reverse Proxy. nginx, haproxy, hitch, Apache httpd (in neuerer Version als deiner), Caddy, ... bieten sich alle an; die Auswahl ist endlos. Am besten ist aber natuerlich, wenn die Applikation im Backend weisz, dass und wie sie reverse proxied wird, und entsprechend kooperiert (z. B. Redirects schon vom Origin aus auf den explizit konfigurierten Canonical VHost/URI verweisen).


Auf der Apache httpd-Seite dahinter (also am Origin) bietet sich der Einsatz von mod_remoteip an, wo die Information ueber die IP-Adresse des TCP Peers in einem HTTP Request Header des Reverse Proxies transportiert wird, um sich in Access-Logs et al. keine hohen Migrationsaufwaende einzutreten. Apache httpd (ab 2.4, iirc) unterstuetzt damit auch das PROXY-Protokoll, aber damit habe ich keine praktischen Erfarhungen.


Ceterum censeo hau weg, eh alles viel zu alt und unsicher.

Zitat aus einem Post von nexus_VI

edit: @COLOSSUS mod_rpaf haben wir da mit Apache hergenommen.

Halte ich fuer die summa summarum schlechtere Wahl als mod_remoteip (obwohl es weniger konfus zu konfigurieren scheint ), da afaict 3rd-Party.

Ich verwend' haproxy für genau solche Sachen. Das ist vielfach wesentlich einfacher als irgendeiner dahergelaufenen Applikation TLS und das automatisierte Zertifikathandling einzuimpfen.

Eine feine Lösung ist z.B. Opnsense. Dort kannst Dir Deine haproxy Frontends, Backends und Regeln im GUI zusammenstöpseln und Letsencrypt Zertifikate werden automatisiert aktualisiert. (Pfsense kann das sicher auch, hab ich aber schon lange nicht mehr in den Fingern gehabt.)

Und haproxy standalone mit einem kleinen Configfile manuell gewartet geht natürlich sowieso.

Ich versteh ned ganz wie stunnel das Problem lösen soll.
Das baut dir einen Tunnel zwischen zwei Endpunkten.

Du brauchst aber einen proxy bzw Webserver der dir die https Terminierung macht

Zitat

Weil so wie ich das verstehe, sähe Apache jetzt eine HTTP Verbindung zur Ressource (nehmen wir Mal an, der Client hätte wirklich HTTP versucht). So, jetzt schreibt er das auf HTTPS um, der Client connected zur HTTPS URL und landet jetzt am stunnel Proxy, der auf 443 lauscht. Der decrypted die Connection, und leitet sie per HTTP an den Backend Apache weiter, der wieder nur "HTTP" erkennt (weil stunnel zu "dumm" ist?), und mod_rewrite schreibt erneut um... quasi eine Endlossschleife?

das kann gut sein, der rewrite von http auf https is ja auch an der falschen stelle, das ghört imho in den nginx/haproxy/younameit . stunnel is halt einfach das falsche "werkzeug"