Épp most néztünk át két olyan területet, ahol szükség van biztonságra: a kommunikációt és az e-levelezést. Úgy is gondolhatunk ezekre, mint levesre és előételre. Most pedig itt a főfogás ideje: elérkeztünk a webes biztonsághoz. A web az a hely, ahol manapság a legtöbb Trudy lófrál és végzi a piszkos dolgait. A következő szakaszokban megnézünk néhány, a webes biztonsággal kapcsolatos problémát és kérdést.
A webes biztonság területét nagyjából három részre tagolhatjuk. Először is: hogyan lehet az objektumokat és az erőforrásokat biztonságosan megnevezni? Másodszor: hogyan lehet biztonságos, hitelesített összeköttetéseket felépíteni? Harmadszor: mi történik akkor, ha egy weboldal egy darabka futtatható kódot küld el az ügyfélnek? Miután megnéztünk néhány lehetséges fenyegetést, rátérünk mindezekre a kérdésekre.
A weboldalak biztonsági problémáiról szinte minden héten olvashatunk az újságokban. A helyzet valóban elég ijesztő. Példaként lássunk pár eddig megtörtént esetet! Először is, az ún. „cracker”-ek már számos szervezet honlapját támadták meg és cserélték ki új honlapra, saját ízlésük szerint. (A bulvársajtó előszeretettel nevezi a számítógépekbe betörő embereket „hacker”-eknek, de a szakmabeliek közül sokan az igazán nagyszerű programozóknak tartják fenn ezt a fogalmat. A betörőket mi is inkább „cracker”-eknek fogjuk nevezni.) A feltört helyek közt vannak a Yahoo, az amerikai hadsereg, a CIA, a NASA és a New York Times oldalai is. A crackerek a legtöbb esetben csak valamilyen vicces szöveget helyeztek el az oldalon, és a webhelyet pár órán belül ki lehetett javítani.
Most viszont nézzünk meg néhány sokkal komolyabb esetet! Számos webhelyet kényszerítettek térdre szolgáltatás megtagadása (Denial of Service, DoS) típusú támadásokkal, melyekben a cracker elárasztja forgalmával a webhelyet, képtelenné téve azt a legális kérések kiszolgálására. A támadást gyakran egyidejűleg több olyan gépről viszik végbe, melyekbe a cracker előzőleg már betört (DDoS-támadások). Az ilyen támadások annyira mindennaposak, hogy már be sem kerülnek a hírekbe, a megtámadott webhelyeknek mégis több ezer dolláros veszteséget okozhatnak az elveszített üzletek miatt.
1999-ben egy svéd cracker feltörte a Microsoft Hotmail webhelyét, és elkészített egy tükrözött webhelyet, melyen egy Hotmail-felhasználó nevét megadva bárki elolvashatta az adott felhasználó összes aktuális és archivált e-levelét.
Egy másik esetben egy Maxim nevű, 19 éves orosz cracker tört be egy e-kereskedelmi webhelyre, és ellopott 300 000 hitelkártyaszámot. Ezután felvette a kapcsolatot a hely tulajdonosaival, és azt mondta nekik, hogy ha nem fizetnek neki 100 000 dollárt, akkor szétküldi az összes kártyaszámot az interneten. A tulajdonosok nem engedtek a zsarolásnak, ő pedig tényleg szétküldte a kártyaszámokat, komoly kárt okozva ezzel sok ártatlan áldozatnak.
Megint más módszert alkalmazott egy 23 éves kaliforniai diák, aki egy hamis sajtóközleményt küldött egy hírügynökségnek, amelyben azt állította, hogy az Emulex társaság nagy negyedéves veszteség bejelentése előtt áll, a vezérigazgató pedig azonnali lemondásra készül. A vállalat részvényeinek árfolyama órákon belül 60%-ot zuhant, ami a részvényeseknek 2 milliárd dollárnál is nagyobb veszteséget okozott. Az elkövető negyedmillió dollárt keresett a dolgon, mivel közvetlenül a bejelentés előtt eladta a részvényeit. Ez az eset ugyan nem egy webhely feltörése volt, mégis nyilvánvaló, hogy hasonló eredménnyel járna az, ha bármely nagyvállalat honlapján helyezne el valaki ilyen bejelentést.
Sajnos sok oldalon át folytathatnánk még a sort. Most azonban ideje lesz szemügyre vennünk néhány műszaki kérdést is a webes biztonságra vonatkozóan. A különböző típusú biztonsági problémákról további információval szolgálnak Anderson [2008a], Stuttard és Pinto [2007], valamint Schneier [2004] munkái. Az interneten keresgélve is rengeteg konkrét eset leírására bukkanhatunk.
Kezdetnek vegyünk egy nagyon alapvető példát: tegyük fel, hogy Aliz szeretné meglátogatni Bob weboldalát. Begépeli hát Bob URL-jét a böngészőjébe, és pár másodperccel később meg is jelenik egy weboldal. De vajon valóban Bob oldala az? Talán igen, talán nem. Lehet, hogy megint itt van Trudy a régi trükkjeivel. Elfoghatja például Aliz összes kimenő csomagját, és megvizsgálhatja azokat. Ha elfog egy olyan HTTP GET kérést, mely Bob webhelye felé tart, akkor maga is elmehet Bob weboldalára, hogy megszerezze az oldalt, amit aztán tetszése szerint módosíthat, és így, meghamisítva adhat vissza Aliznak. Aliznak minderről fogalma sem lesz. Még ennél is rosszabb, hogy Trudy átírhatja Bob e-kereskedésének árait, hogy a nagyon vonzónak tűnő ajánlatokkal rávegye Alizt arra, hogy adja meg a hitelkártyaszámát „Bobnak”, amikor valamilyen árut vásárol.
Az ilyen klasszikus közbeékelődéses támadások egyik hátránya az, hogy Trudynak olyan helyzetben kell lennie, hogy el tudja fogni Aliz kimenő forgalmát, és meg tudja hamisítani a beérkező forgalmát. A gyakorlatban ehhez vagy Aliz, vagy Bob telefonvonalát kell megcsapolnia, mivel a fényvezetőszálas gerinchálózathoz elég nehéz hozzáférni. A vezetékek aktív megcsapolása kétségkívül járható út, de meglehetősen sok munkával is jár, és Trudy a ravaszsága mellett elég lusta is. Aliz becsapásának azonban vannak egyszerűbb módjai is.
Tegyük fel, hogy Trudy be tud törni a DNS-rendszerbe, vagy esetleg épp Aliz internetszolgáltatójának DNS-gyorstárába, és lecseréli Bob IP-címét (ami mondjuk 36.1.2.3) a saját IP-címére (mondjuk 42.9.9.9). Ez a következő támadás előtt nyitja meg az utat. A 8.46.(a) ábra a támadás feltételezett lezajlását mutatja. Itt (1) Aliz elkéri a DNS-től Bob IP-címét, (2) megkapja azt, (3) elkéri Bob honlapját, és (4) azt is megkapja. Miután Trudy Bob DNS-rekordjában Bob IP-címét a sajátjára cserélte ki, a 8.46.(b) ábra szituációjához jutunk. Itt, amikor Aliz kikeresi Bob IP-címét, akkor valójában Trudyét kapja meg, így minden Bobnak szánt forgalma Trudyhoz fog menni. Trudy ezután anélkül is véghezviheti a közbeékelődéses támadást, hogy bármilyen vezeték megcsapolásával bajlódnia kéne. Ehelyett most a DNS-kiszolgálót kell feltörnie, és egy rekordot kell megváltoztatnia, ami már sokkal könnyebb feladat.
8.46. ábra - (a) Normális helyzet. (b) A DNS feltörésén és Bob rekordjának módosításán alapuló támadás
De hogyan tudja Trudy becsapni a DNS-t? Mint kiderül, ez viszonylag egyszerű feladat. Röviden összefoglalva, Trudy ráveheti Aliz internetszolgáltatójának DNS-kiszolgálóját arra, hogy szétküldjön egy kérdést Bob IP-címére vonatkozóan. A DNS-kiszolgálónak azonban sajnos igazából nincs módja arra, hogy ellenőrizze, ki adta a választ, mivel a DNS UDP-t használ. Trudy úgy aknázhatja ki ezt a tulajdonságot, hogy meghamisítja a várt választ, és ezzel hamis IP-címet juttat be a DNS-kiszolgáló gyorstárába. Az egyszerűség kedvéért feltételezzük, hogy Aliz szolgáltatójának eredetileg nincs bejegyzése Bob weboldalához, a bob.com-hoz. Ha mégis van, akkor Trudy megvárhatja, míg annak érvényességi ideje lejár, és később újra próbálkozhat (vagy esetleg más trükkökhöz is folyamodhat).
Trudy azzal kezdi a támadást, hogy elküld egy keresési kérést Aliz internetszolgáltatójának, melyben a bob.com IP-címére kérdez rá. Mivel ehhez a DNS-névhez nem tartozik bejegyzés, a gyorstáras kiszolgáló megkérdezi a com körzet legfelsőbb szintű kiszolgálóját. Csakhogy Trudy megelőzi a com kiszolgálót, és egy hamis választ küld vissza, mely szerint „a bob.com címe 42.9.9.9”, ami valójában a saját IP-címe. Ha a hamis válasz ér vissza először Aliz szolgáltatójához, akkor az kerül bele a gyorstárba, az igazi választ pedig egy idejétmúlt kérésre vonatkozó kéretlen válasznak fogják tekinteni, és visszautasítják. Azt a támadást, amikor egy DNS-kiszolgálót vesznek rá arra, hogy egy hamis IP-címet vegyen fel, DNS-megtévesztésnek (DNS spoofing) nevezzük. Az ilyen, szándékosan hamis IP-címet tartalmazó gyorstár neve mérgezett gyorstár (poisoned cache).
A dolog azért valójában nem ennyire egyszerű. Először is, Aliz internetszolgáltatója megvizsgálja, hogy a válasz valóban a legfelső szintű kiszolgáló IP-címét tartalmazza-e. Trudy azonban azt ír a forrás címmezőjébe, amit csak akar, így ezt a vizsgálatot könnyedén kijátszhatja, hiszen a legfelső szintű kiszolgálók IP-címének mindenki által ismertnek kell lennie.
Másodszor, a DNS-kiszolgálóknál minden kérés egy sorszámot hordoz, hogy a kiszolgálók tudják, melyik kéréshez melyik válasz tartozik. Aliz internetszolgáltatójának megtévesztéséhez Trudynak ismerni kell annak aktuális sorszámát. A sorszámot úgy lehet a legkönnyebben megtudni, ha Trudy saját magának is regisztrál egy körzetet, mondjuk, a trudy-a-tamado.com-ot. Tegyük fel, hogy ennek az IP-címe is 42.9.9.9. Trudy egy DNS-kiszolgálót is felállít újdonsült körzetében, a dns.trudy-a-tamado.com név alatt. Ez szintén a 42.9.9.9-es IP-címet használja, hiszen Trudynak csak egy számítógépe van. A következő feladat az, hogy Aliz szolgáltatójának tudomására hozza a saját DNS-kiszolgálójának meglétét. Ezt könnyen elérheti: csak annyit kell tennie, hogy lekérdezi Aliz szolgáltatójától a valami.trudy-a-tamado.com nevet, aminek hatására Aliz szolgáltatója meg fogja kérdezni a legfelső szintű com kiszolgálót, hogy megtudja, ki Trudy új körzetének kiszolgálója.
Ha a dns.trudy-a-tamado.com már biztos helyen van Aliz szolgáltatójának gyorstárában, megkezdődhet az igazai támadás. Trudy ekkor lekérdezi Aliz szolgáltatójától a www.trudy-a-tamado.com címét. A szolgáltató erre természetesen elküld egy kérést Trudy DNS-kiszolgálójának. Ez a kérés hordozza azt a sorszámot, amit Trudy keres. Trudy erre mint a villám, megkéri Aliz szolgáltatóját, hogy keresse ki neki Bob címét, majd rögtön meg is válaszolja saját kérdését egy hamis válasszal, mely állítólagosan a legfelső szintű com kiszolgálótól jön, és így szól: „a bob.com címe 42.9.9.9”. Ez a hamis válasz eggyel nagyobb sorszámot hordoz, mint az, amelyet Trudy épp azelőtt kapott meg. Ha már itt tart, elküldhet még egy hamis választ, kettővel nagyobb sorszámmal, sőt akár egy tucatnyit is, egyre nagyobb sorszámokkal – valamelyik biztosan megfelelő lesz, a többit meg egyszerűen eldobják. Amikor Trudy hamis válasza megérkezik, bekerül a gyorstárba, az ezután beérkező igazi választ pedig visszautasítják, hiszen akkor már nem lesz függőben lévő kérdés.
Ha Aliz most keresi ki a bob.com címét, akkor a 42.9.9.9-et, vagyis Trudy címét kapja válaszul. Trudy tehát kényelmesen, a saját nappalijában ülve vitt véghez egy sikeres közbeékelődéses támadást. A támadás lépéseit a 8.47. ábra szemlélteti. Ez a speciális támadás kivédhető úgy, hogy a DNS-szerver véletlenszám-azonosítókat használ lekérdezései alkalmával, és nem sorszámokat. Úgy tűnik azonban, hogy minden alkalommal, amikor egy rést betömnek, egy másik keletkezik. Pontosabban, az azonosítók csak 16 bitesek, így ezeken végighaladni könnyű, amikor a számítógép az, amelyik a találgatásokat végzi.
Ezt az egy konkrét támadást ki lehet védeni azzal, ha a DNS-kiszolgálók véletlenszerű azonosítókat használnak az egyszerű sorszámozás helyett, de úgy tűnik, amint betömünk egy lyukat, felbukkan egy másik. Az igazi gond itt az, hogy a DNS-t akkor fejlesztették ki, amikor az internet még csak néhány száz egyetem kutatási céljait szolgálta, és sem Aliz, sem Bob, sem Trudy nem volt hivatalos erre a partira. A biztonság akkor még nem volt téma; a cél az volt, hogy az internet egyáltalán működjön. Ez a környezet azonban drasztikusan megváltozott az évek során, az IETF így 1994-ben felállított egy munkacsoportot, hogy a DNS-t alapjaitól kezdve biztonságossá tegyék. Ez a (most is futó) projekt a DNSsec (DNS security – DNS-biztonság) néven ismert, az első eredményeit az RFC 2535-ben tették közzé. A DNSsec-et sajnos még nem sikerült teljeskörűen telepíteni, ezért számos DNS-kiszolgáló még mindig védtelen a megtévesztéses támadásokkal szemben.
A DNSsec az elgondolásait tekintve rendkívül egyszerű. A megoldás nyilvános kulcsú kriptográfián alapul. Minden (a 7.5. ábra értelmében vett) DNS-zóna rendelkezik egy nyilvános/egyéni kulcspárral. A DNS-kiszolgálók minden kiküldött információt aláírnak a származási zóna egyéni kulcsával, így a vevő ellenőrizheti a hitelességet.
A DNSsec három alapvető szolgáltatást nyújt:
az adatok származási helyének bizonyítása,
nyilvános kulcsok kiosztása,
tranzakciók és kérések hitelesítése.
Az első szolgáltatás a legfontosabb: ez ellenőrzi, hogy a visszaadott adatokat jóváhagyta-e a zóna tulajdonosa. A második a nyilvános kulcsok biztonságos tárolását és kinyerését teszi lehetővé. A harmadikra a visszajátszásos és a megtévesztéses támadások elleni védelemnél van szükség. Figyeljük meg, hogy titkosságot biztosító szolgáltatás nincs, hiszen a DNS-ben lévő összes információ nyilvánosnak tekinthető. Mivel a DNSsec fokozatos bevezetése várhatóan több évig is eltart majd, elengedhetetlenül fontos, hogy a biztonságos kiszolgálók együtt tudjanak működni a nem biztonságos társaikkal, vagyis magát a DNS-protokollt nem lehet megváltoztatni. Lássunk most tehát néhány részletet!
A DNS-rekordok RRSet (Resource Record Set – erőforrás-rekordkészlet) nevű halmazokba vannak csoportosítva, ahol az ugyanolyan nevű, osztályú és típusú rekordok kerülnek egy halmazba. Egy RRSet tartalmazhat több A rekordot is, például akkor, ha egy DNS-név egy elsődleges és egy másodlagos IP-címre is leképezhető. Az RRSet-ek számos új rekordtípussal is kiegészültek (lásd lejjebb). Minden RRSet egy kriptográfiai hash-el van ellátva (például MD5 vagy SHA-1 alkalmazásával). A hash-t a zóna egyéni kulcsával írják alá (például RSA segítségével). Az ügyfeleknek átvitt adategységek tehát aláírt RRSet-ek. Egy aláírt RRSet vételekor az ügyfél ellenőrizheti, hogy azt tényleg a származási zóna egyéni kulcsával írták alá. Ha az aláírás megegyezik, akkor az adatokat elfogadják. Mivel minden RRSet tartalmazza a saját aláírását, az RRSet-eket bármilyen gyorstárban tárolni lehet, még a nem megbízható kiszolgálókon is, és ez sem veszélyezteti a biztonságot.
A DNSsec számos új rekordtípust vezet be. Ezek közül az első a KULCS (KEY) rekord. Ez tartalmazza egy zóna, felhasználó, hoszt vagy más főszereplő nyilvános kulcsát, az aláíráshoz használt kriptográfiai algoritmust, az átvitelnél használt protokollt és még néhány egyéb bitet. A nyilvános kulcsot tisztán, önmagában tárolják. X.509 tanúsítványokat nem használnak a nagy helyigényük miatt. Az algoritmus mezőben az 1 jelenti az MD5/RSA-aláírásokat (ez a javasolt választás), más értékek pedig más kombinációknak felelnek meg. A protokollmező az IPsec vagy más biztonsági protokoll használatára utalhat, ha egyáltalán van ilyen.
A második új rekordtípus a SIG (ALÁÍRÁS) rekord. Ez a KEY rekord által meghatározott algoritmussal aláírt hash-t tartalmazza. Az aláírás az RRSet összes rekordjára vonatkozik, beleértve az összes KEY rekordot is, kivéve magát a SIG rekordot. A rekord tartalmazza még az aláírás érvényességének kezdetét és végét is, valamint az aláíró nevét és pár más elemet is.
A DNSsec-et úgy tervezték, hogy a zóna egyéni kulcsát offline lehessen tartani. A zóna adatbázisának tartalmát naponta egyszer vagy kétszer manuálisan (például egy CD-ROM-on) át lehet vinni egy hálózatba nem kötött gépre, mely az egyéni kulcsot tárolja. Ezen a gépen az összes RRSet-et alá lehet írni, és az így előállt SIG rekordot vissza lehet szállítani a zóna elsődleges kiszolgálójára CD-ROM-on. Ily módon az egyéni kulcsot egy széfbe zárt CD-ROM-on lehet tárolni, melyet csak akkor tesznek be a hálózatba nem kötött gépbe, amikor az aznapi új RRSet-eket kell aláírni. Az aláírás elvégzése után a kulcs összes másolatát kitörlik a memóriából és a merevlemezről, és a CD-ROM-ot visszateszik a széfbe. Ez az eljárás az elektronikus biztonságot a fizikai biztonságra vezeti vissza, annak kezeléséhez pedig már jobban értenek az emberek.
Az, hogy az RRSet-eket előre aláírják, nagyban meggyorsítja a kérések megválaszolását, hiszen nem kell menet közben a kriptográfiával bajlódni. Ennek ára az, hogy nagy tárterületre van szükség a merevlemezen a DNS-adatbázisok összes kulcsának és aláírásának tárolásához. Egyes rekordok mérete akár az eredeti méret tízszeresére is növekedhet az aláírásnak köszönhetően.
Amikor az ügyfélfolyamat egy aláírt RRSet-et kap, akkor először alkalmaznia kell a származási zóna nyilvános kulcsát, hogy visszafejtse a hash-t, majd saját magának is ki kell számítania a hash-t, és össze kell hasonlítania a két értéket. Ha megegyeznek, akkor az adatok érvényesnek tekinthetők. Ez az eljárás azonban felveti azt a kérdést, hogy hogyan kapja meg az ügyfél a zóna nyilvános kulcsát? Az egyik lehetséges megoldás az, ha a kulcsot egy megbízható kiszolgálótól szerezzük be, egy biztonságos összeköttetésen keresztül (például IPsec használatával).
A gyakorlatban azonban inkább azzal számolhatunk, hogy az ügyfelek előre fel lesznek szerelve az összes legfelső szintű körzet nyilvános kulcsával. Ha Aliz most szeretné meglátogatni Bob webhelyét, akkor elkérheti a DNS-től a bob.com RRSet-jét, mely tartalmazni fogja Bob IP-címét, és egy KEY rekordot Bob nyilvános kulcsával. Ezt az RRSet-et a legfelső szintű com körzet fogja aláírni, ezért érvényességét Aliz könnyedén ellenőrizheti. Egy ilyen RRSet lehetséges tartalmára mutat példát a 8.48. ábra.
8.48. ábra - Példa a bob.com RRSet-jére. A KEY rekord tartalmazza Bob nyilvános kulcsát. A SIG rekord az A és a KEY rekordoknak a legfelső szintű com kiszolgáló által aláírt hash-e, mely a hitelességük ellenőrzésére szolgál
Bob nyilvános kulcsának ellenőrzött másolatával felvértezve Aliz már megkérdezheti Bob DNS-kiszolgálójától (melyet Bob üzemeltet), hogy mi a www.bob.com IP-címe. Ez az RRSet Bob egyéni kulcsával lesz aláírva, így Aliz ellenőrizheti a Bob által visszaadott RRSet-en lévő aláírás érvényességét. Ha Trudynak sikerül is valahogy egy hamis RRSet-et bejuttatnia bármelyik gyorstárba, Aliz akkor is könnyedén észreveheti, hogy az nem hiteles, mivel a benne szereplő SIG rekord helytelen lesz.
A DNSsec emellett arra is ad kriptográfiai eljárást, hogy egy választ egy bizonyos kérdéshez lehessen kötni, megelőzve ezzel azt a fajta megtévesztést, amivel Trudy állt elő a 8.47. ábra példájában. Ez a megtévesztést megakadályozó (opcionális) óvintézkedés a válaszhoz hozzáadja a lekérdező üzenet hash-ét, melyet a válaszadó egyéni kulcsával írnak alá. Mivel Trudy nem ismeri a legfelső szintű com kiszolgáló egyéni kulcsát, ezért nem tudja Aliz ISP-jének a lekérdezésre adandó választ meghamisítani. Azt minden további nélkül elérheti ugyan, hogy az ő válasza érkezzen meg előbb, de Aliz ISP-jének DNS-kiszolgálója úgyis vissza fogja utasítani, mivel a hash-elt lekérdezésre vonatkozó aláírása érvénytelen lesz.
A DNSsec néhány további rekordtípust is támogat. A CERT (TANÚSÍTVÁNYOK) rekord például a tanúsítványok tárolására használható (például X.509 tanúsítványokhoz). Ezt a rekordot azért biztosították, mert egyesek a DNS-ből egy PKI-t szeretnének kialakítani. Hogy ez valóban be is következik-e, azt még nem lehet tudni. A DNSsec tárgyalását mindenesetre ezzel befejezzük. További részleteket az RFC 2535 tartalmaz.
A biztonságos névkezelés kezdetnek jó, de a web biztonsága ennél jóval több dolgot takar. A következő lépést a biztonságos összeköttetések jelentik. Most tehát azt fogjuk megvizsgálni, hogy a biztonságos összeköttetéseket hogyan lehet létrehozni.
Amikor a web betört a köztudatba, kezdetben csak statikus oldalak terjesztésére használták. Néhány vállalatnak azonban nem sokkal később az az ötlete támadt, hogy üzleti tranzakciók céljából is használják a webet, hogy online módon lehessen például hitelkártyával vásárolni, banki műveleteket végezni vagy tőzsdézni. Az ilyen alkalmazások miatt jelent meg a biztonságos összeköttetések iránti igény. Az igény kielégítésére 1995-ben a Netscape Communications Corp., az akkoriban domináns böngészőgyártó az SSL (Secure Sockets Layer – biztonságos csatlakozóréteg) nevű biztonsági csomag bemutatásával állt elő. A szoftvert és annak protokollját ma már széles körben használják, például a Firefox, a Safari és az Internet Explorer, érdemes tehát közelebbről is szemügyre vennünk a részleteit.
Az SSL biztonságos összeköttetést hoz létre két csatlakozó között, és többek között a következő lehetőségeket kínálja:
paraméterek egyeztetése az ügyfél és a kiszolgáló között,
kölcsönös hitelesítés az ügyfél és a kiszolgáló között,
titkos kommunikáció,
az adatok sértetlenségének biztosítása.
Ezekkel az elemekkel már eddig is találkoztunk, nem igényelnek tehát bővebb magyarázatot.
Az SSL elhelyezkedését a szokásos protokollkészletben a 8.49. ábra szemlélteti. Az SSL gyakorlatilag egy új réteget jelent, mely az alkalmazási és a szállítási réteg közé ékelődik be. Ez fogadja a böngészőből érkező kéréseket, és átadja azokat a TCP-nek a kiszolgálóhoz való továbbításra. A biztonságos összeköttetés kiépítése után az SSL fő feladata a tömörítés és a titkosítás kezelése. Ha a HTTP-t SSL fölött használják, akkor HTTPS-nek (Secure HTTP – biztonságos HTTP) nevezik, még akkor is, ha maga a protokoll továbbra is csak a szabványos HTTP. Ez néha egy új porton (443) keresztül érhető el a hagyományos (80) helyett. Megjegyezzük, hogy az SSL-t nem csak webböngészőkkel lehet használni, de ez a leggyakoribb alkalmazási módja. Köcsönös hitelesítést is biztosít.
8.49. ábra - Egy SSL segítségével böngésző otthoni felhasználó által használt rétegek és protokollok
Az SSL-protokoll több verziót is megélt már. Az alábbiakban csak a 3. verziót fogjuk tárgyalni, mely mind közül a legelterjedtebb. Az SSL számos különböző algoritmust és opciót támogat. Az opciók között van a tömörítés megléte vagy hiánya, az alkalmazandó kriptográfiai algoritmusok, valamint néhány, a kriptográfia kivitelének korlátozásaival kapcsolatos lehetőség. Ez utóbbiakat főként annak biztosítására szánták, hogy komoly kriptográfiát csak akkor lehessen használni, amikor az összeköttetés mindkét vége az Egyesült Államokban van. A kulcsok hossza minden egyéb esetben 40 bitre van korlátozva, ami a kriptográfusok szemében tulajdonképpen vicc. A Netscape azért kényszerült ilyen megszorítást alkalmazni, mert csak így kapta meg a kiviteli engedélyt az amerikai kormánytól.
Az SSL két alprotokollból áll: az egyik a biztonságos összeköttetés kiépítésére, a másik pedig annak használatára szolgál. Kezdjük a kiépítés folyamatának vizsgálatával! Az ezért felelős alprotokollt a 8.50. ábra mutatja be. Ez az 1-es üzenettel kezdődik, melyben Aliz elküld egy kérést Bobnak az összeköttetés kiépítésére vonatkozóan. A kérés megadja az Aliz által használt SSL verzióját, valamint az Aliz által előnyben részesített tömörítési módot és kriptográfiai algoritmusokat. Tartalmaz még ezenkívül egy 
véletlen számot is, mely később kerül felhasználásra.
Most Bob következik. Ő a 2-es üzenetben választ egyet az Aliz által felkínált algoritmusok közül, és elküldi a saját véletlen számát, 
-t, a 3-as üzenetben pedig elküld egy tanúsítványt, mely a saját nyilvános kulcsát tartalmazza. Ha a tanúsítvány nem hordozza valamely jól ismert hatóság aláírását, akkor elküld még mellé egy tanúsítványláncot, melynek segítségével már el lehet jutni egy ilyen hatósághoz. Minden böngésző, így Aliz böngészője is eleve tartalmaz mintegy 100 nyilvános kulcsot, így ha Bob ki tud építeni egy olyan láncot, mely ezek közül valamelyikhez kapcsolódik, akkor Aliz képes lesz Bob nyilvános kulcsának ellenőrzésére. Ezen a ponton Bob egyéb üzeneteket is elküldhet (például elkérheti Aliz nyilvános kulcsának tanúsítványát). Ha Bob elkészült, elküldi Aliznak a 4-es üzenetet, hogy tudassa vele: rajta a sor.
Aliz erre véletlenszerűen kiválaszt egy 384 bites előzetes főkulcsot (premaster key), majd elküldi azt Bobnak az ő nyilvános kulcsával titkosítva (5-ös üzenet). Az adatok titkosítására használt tényleges viszonykulcsot a mindkét véletlen számmal kombinált előzetes főkulcsból származtatják, bonyolult módon. Az 5-ös üzenet beérkezése után Aliz és Bob is ki tudja már számolni a viszonykulcsot. Épp ezért Aliz meg is kéri Bobot arra, hogy álljon át az új kódolásra (6-os üzenet), majd azt is közli vele, hogy végzett a kiépítési alprotokollal (7-es üzenet). Bob ezután nyugtázza Aliz üzeneteit (8-as és 9-es üzenet).
Most az a helyzet állt elő, hogy Aliz tudja ugyan, hogy kicsoda Bob, de Bob nem tudja, hogy ki Aliz (hacsak nincs Aliznak nyilvános kulcsa és egy ahhoz tartozó tanúsítványa, ami elég valószínűtlen egy magánszemély esetében). Bob első üzenetében ezért jó eséllyel arra fogja kérni Alizt, hogy lépjen be egy előzőleg rögzített belépési név és jelszó segítségével. A beléptetés protokollja ugyanakkor már nem tartozik az SSL hatáskörébe. A lényeg az, hogy akárhogy is történjék a beléptetés, utána megkezdődhet az adatátvitel.
Mint már említettük, az SSL többféle kriptográfiai algoritmust is támogat. Ezek közül a legerősebb algoritmus a titkosításhoz háromszoros DES-et használ három különböző kulccsal, a sértetlenség biztosításához pedig SHA-1-et. Ez a kombináció viszonylag lassú, ezért leginkább a banki és ehhez hasonló alkalmazásokban használják, ahol a legmagasabb fokú biztonságra van szükség. Az átlagos e-kereskedelmi alkalmazásokban a titkosításhoz 128 bites kulcsú RC4-et, a hitelesítéshez pedig MD5-öt használnak. Az RC4 a 128 bites kulcsot kezdőértéknek (seed) veszi, és belső használatra egy sokkal nagyobb számot állít elő belőle. A későbbiekben aztán ezzel a belső számmal készíti el a kulcsfolyamot. A kulcsfolyamot kizáró vagy kapcsolatba hozzák a nyílt szöveggel, így egy olyan klasszikus folyamkódolót kapnak, amilyet a 8.14. ábrán láthattunk. Az exportra szánt verziók szintén 128 bites kulcsú RC4-et használnak, de a bitek közül 88-at nyilvánosságra hoznak, hogy a kódot könnyen fel lehessen törni.
A tényleges átvitelre egy másik alprotokollt használnak, amit a 8.51. ábra mutat be. A böngészőből érkező üzeneteket itt először legfeljebb 16 KB-os egységekre darabolják. Ha a tömörítés engedélyezett, akkor ezután minden egységet külön tömörítenek. Ezt követően a két véletlen számból (nonce) és az előzetes főkulcsból származó titkos kulcsot konkatenálják a tömörített szöveggel, az eredményből pedig hash-t képeznek a megegyezés szerinti hash-algoritmussal (ez rendszerint az MD5). Ezt a hash-t aztán üzenethitelesítő kódként (message authentication code, MAC) minden egyes részhez hozzáfűzik. A tömörített részeket az MAC-vel együtt ezután a megállapodás szerinti szimmetrikus titkosító algoritmussal kódolják (általában kizáró vagy kapcsolatba hozzák az RC4 kulcsfolyammal). Végül egy fejrészt illesztenek az egyes részekhez, és átviszik azokat a TCP-összeköttetésen.
Itt azonban elkel egypár óvatosságra intő szó. Tudjuk, hogy az RC4-ről kiderült, hogy van néhány gyenge kulcsa, melyeket könnyen vissza lehet fejteni, ezért az SSL biztonsága is ingoványos talajon áll [Fluhrer és mások, 2001]. Az olyan böngészőket tehát, melyekben a kódoló készletet a felhasználó választhatja meg, mindig a 168 bites kulcsú háromszoros DES és az SHA-1 használatára kell beállítani, még akkor is, ha ez a kombináció lassabb az RC4-nél és az MD5-nél. Vagy ami még ennél is jobb, a felhasználó frissítse a böngészőt, hogy az támogassa az SSL utáni megoldást, amelyet rövidesen leírunk. Az SSL további problémája, hogy a főszereplők nem mindig rendelkeznek tanúsítványokkal, vagy ha igen, még akkor sem mindig ellenőrzik, hogy a felhasznált kulcsok megfelelnek-e azoknak.
1996-ban a Netscape Communications Corp. átadta az SSL-et az IETF-nek szabványosítás céljából. Az eredmény a TLS (Transport Layer Security – szállítási rétegbeli biztonság) protokoll lett, melyet az RFC 2246 ír le.
A TLS az SSL 3. változatára épül. Az SSL-en csak viszonylag kisebb változtatásokat hajtottak végre, ami ahhoz mégis elég volt, hogy az SSL 3. verziója és a TLS ne tudjon együtt működni. Megváltoztatták például azt a folyamatot, mely az előzetes főkulcsból és a két véletlen számból állítja elő a viszonykulcsot, mégpedig azért, hogy erősebb kulcsot kapjanak (vagyis olyat, amit nehezebb megfejteni). Emiatt az inkompatibilitás miatt a legtöbb böngésző megvalósítja mindkét protokollt úgy, hogy a TLS visszavedlik SSL-re az egyeztetés során, ha ez szükséges. Erre a megoldásra úgy hivatkoznak, mint SSL/TLS. Az első TLS-megvalósítások 1999-ben jelentek meg az 1.2 változattal, amelyet 2008 augusztusában definiáltak. Ez támogatja az erősebb titkosító eljárásokat (például AES). Az SSL piacon elfoglalt helye erős maradt, bár a TLS fokozatosan ki fogja szorítani
A névkezelésen és az összeköttetéseken kívül egyéb területei is vannak a webes biztonságnak. A kezdeti időkben a weboldalak pusztán statikus HTML-állományok voltak, így nem tartalmaztak még futtatható kódot sem. Manapság viszont gyakran találunk bennük apró programokat, köztük Java-kisalkalmazásokat, ActiveX-vezérlőket és JavaScripteket. Az ilyen hordozható kódok (mobile code) letöltése és futtatása nyilvánvalóan komoly biztonsági kockázatokat rejt, melyek minimalizálására számos eljárást javasoltak. Most röviden áttekintünk néhány olyan kérdést, melyet a hordozható kódok vetnek fel, majd megnézünk néhány megközelítést ezek kezelésére.
A Java-kisalkalmazások (appletek) apró Java-programok, amelyeket egy veremorientált, JVM (Java Virtual Machine – Java virtuális gép) nevű gépi nyelvre fordítottak le. Ezeket egy weboldalon is el lehet helyezni, ekkor az oldallal együtt ezek is letöltődnek. A letöltés után a kisalkalmazások egy böngészőn belüli JVM-értelmezőbe kerülnek, amint azt a 8.52. ábra szemlélteti.
Az értelmezett kódok futtatásának előnye a lefordított kódokkal szemben, hogy az előbbinél az értelmező a végrehajtás előtt minden utasítást megvizsgál. Ez lehetőséget nyújt annak ellenőrzésére, hogy az utasítás címe érvényes-e. Ezenfelül a rendszerhívásokat is elkapják és értelmezik. Az ilyen hívások kezelése a biztonsági politikától függ. Például, ha egy kisalkalmazás megbízható (például a helyi lemezről származik), akkor annak rendszerhívásait minden további nélkül végre lehet hajtani. Ha azonban nem megbízható (például az internetről érkezett), akkor egy úgynevezett homokozóba (sandbox) lehet zárni, hogy korlátok közé szorítsuk működését, és meggátoljuk abban, hogy hozzáférhessen a rendszer erőforrásaihoz.
Amikor egy kisalkalmazás egy rendszererőforráshoz próbál hozzáférni, akkor a hívását egy biztonsági felügyelőnek adják át jóváhagyásra. A felügyelő a helyi biztonságpolitika fényében vizsgálja meg a hívást, majd eldönti, hogy elfogadja vagy visszautasítja-e azt. Ily módon lehetőség nyílik annak biztosítására, hogy a kisalkalmazások csak bizonyos erőforrásokhoz férhessenek hozzá. Sajnos az az igazság, hogy ez a biztonsági modell gyengén működik, és folyton-folyvást hibák bukkannak fel benne.
Az ActiveX-programok Pentium processzorokra írt bináris programok, melyeket weboldalakba lehet ágyazni. Ha a böngésző egy ilyennel találkozik, akkor megnézi, hogy szabad-e futtatni, és ha igen, akkor futtatja azt. Nincs semmilyen értelmezés, se homokozó, az ilyen programoknak tehát éppen annyi lehetőségük van, mint más felhasználói programoknak, így esetleg nagy károkat is okozhatnak. Az összes biztonság egyedül annak eldöntésében összpontosul, hogy futtatható-e az ActiveX-vezérlő vagy sem.
A Microsoft egy olyan eljárást választott ezen döntés meghozatalára, mely a kódok aláírásának (code signing) elvén alapszik. Minden ActiveX-vezérlőt egy digitális aláírás kísér – ez egy, a kódból képzett hash, melyet annak készítője nyilvános kulcsú kriptográfia segítségével aláírt. Amikor egy ActiveX-vezérlő felbukkan, a böngésző először az aláírást ellenőrzi, hogy meggyőződjön róla, hogy nem nyúltak hozzá a kódhoz az átvitel során. Ha az aláírás megfelelő, akkor a böngésző megnézi a belső táblázatában, hogy a program készítője megbízható-e, vagy van-e tőle induló bizalmi lánc egy megbízható szerzőhöz. Ha a szerző megbízható, akkor a programot futtatják; különben nem. A Microsoft ActiveX-vezérlők ellenőrzésére szolgáló rendszerét Authenticode-nak nevezik.
Érdemes összehasonlítani a Java és az ActiveX megközelítését. A Java nem tesz kísérletet arra, hogy kiderítse, ki írta a kisalkalmazást. Ehelyett egy futási időben működő értelmező biztosítja, hogy a kisalkalmazás ne tegyen semmi olyat, amit a gép tulajdonosa szerint a kisalkalmazások nem tehetnek meg. Ezzel szemben az aláírt kódoknál nem próbálják meg felügyelni a hordozható kód futási idejű viselkedését. Ha a kód megbízható forrásból érkezett, és nem módosították útközben, akkor futhat. Meg sem kísérlik megvizsgálni azt, hogy a kód vajon rosszindulatú vagy sem. Az eredeti szerző szándékosan is megírhatja úgy a kódot, hogy az formázza le a merevlemezt, majd törölje a flash ROM tartalmát, hogy a számítógépet soha többé ne lehessen elindítani. Ha ez a szerző ezután megkapja a megbízhatósági tanúsítványt, akkor a kódot futtatni fogják, az pedig tönkreteszi a számítógépet (hacsak nem tiltották le az ActiveX-vezérlőket a böngészőben).
Sokan érzik úgy, hogy ijesztő dolog egy ismeretlen szoftvercégben megbízni. A probléma szemléltetésére egy seattle-i programozó megalapított egy szoftvercéget, majd megbízhatónak tanúsíttatta azt, amit nem nehéz elérni. Írt ezután egy olyan ActiveX-vezérlőt, mely szabályszerűen lekapcsolta a számítógépet, és elkezdte a vezérlőjét széles körben terjeszteni. Sok számítógépet sikerült lekapcsolnia, de azokat egyszerűen újra lehetett indítani, tehát nem okozott kárt, mindössze megpróbálta felhívni a világ figyelmét a problémára. A hivatalos reakció az volt, hogy visszavonták a tanúsítványát az adott vezérlőre vonatkozóan. Ez véget vetett ugyan a közvetlen kellemetlenségeket okozó rövidke időszaknak, de a felszín alatt rejlő problémát még mindig kihasználhatja egy rosszindulatú programozó [Garfinkel és Spafford, 2002]. Mivel nincs arra mód, hogy az esetleg hordozható kódokat is előállító több ezer céget felügyeljék, a kódok aláírásának módszere valójában egy ketyegő időzített bomba.
A JavaScriptnek nincs semmilyen formális biztonsági modellje, történelmét pedig végigkísérik a biztonsági lyukakkal teli megvalósítások. A biztonságot minden gyártó más módon kezeli. A Netscape Navigator 2. verziója például egy, a Javáéhoz hasonló modellt alkalmazott, a 4. verzióban viszont már felhagytak ezzel, és áttértek a kódaláírásos modellre.
Az alapvető probléma az, hogy egy idegen kód futtatása a számítógépen jó eséllyel csak a bajok forrása lehet. A biztonság szempontjából olyan ez, mintha az ember egy betörőt hívna meg a házába, aztán próbálná alaposan szemmel tartani, nehogy kiszökjön a konyhából a nappaliba. Ha valami váratlan következik be, és az ember figyelmét egy pillanatra elvonják, akkor csúnya dolgok történhetnek. A feszültséget itt az okozza, hogy a hordozható kódok látványos grafikát és gyors interakciót tesznek lehetővé, és sok webtervező ezt jóval fontosabbnak tartja, mint a biztonságot, különösen akkor, ha valaki másnak a gépe van veszélyben.
Ugyanúgy, mint a weblapok kóddal történő kiterjesztésének, a böngészők kiterjesztésének, a kiegészítéseknek (add-on) és a beépülő moduloknak (plug-in) is óriási piaca van. Ezek számítógépes programok, amelyekkel a webböngészők több funkciót tudnak ellátni. A beépülő modulokkal értelmezni lehet vagy meg lehet jeleníteni bizonyos típusú tartalmakat, például PDF-dokumentumokat vagy Flash-animációkat. A kiterjesztések és kiegészítések a böngészőt vagy új képességekkel látják el, amilyen például a jobb jelszókezelés, vagy együttműködési módokat biztosítanak weblapokkal például azáltal, hogy megjelölik azokat vagy hogy lehetővé teszik megadott termékek könnyű vásárlását.
Egy kiterjesztés, egy kiegészítés vagy egy beépülő modul telepítése nem bonyolultabb annál, mint böngészéssel elérni a kívánt objektumot, és rákattintani a hiperhivatkozásra a programok telepítéséhez. Ennek a tevékenységnek az eredményeként az interneten keresztül kód fog letöltődni és a böngészőbe települni. Az összes ilyen programot keretrendszerekben írják, amelyek különbözők lehetnek attól a böngészőtől függően, amelyet feljavítanak. Első közelítésben azonban ezek a böngésző hiteles számítási bázisának részévé válnak. Azaz, ha a kód, amelyet telepítünk hibás, az egész böngésző veszélybe kerülhet.
Van még két további nyilvánvaló hibalehetőség. Az első az, hogy a program esetleg rosszindulatúan viselkedik, például azzal, hogy összegyűjt személyes információkat és elküldi azt egy távoli szerverre. Mindenesetre a böngésző úgy tudja, hogy a felhasználó éppen ezért telepítette a kiterjesztést. A második probléma az, hogy a beépülő modulok a böngészőt képessé teszik arra, hogy új típusú tartalmat értelmezzen. Ez a tartalom gyakran maga egy teljesen kiterjesztett programnyelv. A PDF és a Flash jó példa erre. Amikor a felhasználó PDF-fel oldalakat vagy Flash-sel tartalmat néz, a beépülő modulok a böngészőjükben végrehajtják a PDF- vagy Flash-kódot. Ennek a kódnak biztonságosnak kellene lennie, azonban gyakran vannak benne gyenge biztonsági pontok, amelyek kihasználhatók. Mindezek miatt a kiegészítéseket és a beépülő modulokat csak akkor kell telepíteni, amikor szükség van rájuk, és csak megbízható szállítótól szabad ezeket letölteni.
A vírusok a hordozható kódok egy másik formáját jelentik. A fenti példáktól eltérően az ember semmilyen formában nem hívja meg a vírusokat a számítógépére. Egy vírus és a hagyományos hordozható kód között az a különbség, hogy a vírusokat úgy írják meg, hogy reprodukálják önmagukat. Amikor egy weboldalról, egy e-levél mellékletből vagy valami más úton-módon megérkezik egy vírus, akkor általában azzal kezdi a tevékenységét, hogy megfertőzi a háttértáron található futtatható programokat. Ha ezek után egy ilyen fertőzött programot futtatunk, akkor az irányítás átkerül a vírushoz, ami rendszerint megpróbálja átterjeszteni magát más gépekre is, például úgy, hogy másolatokat küld magáról az áldozat e-levél címjegyzékében található összes személynek. Egyes vírusok a merevlemez rendszerindító szektorát (boot sector) fertőzik meg, így a gép indításakor a vírus máris futni fog. A vírusok rendkívül súlyos problémát jelentenek az interneten, és már eddig is több milliárd dollárnyi kárt okoztak. A problémára egyértelmű megoldás nem létezik. Talán az olyan teljesen új generációs operációs rendszerek enyhítenének a gondokon, melyek biztonságos mikrokerneleken alapulnak, és szigorúan elkülönítik egymástól az egyes felhasználókat, folyamatokat és erőforrásokat.