Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Már látom a fényt
az alagút végén...
De, miért dudál?
/Graffiti/
2012. március 1.  
 "Alagút-effektus" 
   
Jó dolog a kriptográfiával biztonságossá tett kommunikációs csatorna, de tény, hogy költséges, sok erőforrást emészthet fel. Ennek vannak látható/hallható jelei pl. egy (SSL/TLS-sel védett) RTMPS-en átfutó video stream-nél, de egy egyszerű, sok kis tranzakciót kezdeményező webes kommunikációnál is komoly lassulás jelentkezhet HTTPS felett. Az okok között megjelenik többek közt a megnövekedett processzor-igény, a hálózati forgalom overhead, amelyek mind-mind értékes ms-okat jelentenek. A jelen bejegyzés inkább az utóbbira összpontosít.

Tételezzük fel, hogy van néhány olyan szolgáltatás, amit viszonylag sűrűn keresünk fel, azoktól adatokat kérünk le, azaz sokszor lefut a CONNECT révén egy-egy teljes SSL/TLS handshake, viszont maga a lekért adatmennyiség nem sokkal több, mint ez az SSL/TLS handshake. Kézenfekvő a kérdés, hogy miért ne lehetne "kimerevíteni" az SSL/TLS réteget, miért ne lehetne a session adatokat ideiglenesen tárolni, tartani (cache)? Szerencsére van erre lehetőség! Először 2006. májusában adtak ki szabványos megoldást az IETF RFC 4507 révén, majd ezt frissítette az IETF RFC 5077 számú leírás 2008. januárjában. A szabványok lényege, hogy lehetővé tesznek egy egyszerűbb SSL/TLS handshake kommunikációt is, amelynél a kezdeményező kliens egy korábban már egyeztetett paraméterlistát ("session_id") játszik vissza (cache). Természetesen a visszajátszásnak, újrahasznosításnak vannak feltételei: a kliens próbálkozásait a szerver oldalnak is jóvá kell hagynia, egy alapbeállítású Apache web server esetében pl. a SSLSessionCacheTimeout 300 másodpercre van állítva, de ez akár még tovább is növelhető, a TLS-ről szóló leírásban felső határértékként 24 óra van megjelölve. Amennyiben a kliens oldalon futó kód valami miatt nem képes ezen adatok tárolására és újrahasznosítására, igénybe lehet venni külső segédalkalmazásokat is, mint pl. az stunnel-t.

Az SSL/TLS handshake különböző fajtái az IETF RFC 5077 szerint:

A jelen esetben, kísérletképpen egy időbélyeg szolgáltatót fogunk meghajtani! A fent leírt feltételek ráillenek egy ilyen kommunikációra, hiszen maguk az időbélyeg kérések (kb. 70 byte) és időbélyeg válaszok (kb. 2 kB) kis adatok. A kísérleti környezet elektronikus aláírásokat hoz létre, az egyes műveletek időigényén, ami kb. 2,5 másodperc azonban egyértelműen látszik, hogy kb. 1,5 másodpercet az időbélyeg visz el. Ilyen rendszereknél tehát nem is drága HSM-eket kell venni, mert nem a kulcsokkal való kódolás a nehéz munka, sőt, kisebb (<1 MB) adatok aláírásánál még a lenyomatszámítás is pillanatok alatt megvan, a lassúságot, a szűk keresztmetszetet a hálózati kommunikáció jelenti. A rendszerek méretezésénél viszont figyelni kell arra, hogy pl. egy közmű szolgáltatónál Magyarországon nem ritka, hogy a hónapzárás után 2 napon belül ki kell állítani majdnem 4 millió e-számlát a végfelhasználók számára, de e-közigazgatási rendszernél is jogszabáyi előírások léteznek bizonyos szervezeteknél, amelyek alapján az állampolgártól, cégtől származó beadványokra X napon belül hiteles, elektronikus választ kell kiküldeni. Ezekben a "darálós" esetekben bizony minden ms számít...

Az stunnel nélküli kísérleti esetnél látszik, hogy az első kapcsolatfelépítésnél (vagy ha nincsen SSL/TLS session cache beállítva), akkor végigmegy a teljes handshake (ld. alábbi képen). A "ClientHello" nem küld már korábban letárolt "session_id" adatot csak az újonnan létrehozott "challenge" véletlenszámot ("ClientHello.random").

Az stunnel segítségével tárolt session adatok újrahasznosítása esetén azonban látható, hogy a már korábban egyeztetett "session_id" elküldésre kerül, és a "ClientHello" után a szervertől már jön is a "ChangeCipherSpec" jelzőüzenet, amely szerint ezután már minden adat rejtjelezett lesz.

A Wireshark-kal készített képeken tehát látszik, hogy melyik esetben volt közvetlen elérés, illetve melyik esetben volt egy stunnel által létrehozott csatornán keresztül meghajtva az időbélyeg szolgáltató. Hogy mennyit számított ez? Egymás után - amennyire lehet azonos peremfeltételek mentén - végrehajtott mérések során (100 darabos csomagokkal) az időbélyegek beszerzése által igényelt kb. 1,5 másodperc/darab 0,8 másodperc/darabra csökkent, azaz ez a részfolyamat 45-50%-kal, a teljes aláírás-létrehozási funkció pedig 30-35%-kal lett gyorsabb az SSL/TLS cache-nek köszönhetően. Aki szeretne játszadozni, annak segítségül alább látható a használt stunnel konfiguráció (a "connect" URL-t értelemszerűen kell kitölteni).

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info