"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

Frage zu HTTPS reverse Proxy auf Apache

GrandAdmiralThrawn 19.11.2019 - 15:14 2618 17
Posts

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3482
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.

nexus_VI

Overnumerousness!
Avatar
Registered: Aug 2006
Location: südstadt
Posts: 3070
Habe einige Nginx Instanzen so laufen, als SSL Offloader. Setze dort dann einfach HTTPS=1, bzw eventuell versteht die Applikation dahinter den X-Forwarded-Proto Header, dann ist das nicht notwendig. Im Nginx reicht eine sehr überschaubare proxy_pass Direktive, kann dir gern ein Beispiel nachreichen.

Imho geht das mit Nginx einfacher und komfortabler, den kannst du z.b. auch vom Certbot konfigurieren und falls nötig (Zert erneuert) reloaden lassen ...

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3482
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. ugly_240877.gif

davebastard

Vinyl-Sammler
Avatar
Registered: Jun 2002
Location: wean
Posts: 8575
verwende ebenso nginx öfters in dieser art und weise. Wozu ist das stunnel gut ? alles hinter dem reverse proxy ist doch eh nicht von außen erreichbar.

edit: achso, stunnel ALS reverse proxy, davon würd ich auch absehen, ist nicht dafür gemacht.
Bearbeitet von davebastard am 19.11.2019, 15:33

COLOSSUS

# pkill -9 .
Avatar
Registered: Dec 2000
Location: Wien || Stmk
Posts: 10927
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.

nexus_VI

Overnumerousness!
Avatar
Registered: Aug 2006
Location: südstadt
Posts: 3070
Ja, ist bei uns u.a. eine Performancefrage für SaaS Angebote, aber wurscht, könnte auch dein Problem lösen.

Selbstgebautes Skript weghauen, Certbot (ACME) Client und Nginx installieren (da reicht das kleinste Paket, nicht so winzig wie stunnel aber überschaubar) wäre mein Vorschlag.

Und in einem weiteren Schritt dann den Apache als Backend loswerden, da sind wir gerade dabei ;)

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

COLOSSUS

# pkill -9 .
Avatar
Registered: Dec 2000
Location: Wien || Stmk
Posts: 10927
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.

nexus_VI

Overnumerousness!
Avatar
Registered: Aug 2006
Location: südstadt
Posts: 3070
Richtig, eine augenscheinlich uninformierte Entscheidung - aber funktioniert hats ;)

COLOSSUS

# pkill -9 .
Avatar
Registered: Dec 2000
Location: Wien || Stmk
Posts: 10927
:D

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3482
Danke erst Mal für den Input.

Soll heißen, wenn ich das Protokoll nur "dumm" wrappe, dann würde mod_rewrite von HTTP auf HTTPS am "unsicheren" Webserver failen, weil er von z.B. stunnel kommend immer nur HTTP Requests bekommt? Also, der "sieht" dann nicht, daß der Client HTTPS zum Proxy hat?

Wenn man dafür besagte Intelligenz im Proxy (und am Backend Server) braucht, dann ist meine "simple" Idee eh hinfällig.

bsox

Schwarze Socke
Avatar
Registered: Jun 2009
Location: Dschibuti
Posts: 801
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.

nexus_VI

Overnumerousness!
Avatar
Registered: Aug 2006
Location: südstadt
Posts: 3070
Zitat aus einem Post von GrandAdmiralThrawn
Danke erst Mal für den Input.

Soll heißen, wenn ich das Protokoll nur "dumm" wrappe, dann würde mod_rewrite von HTTP auf HTTPS am "unsicheren" Webserver failen, weil er von z.B. stunnel kommend immer nur HTTP Requests bekommt? Also, der "sieht" dann nicht, daß der Client HTTPS zum Proxy hat?

Wenn man dafür besagte Intelligenz im Proxy (und am Backend Server) braucht, dann ist meine "simple" Idee eh hinfällig.
Irgendeine Methode muss das Backend üblicherweise eh haben um festzustellen welches Scheme es zu liefern hat. In unserem Fall wurde von der Applikation (glaube das ist üblich) die $_SERVER['HTTPS'] ausgewertet, die hab ich daher vom Reverse Proxy setzen lassen. Läuft alles tadellos mit "dummem" Backend.

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 41419
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

GrandAdmiralThrawn

XP Nazi
Avatar
Registered: Aug 2000
Location: BRUCK!
Posts: 3482
Ich weiß nicht Mal was "HTTPS Terminierung" bedeutet. ;)

Also wie gesagt, für IMAPS, POP3S, eingehendes SMTPS und diverse simple HTTPS Interfaces (nicht über Apache) funktioniert das mit stunnel wunderbar. Also überall da, wo das Protokoll implizit ist, und nichts am Protokoll selbst modifiziert werden muß. Für eingehendes SMTPES (also explizites TLS über SMTP) unterstützt's eine Teilmenge des SMTP Protokolls, um das gangbar zu machen - halt grade nur zum Aushandeln der Verschlüsselung über STARTTLS (oder sowas) im Kontext des SMTP Protokolls, kA wie es genau funzt.

Für HTTPS existiert sowas in stunnel m.W.n. nicht. Ich kann also stunnel nicht ins Protokoll so wie es zwischen Proxy und Backend Server gesprochen wird eingreifen lassen.

Damit ist das ganze so wie von mir ursprünglich geplant wohl hinfällig. Ich schätze es würde gehen, wenn ich nicht mod_rewrite brauchen würde, um für gewisse Ressourcen HTTPS zu erzwingen...

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?

Zumindest nehme ich Mal an, daß darin ein mit stunnel nicht lösbares Problem liegt?

Oder liege ich da falsch?

davebastard

Vinyl-Sammler
Avatar
Registered: Jun 2002
Location: wean
Posts: 8575
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"
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz