Teljes HTTPS proxy hogyan? [Megoldva]

Linux-haladó

Van egy régi, 2.2-es linux apache szerverem, ami még csak a TLS 1.0-át támogatja.
Szeretném, ha a HTTPS kérelmek teljes kiszolgálását egy-egy VirtualHost-on, tovább küldené egy másik, frissebb webszervernek a háttérben, ami már TLS 1.2-őt is támogat.
Sehogy sem tudom rábírni az Apache szerveremet, hogy ne a fogadó, régi szerver próbálja meg hitelesíteni a kérelmet, hanem a teljes hitelesítési folyamatot proxizza.
Csinált már valaki ilyent? Van ötletetek, ezt hogyan lehet elérni?

  • 1626 megtekintés

( Vizibirka | 2017. 03. 07., k – 13:43 )

Sehogy, mert amit te szeretnel, azt csak TCP tunnellel lehet megcsinalni.

Úgy tűnik, korai volt az örömöm ... Annyi szépséghibája van a dolognak, hogy a kérelemben szereplő HOST-ra feltételt csak mode http alatt tudok tenni. mode tcp alatt a teljes portra érkező forgalmat továbbítja, így a szétválasztásra ez sem képes. :( Ebben a formában ez kb. egy tűzfalszabállyal egyenértékű.

És mégis! :)
A haproxy képes tcp módban sni kezelésére is!
Ha ez valakinek még segítség, itt egy link:
http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/
Most már tökéletesen működik, ezzel be tudom állítani a hostonkénti szétválogatást is.
Még egyszer köszönök minden segítséget!

( joco01 v | 2017. 03. 07., k – 14:14 )

Protokollok rétegződését ajánlom figyelmedbe. Az SSL a TCP fölött, HTTP alatt van. A régi Apache csak akkor tud bármit kezdeni a bejövő kapcsolattal, ha HTTP szinten néz rá, magyarul ki kell csomagolnia az SSL-t (amit állításod szerint nem tud). Ahogy fentebb írták, egy stunnel kibontja az SSL-t az Apache előtt és az Apache már csak a HTTP-t fogja megkapni. Lehet még próbálkozni iptables továbbítással is, ez TCP/IP szinten megy, tehát nem látod a HTTP kérést, nem tudsz pl. az URL alapján különböző backendre továbbítani.

De szerintem leginkább az itt a baj, hogy azt a régi Apache-ot teljesen ki kellene dobni és lecserélni, önmagában is gáz, főleg reverse proxynak használni, csak favágás lesz belőle.

--

Hivatalosan én is úgy tudtam, hogy az Apache nem tudja kibontani az SSL-t, és erre használja az openssl-t a rendszerből... Volt ez akkor, amikor ebből következően megtanították nekem azt is, hogy név alapú virtual host nem lehetséges Apache alatt 1 IP címmel, hisz a hitelesítés az IP címre vonatkozik, és az Apache csak utána jut a hitelesített kérelemhez, amiből felismeri a nevet.
Aztán mégis csak lehetséges név alapú virtual host egy IP-vel. Ezért reméltem, hogy az Apache mégis csak képes továbbítani valahogy a teljes kérelmet kibontatlanul, hisz még hitelesítés előtt felismeri, kinek szól a kérelem.
Tudom, hogy gáz a helyzet, de egy átmeneti megoldás mindenképp kell, míg a végleges el nem készül.

SNI kell ahhoz, hogy a keresnek megfelelo cert/key part valassza ki az apache, ez a resz eddig oke talan nalad is a 2.2-vel. Az SSL handshake az apache es a kliens tortenik igy marad a TLS1.0 protokoll, innentol az apache mar a titkositatlan HTTP forgalmat kezeli, amit ugyan ujra be lehet titkositani, hogy a 2.4-nek atkuldd, de ennek csak akkor van ertelme, ha a ket apache kozotti kapcsolat nem vedett - kulonben csak a procikat dolgoztatot feleslegesen. Egy SSL terminalo proxyt berakhatsz a mostani webszerver ele (ez lehet akar az ujabb apache, vagy haproxy, vagy ...), de ez sem lesz ugy transzparens, ahogy szeretned - azaz a kliens kapcsolata mindig a proxyn fog vegzodni, nem egyik vagy masik webszerveren.

Igen, 2.2 alatt működik a hostnév alapú hitelesítés kiválasztása. Mivel az Apache és a kliens tartja a kapcsolatot, azt el tudom fogadni, hogy az Apache TLS 1.0 felett nem fog tudni semmit.
Tehát az Apache elé kell mindenképp egy proxy, de olyan, amelyik a hostnév alapján képes a tcp forgalmat egyik vagy másik szerver felé továbbítani.
Egyelőre ilyen proxy-t még nem találtam. Sajna a haproxy-ban sem tudom ezt beállítani. (Vagyis be lehet állítani, hibát sem ad, csak tcp módban egyszerűen figyelmen kívül hagyja a httpchk feltételt.