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?
- 493 megtekintés
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...
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
ez a megoldas mukodik.
ha a session transfer trukk nem jon ossze, akkor marad ez a megoldas.
- A hozzászóláshoz be kell jelentkezni
milyen elonye lenne annak a megoldasnak amit fent vazoltal ahhoz kepest mint amit a webszerver csinal?
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
elfelejtettem irni, hogy B process az A forkja.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Én csak SSL_accept/connect előtt vittem át session-t, és az is régen volt. Emlékeim szerint valami ilyenek kellettek:
- SSL_CTX_set_session_id_context
- SSL_CTX_set_session_cache_mode
- SSL_CTX_set_timeout
- SSL_CTX_get_tlsext_ticket_keys / SSL_CTX_set_tlsext_ticket_keys
- i2d_SSL_SESSION / d2i_SSL_SESSION
- SSL_set_session
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...
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni