Fórumok
Sziasztok,
Adott 2 process (a,b) akik egy siman tcp socketen tartják a kapcsolatot. B processnek van egy openssl/boost::asio listen portja, ahol varja a bejovo kapcsolatokat majd megcsinalja a tls handshaket. Ha ez meg van, szeretnem atadni az A process-nek az ssl sessiont. Maga a tcp layeren levo socket file descriptor atadasa mar megoldott, az mukodik, de a session atadassal gondjaim vannak. Elvileg a i2d_ssl_session/d2i_ssl_session-al serializalhato a teljes session context, de egyelore hibat dob ha az atadott ssl socketen megprobalom folytatni a kommunikaciot.
Foglalkozott mar valaki hasonloval?
Hozzászólások
a szerverek nem hasonlokeppen csinaljak? pl. webszerver.
nem tudom csak kerdem, azok is megoldjak valahogy, hatha a forrasuk mond valamit.
neked aztan fura humorod van...
Nem, ott a socket file handler másolásra kerül a fork-kor és utána jön az SSL. (Vagy eleve többszálú és nem indít minden session-nek process-t.)
https://naszta.hu
ez a megoldas mukodik.
ha a session transfer trukk nem jon ossze, akkor marad ez a megoldas.
milyen elonye lenne annak a megoldasnak amit fent vazoltal ahhoz kepest mint amit a webszerver csinal?
neked aztan fura humorod van...
B process, aki az SSL handshake-et bonyolitana nobody user alatt fut, nagyon keves jogosultsaga van. Ha meghekkelik, akkor meg mindig nem jutottak el a root alatt futo A processig. Persze tudom, az mar onnan egy lepes, mivel van egy allando kapcsolat a 2 process kozt.
Az a baj, hogy a megoldásodban a handshake utáni részben viszont már az A processzben zajlik az SSL forgalmazás.
Szerintem biztonságilag tisztább és egyszerűbb a reverse proxys megoldás - még akkor is, ha overheadben azért nagyobb. Cserébe bármilyen kiforrott idegen reverse proxy kódot is használhatsz.
> Ha meghekkelik, akkor meg mindig nem jutottak el a root alatt futo A processig.
Viszont ha nem hekkelik meg, akkor te átadod a kapcsolatot az A processznek, hogy meghekkelhessék azt.
Webszervernél a tipikus megoldás az, hogy van egy "előtét", ami az SSL-t csinálja, és tovább proxyzza a kéréseket immáron titkosítatlan HTTP kérésekkel. Tehát az SSL egy processzben van, és a lényegi forgalom a valódi kiszolgálótól az előtéten is átmegy. Legalábbis én így raktam össze a játszós szerveremen és mindenhol azt olvasom, hogy ez egy tipikus megoldás. Egy minimális plusz erőforrás igénye van, ha nagy sávszélességet kell kiszolgálni, akkor nem jó, de minden másra megfelel.
nem tudod... az ssl contextet ha át is tudnád adni, mi garantálja neked, hogy a 2 processz pl. ugyanazt az ssl lib verziót használja, stb.
másképp kell megoldani a problémát, imho
elfelejtettem irni, hogy B process az A forkja.
Két irány lenne ilyen esetben:
- Az egyik az "egyszerűbb": Kernel TLS, így csak az fd-t egyszerűen átdobod minden macera nélkül
- A másik amikor context sharing -et próbálsz mint most. Az irány teljesen jó, úgy kell ahogy írtad, viszont a "de egyelore hibat dob ha az atadott ssl socketen megprobalom folytatni a kommunikaciot." kevés, jó lenne látni, hogy milyen hibát dob :) Illetve ha a túloldalon visszaolvasod a session-t, azt vissza kell illeszteni a teljes context -be SSL_CTX_add_session -el
// Happy debugging, suckers
#define true (rand() > 10)
Igen, az SSL_CTX_add_session hiba nelkul lefut. Idokozben meg annyival kiegeszitettem a dolgot, hogy a master key-t is atviszem a masik oldalra. Szerintem az lehet a gond, hogy az SSL "PINIT" statuszban marad, nem pedig "TLSOK". Ha ilyen allapotban probalok kommunikalni, mivel a kliens mar tul van az handshake-en, a szerver oldali ujjonnan letrejott, de reszben visszaallitott session meg nem.
Az SSL statem status nem publikus, igy nem jo szivvel irnam felul, meg ha lenne is lehetosegen openssl headereken keresztul.
Pedig ha jol emlekszem, a state -et neked kezzel kell atbillenteni, mert a session data-ba csak a handshake -nel egymassal lebeszelt adatok lesznek meg. Esetedben pedig nem egy mar meglevo session -t akarsz ujra feleleszteni cache-bol, hanem egy meg elot folytatni
// Happy debugging, suckers
#define true (rand() > 10)
Ugy nez ki nem segit rajta ha session visszaallitasa utan beallitom a state-et TLS_ST_OK-ra, ami normal handshake utan szokott lenni. Az elso IO-nal dob egy ssl3_read_bytes hibat.
Én csak SSL_accept/connect előtt vittem át session-t, és az is régen volt. Emlékeim szerint valami ilyenek kellettek:
Tudom, hogy te mást csinálsz, csak az jutott eszembe, hogy a processzek közötti eltérő session cache vagy session id context inicializáció a processzek között valahogy megfekszi az OpenSSL gyomrát...
azt erzem itt valamit nagyon nem ugy csinalsz ahogy kene. erre kesz megoldasok vannak (nem te vagy az elso akinek ilyen kene), hogy a szulo fogadja tcp kapcsolatot, megcsinalja amit kell a kapcsolat felepiteshez, utana meg mar egy gyerek process dolgozza fel az adatokat. csak fel kell turni a netet. foleg ha meg olyat is hasznalsz hogy boost::*
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!