php alapú programok https probléma

Fórumok

Helo!

 

Segítséget szeretnék kérni ahhoz, hogy mi mászhatott el. Először egy moodle-nél jött elő, bizonyos belső linkek átváltanak maguktól https-re. Persze ilyenkor jön a hibaüzenet, hogy nincs valid cert... bár már azt se értem, hogy oldja fel az nginx, mikor https-re nincs is figyelése.

Aztán jött a mediawiki. Itt már az elejétől átvált https-be, pedig nincs beállítva.

Ami közös, hogy frissült a php és nginx mindkét helyen. Frissíteni kellene a szoftvereket? A moodle már kapott frissítést, igaz nem a legújabbat.

 

Köszi a segítséget. Ha valami nem világos, kérdezzetek :)

Hozzászólások

Szerkesztve: 2021. 09. 17., p – 13:32

Ha publikus szolgáltatás, akkor mi az akadálya annak, hogy elfelejtsd végre a http-t meg a self-signed vagy még az se certet? Jó esély van arra is, hogy a böngésző először https-en kérdez, és csak ha explicit megadod, hogy http://, akkor fordul plain textben a kiszolgálóhoz.

HSTS is lehet. Ha akar csak 1x is kapott a bongeszo adott IP/Domainrol HSTS cookiet a bongeszo, akkor utana soha meg sem probal plain http sessiont nyitni az adott host fele. Fel is vesi a sajat kis adatbazisaba ahonnan egyreszol korulmenyes kiirtani masreszrol ha veletlen megint kap egyet akkor kezdodik elolrol az egesz.

(Portok kulonbozosege is figyelmen kivul van hagyva. Eleg egy szolgaltatastol kapni HSTS-t es az egesz host meg lesz markolva HTTPS-onlynak)

 

Manapsag mar tenyleg “olcsobb” elore menekulni es beallitani a normalis https-t. 

Felejtsd el a plain HTTP-t, mert lassan eljutunk oda, hogy a bongeszok sem fogjak tamogatni.

Nalunk pl a service-ek kozott, meg ha ugyanazon a hoston futnak is, kotelezo a mutual-TLS. 

Bár messziről jól néz ki, hogy mindenki erős azonosításhoz és titkos csatornához köti kivel kommunikál, de virtuális környezetben ezt hogy csinálod jól? Honnan lesz entrópiád a titkosításhoz? Mert ugye ha az nincs akkor némi CPU égetésen kívül csak hamis biztonságérzetet kelt. Hogyan kerülöd el, hogy a cert lejáratoknál ne sérüljön a szolgáltatás amikor sok száz különböző apró szolgáltatásban kéne cserélni? Ha ráépítesz a vas képességeire (pl vTPM), akkor meg elveszted a virtualizáció adta rugalmasságot. 

Nagyon nem triviális ezt jól csinálni, anélkül pedig nem jelent előnyt. 

"Hogyan kerülöd el, hogy a cert lejáratoknál ne sérüljön a szolgáltatás amikor sok száz különböző apró szolgáltatásban kéne cserélni?" - Jó tervezéssel. Ha 123 apró szolgáltatásod van, és mind külön certet használ, akkor megfelelő konfig menedzsmenttel oda kell alájuk tolni a certet, és adni az ssl-t végződtető komponensnek egy "taslit", hogy olvassa fel az új certet, és a jövőben azt használja. Ez mind jól automatizálható.
Ha meg az az 123 darab szolgáltatás olyan k. fontos, akkor célszerűen egy LB/HA fronteded van előtte, ahol az SSL-t egy helyen végződteted. Az egyiken cserélsz, átbillented a szolgáltatást, majd a másikon is cserélsz, és örömködzs vala neki.
persze ha a szolgáltatásod nem bírja elviselni, hogy egyik kapcsolat az egyik ssl-termináló FE-en, a másik meg egy másikon végződik, az így járt - picit máshol, mélyebben kell áttervezni a működést.

"a https túl nagy load-ot tesz rá" - akkor az ssl-terminálást ki kell pakolni egy erre szolgáló ha/lb eszközre (sw/appliance, terheléstől függően). Bár mondjuk egy jó ideje már értelmes CPU-k esetében a "titkosítás túl nagy plusz terhelést jelent" egyszerűen nem igaz - ahol meg annyira nagy a forgalom, hogy de, még egy korszerű CPU is "izzad" miatta, ott amúgy is ideje a rendszer skálázhatóságát átgondolni, és darabolni/forgalmat osztani/stb.
A beágyazott rendszerek, ha és amennyiben zárt, teljesen szeparált, fizikailag is védett hálózaton beszélgetnek, akkor nyugodtan beszélgessenek plain text protokollokon - senkit sem fog zavarni.
Volt szerencsém olyan audithoz, ahol belekötöttek abba, hogy két gép között rsh/rcp/telnet/ftp volt használatban, "mert ha valaki hozzáfér a gépek közötti hálózathoz, akkor..." - megmutattuk az auditot végző fiatal srácnak azt a bizonyos hálózatot... Egy 1feet hosszú UTP kábelt egy kifejezetten szűk kör számára elérhető gépterembe lerakott secure rack-ben egymás fölött lévő két gép között... Na akkor megnyugodott :-) és remélhetőleg megértette a "kockázatarányos védelem" fogalmát is :-D