Stručnjaci sve češće upozoravaju da jedan od najneprimetnijih, ali najskupljih uzroka loših performansi modernih aplikacija može biti upravo SSL/TLS sloj. Iako se već decenijama posmatra kao neupitan stub bezbednosti interneta, ovaj protokol sve češće pokazuje i svoju slabost: značajno opterećenje procesora i povećanu latenciju, naročito u sistemima sa velikim brojem kratkotrajnih konekcija.
Kada bezbednost postane trošak
Svaka nova bezbedna konekcija zahteva određenu količinu resursa. U sistemima koji obrađuju stotine ili hiljade kratkotrajnih zahteva u sekundi, taj trošak se brzo akumulira, i u vidu latencije i u vidu opterećenja procesora.
Dok većina razvojnih timova pažnju posvećuje optimizaciji baza podataka, rešavanju N+1 upita i finom podešavanju mikroservisa, deo problema često ostaje skriven u sloju koji se podrazumeva, u SSL/TLS protokolu.
Većina programera ga posmatra kao jednostavan bezbednosni omotač, onaj „katancić“ u pregledaču ili „S“ u HTTPS-u, ali SSL/TLS je zapravo aktivan proces koji uključuje složene kriptografske operacije. Taj proces se odvija pri gotovo svakoj novoj bezbednoj konekciji i troši značajnu količinu procesorskih ciklusa.
Kako funkcioniše rukovanje i zašto usporava sistem
Proces uspostavljanja bezbedne konekcije nije jednostavan. Nakon osnovnog TCP rukovanja, TLS dodaje svoj niz koraka: pozdravne poruke (ClientHello, ServerHello), razmenu sertifikata i generisanje ključeva. Upravo ovaj poslednji korak, koji koristi asimetričnu kriptografiju, najviše opterećuje procesor.
Kako je objasnio softverski inženjer Husein Naser u svom predavanju „Anatomy of a Request: Beyond Backend Processing“, TLS rukovanje predstavlja „ples“ koji počinje mnogo pre nego što serverska logika uopšte vidi zahtev. Svaka razmena ključeva zahteva kompleksnu matematičku obradu i zauzima resurse koji bi inače bili dostupni aplikacionom sloju.
Upoređeno slikovito, TLS rukovanje je poput bezbednosne kontrole na ulazu u zgradu. Sama po sebi, ona je neophodna, ali ako se mora prolaziti pri svakoj poseti, sistem brzo postaje neefikasan.
Kada milisekunde postanu problem
Jedno rukovanje traje svega nekoliko desetina milisekundi, ali u sistemima koji obrađuju ogroman broj zahteva to postaje ozbiljan faktor.
Na primer, u e-commerce API-ju koji procesuira 1.000 zahteva u sekundi, ako 30 odsto njih inicira novo TLS rukovanje, to znači 300 kriptografskih pregovora svake sekunde i isto toliko dodatnih opterećenja procesora.
Savremeni protokoli donekle ublažavaju problem. HTTP/1.1 keep-alive, HTTP/2 multipleksiranje i HTTP/3 QUIC omogućavaju deljenje konekcija, dok TLS 1.3 uvodi mehanizme kao što su 0-RTT (zero round-trip time) i session resumption, čime se smanjuje potreba za ponovnim rukovanjem.
Ipak, u aplikacijama koje ne koriste connection pooling ili u okruženjima sa čestim prekidima konekcija, ovi troškovi se brzo sabiraju. Rezultat su veća latencija, veće opterećenje procesora i viši troškovi infrastrukture.
Primer iz prakse: OpenSSL 3 i pad performansi
Ono što je dugo delovalo kao teorijski rizik postalo je stvaran problem kada je biblioteka OpenSSL u verziji 3.x izazvala drastičan pad performansi. Istraživanja su pokazala da je nova verzija, namenjena dugoročnoj podršci, u nekim višestruko opterećenim okruženjima radila i do 99 odsto sporije od prethodne.
Umesto očekivanog skaliranja sa brojem procesorskih jezgara, performanse su se pogoršavale. Organizacije su bile primorane da biraju između bezbednosti i brzine: da nadograde i trpe pad performansi, ili da ostanu na starijoj verziji i rizikuju bezbednosne propuste. U pojedinim slučajevima, za isti nivo usluge bilo je potrebno i do 42 puta više hardverskih resursa.
Srećom, novije verzije kao što je OpenSSL 3.5 ispravile su većinu problema i ponovo postale preporučene za upotrebu, iako njihov dizajn i dalje nije idealan pod ekstremnim opterećenjem.
Kako se problem može ublažiti
Stručnjaci ističu da SSL/TLS sloj ne bi trebalo tretirati kao zatvoreni sistem. Kao i aplikacioni kod, on mora da se prati, meri i optimizuje.
Nekoliko preporučenih koraka uključuje:
- Profilisanje van aplikacije: merenjem potrošnje procesora kroz alate za profilisanje često se otkriva da funkcije poput SSL_read ili SSL_write troše neočekivano mnogo resursa.
- Poznavanje biblioteke: važno je znati da li sistem koristi OpenSSL, BoringSSL, LibreSSL ili AWS-LC, jer razlike u performansama i načinu implementacije mogu biti značajne.
- Sistemsko podešavanje: fino podešavanje TCP parametara, veličine bafera i broja aktivnih konekcija može doprineti stabilnijem radu sa velikim brojem bezbednih zahteva.
- Smanjenje broja rukovanja: connection pooling, omogućavanje HTTP/2 ili HTTP/3 i korišćenje TLS session resumption mehanizama mogu znatno smanjiti opterećenje.
Temelj koji nosi, ali i ograničava
SSL/TLS ostaje osnov bezbedne komunikacije na internetu, ali istovremeno pokazuje da nijedan sloj sistema nije besplatan. Razumevanjem njegovih troškova, merenjem uticaja i pažljivim izborom protokola i biblioteka, razvojni timovi mogu da obezbede da bezbednost ne postane neprijatelj performansi.