Vlákno názorů k článku Velká řešení otevřeně: load balancing s HAProxy od lojzak - Terminace TLS na load balanceru a následná nešifrovaná...
-
Terminace ssl spojeni na balancerech je naprosto standardni reseni - rika se tomu SSL Akcelerator. Sit za loadbalancerem ale musite mit pod kontrolou a nesmite tam pripojit cizi zarizeni. Pokud stavite cluster pro jednoho zakaznika s vlastni vnitrni siti, tak opravdu neni zadny rozumny duvod tento scenar nepouzit. Tech par procent usetreneho vykonu se Vam muze ve spicce hodit.
-
MP (neregistrovaný)
Zase na druhou stranu, ve chvili, kdy potrebujete presmerovat backend nekam mimo, klidne i pres nechranene site, tak je lepsi nemit terminaci ssl na balanceru. Jeste resenim je mit reencrypt setup, kdy se pouzije HTTP rezim s ssl offload, ale smerem na backend se to zase zasifruje.
Ja to ted prave rozjizdim v testovacim rezimu a taktez hodne vaham nad TCP/HTTP rezimem. Jednak z duvodu prave Let's Encrypt a uloziste pro certifikaty a nutnost jejich prenos na balancery/aplikacni servery v ruznem formatu, jednak z duvodu, ze jsem ted nasazoval jednu apache proxy pro websockety a byly s tim problemy, nez se naslo konfiguracni reseni. TCP je jednoduchost, ale nevyhodou je prave nemoznost to filtrovat na urovni L7.
-
. . (neregistrovaný)
terminovat SSL spojení na balanceru je pro homogenní systémy lepší řešení, držíš tím soukromé klíče na jednom místě a dobře chráněné, než když je má k dispozici aplikační kód či mnoho dalších jednotek.
Nic ti ale nebrání, aby backend komunikace byla chráněná vlastní ssl/tls vrstvou, tohle řešení běžně používám a implementuji i klientů.
Websocket na to je velice špatně navržený a v kombinaci s node.js to může být průser. HTTP/2 umožňuje v jednodušším režimu rovnou jeho terminaci na balanceru a následnou komunikaci přes HTTP na backend. Pokud máš potřebu HTTP/2 dostat až k samotné aplikaci (jak to dělá třeba google), je vhodné z aplikace odstranit doménovou logiku a udělat z ní jen transparentní collector pro data z dalších backendů.
Je neskutečně rizikové v jednom aplikačním vlákně dešifrovat data a zároveň tam provádět doménové operace, řada programovacích jazyků/knihoven/compilerů nenuluje data při uvolnění (či alokaci) paměti a může dojít k úniku soukromých klíčů, zejména kritické to je v dynamických jazycích s GC (php, node.js, python, lua, java).
-
MP (neregistrovaný)
Tak, pokud maji mit klice k dispozici balancery v chranene zone, ale pristupne zvenku, nebo nginxy v interni zone, tak to uz vyjde z meho pohledu nastejno ve chvili, kdyz hodlam mit tls po cele trase. Interni certifikaty na to nasazovat nechci (ani na to nemam automatiku), takze je pro me jednodussi pouzit tcp variantu. V obou pripadech stejne musim delat synchronizaci certifikatu na vice stroju. Rozhodne tim nezavrhuji http variantu, mozna na ni casem prejdeme, nebyt let's encrypt, tak snad ani nevaham.
-
. . (neregistrovaný)
samozřejmě, pokud máš takovýhou infrastrukturu, moc velký rozdíl v tom není, ale na backendu můžeš mít mnohem více technologií než nginx nebo v budoucnu dojde k rozšíření a pak to je problematické.
Terminací SSL/TSL vrstvy na backendu přicházíš o možnost znovupoužívání SSL/TLS session a musí se pro každý backend vytvářet nová (její synchronizace a udržování na centralizovaném uložišti je technicky náročnější), tím zbytečně prodlužuješ načítání stránek.
Balancování pouze TCP kanálu může dojít k ne optimálnímu využití zdrojů, stejně tak nedokážeš efektivně využívat cache pro statické soubory, ty ale zase můžeš mít někde jinde v CDN.
ČLÁNKY DO MAILU