A nagy vállalatok és szolgáltatók különféle biztonsági intézkedésekkel próbálják visszaszerezni ügyfeleik bizalmát, amit alaposan kikezdtek a megfigyelési botrányok. A Yahoo! alapértelmezetté teszi a titkosított (HTTPS-alapú) kommunikációt, a Google 2048 bitesre cseréli digitális tanúsítványait, a Microsoft pedig az Office 365-ben titkosítási szolgáltatást nyújt a levelezéshez. A sorba most a Twitter is beállt. Miután tavasszal bevezette a kétfaktoros azonosítást (http://bitport.hu/ketfaktoros-azonositassal-erositik-a-twitter-biztonsagat), most a titkosítás javításával növeli a szolgáltatás biztonságát.

HTTPS-kommunikáció forward secrecy-vel erősítve

A Twitter mintegy másfél éve tette alapértelmezetté tette a HTTPS-alapú kommunikációt. Az akkor bevezetett eljárások azonban még nem feleltek meg minden szempontból az üzemeltetők elvárásainak, ezért most a vállalat megteremtette az úgynevezett forward secrecy támogatásához szükséges feltételeket is.

A forward secrecy révén a hálózati adatforgalom – főleg utólagos – lehallgatása, visszafejtése válik nehezebbé. A hagyományos HTTPS-alapú kommunikáció során a szerveren tárolódik egy titkos kulcs, ami ha illetéktelen kezekbe kerül, akkor a dekódolás viszonylag egyszerűvé válik. Ezzel szemben a forward secrecy alkalmazásakor rendszeresen változik, cserélődik a kulcs.

A kapcsolat tulajdonságai a Chrome-ban

Jacob Hoffman-Andrews, a Twitter biztonsági mérnöke elmondta, hogy a kulcsforgatáshoz egy új rendszert vezettek be, amely egyrészt hibatűrő architektúrára épül, másrészt minden tizenkettedik órában új kulcsot generál. A régi kulcsokat 16 óránként semmisíti meg. A szakember hangsúlyozta, hogy az adatokat egy átmeneti tárolón (tempfs) tárolják olyan környezetekben, ahol nincsenek konfigurálva swap partíciók. Ezzel elkerülhető, hogy a kulcsok bárhol is megőrződjenek a memórián kívül.

A forward secrecy támogatásához engedélyezték az ún. EC Diffie-Hellman kulcscsere algoritmus használatát. A Diffie-Hellman kulcscserének alapvetően két típusa létezik. A hagyományosnak nevezett típus jóval több CPU erőforrást igényel, mint az RSA. Van azonban az eljárásnak egy módosított változata is, az ECDH (Elliptic Curve Diffie-Hellman), ami viszont csak kis mértékben költségesebb műveleteket eredményez, mint az RSA-algoritmusok. Hoffman-Andrews ezzel kapcsolatban egy teljesítménytesztre hivatkozva azt állította, hogy az optimalizált ECDH összességében csupán 15 százalékkal több erőforrást emészt fel, mint a 2048 bites RSA. (A hagyományos Diffie-Hellman viszont 310 százalékkal nagyobb terhelést eredményez szerver oldalon.)

Az elliptikus görbék feletti Diffie-Hellman protokoll (forrás: Microsec e-szignó)

A Twitter eddigi statisztikái szerint az ECDH-támogatás kliens oldalon 75 százalékban biztosított. A maradék 25 százalékba olyan régebbi rendszerek tartoznak, amelyek nem rendelkeznek ECDHE kompatibilitással. A bevezetett biztonsági újdonság a twitter.com, az api.twitter.com és a mobile.twitter.com domaineket érinti.

Persze a forward secrecy korántsem sem új keletű védelmi megoldás. A Google már 2011 óta alkalmazza, míg a Facebook idén döntött arról, hogy a rendszereit felkészíti az egyre népszerűbbé váló eljárás használatára.

_{(A cikk a Biztonságportálon megjelent írás szerkesztett változata.)}