SSL, tedy secure socket layer si můžete v duchu představit coby jakousi další přídavnou vrstvu, která chrání data na hraniční čáře mezi vrstvou aplikační a transportní , tj. TCP/IP protokolem. Pokud použijeme odpovídající digitální certifikát, můžeme data šifrovat, přičemž využití se samozřejmě nabízí nejen pro šifrování komunikace mezi prohlížečem a webovým serverem, ale i v případě celé řady dalších protokolů jako POP3, nebo SMTP. V praxi se pak daný protokol ohlásí s pozměněným názvem (přidáním písmenka „s“, například tedy jako SMTPS).
Na první pohled by se mohlo zdát, že je-li nějaký protokol jednou navržen právě za účelem utajení přenášených informací, nebude tak snadné ho překonat. Ostatně v řadě dobře míněných bezpečnostních doporučení lze narazit právě na dobře míněná doporučení typu „svěřujte citlivé údaje výhradně https“.
Bohužel pravý opak je pravdou, přičemž (jak zjistíme dále) vinu za bezpečnostní mezery je často nutné hledat i u samotných provozovatelů. Ještě před několika málo lety jste bez problémů mohli najít na řadě serverů tzv. „self-signed“ a jim podobné certifikáty, které nejde pořádně ani ověřit, nemluvě pak vůbec o tom, jak rychle se dají obejít. V následujících odstavcích bych proto rád stručně zmínil alespoň některé konkrétní problémy, na které je dobré dávat si pozor, ať již jste v pozici uživatele, či poskytovatele.
Jedním z těch nejznámějších bylo tradičně sniffování, tedy „odposlouchávání“ hesel/dat (možná i proto, že tento způsob bývá rovněž považován za nejjednodušší a nadto popisováno v celé řadě článků, pročež ho i spousta začínajících crackerů s velkou oblibou zkouší). Pokud se schopný útočník jednou dostal na router (nebo obecně jakýkoliv „průchozí stroj“), neštěstí mohlo být hotovo. Protékající data jsou sice stále šifrována, ale není zase až tak složité neopatrným návštěvníkům podstrčit falešný SSL server, kde dojde k jejich dekódování a přečtení. Existuje více způsobů, jak komunikaci uživatelů někam (např. na localhost) přesměrovat.
Tak třebas u routerů používajících iptables stačilo do PREROUTING zkrátka přidat takové pravidlo, které změnilo cíl. Jakmile se cesta jednou nasměrovala k vybranému portu routeru, zbývalo k němu již jen připojit onen „SSL server“ – kteroužto funkci stále na výbornou zastane populární prográmek Stunnel, doplňující SSL šifrování k těm programům, které ho jinak nepodporují. Aby toto všechno fungovalo, musí mít ovšem vetřelec při ruce i nějaký ten podepsaný certifikát. Nu a právě s ním bude zpravidla úspěšný jen tehdy, pokud je současně uživatel dostatečně neopatrný a navzdory varování prohlížeče ho bez rozmýšlení akceptuje.
V současnosti už většině útočníků stačí zaměřit svoji pozornost rovnou na cílové počítače a neobtěžovat se s routery. Občas se ale najde dokonce i někdo natolik vynalézavý, aby dokázal ukrást přímo certifikát od certifikační autority. Svého času právě touto cestou zmizely dva „kousky“ od VeriSignu, navíc určené k podepisování kódů (tedy se za ně dal bez problémů schovat třebas nebezpečný virus). Tehdy je z pohledu uživatele prakticky nemožné se bránit, jelikož neexistuje žádný rozumný důvod, proč takovému certifikátu nedůvěřovat. Naštěstí se jedná o velmi ojedinělé události.
Zatímco ve výše popisovaném případě sniffování se dopouští osudové chyby sám uživatel, nyní se podíváme pro změnu na zoubek poskytovatelům. Během nedávného Chaos Communication Campu (C3) (http://en.wikipedia.org/wiki/Chaos_Communication_Camp) přišla firma Canola & Jones s tvrzením o masovém rozšíření veskrze špatných implementací SSL. Toto zjištění je ovšem svým způsobem alarmující, neboť nejsou-li ani sami provozovatelé serverů či výrobci softwaru v otázce bezpečnosti dostatečně zodpovědní, jen těžko pak totéž očekávat od jejich klientů.
Mezi ty nejběžnější chyby přitom patří takové banality, jako již zmiňované používání expirovaných, eventuálně rovnou úplně špatných (www.adresa.cz vs. adresa.cz) certifikátů. Mnozí stále ještě provozují vysloveně zastaralé a nebezpečné technologie typu RC-4 (40bit), nebo SSL 2. A aby toho všeho nebylo málo, neuvěřitelný zmatek panuje přímo i v oblasti certifikačních autorit.
V dané souvislosti lze z historie připomenout řekněme známou chybu Internet Exploreru, kdy chybná implementace způsobila provádění pouze částečné kontroly digitálních certifikátů namísto kontroly úplné. Kvůli tomu IE akceptoval i certifikáty vytvořené za účelem oklamání uživatelů (viz sniffování), neboť sice prověřoval platnost konkrétního certifikátu, ale nešel přitom až ke „kořenové“ autoritě. Proto, jste-li provozovatel aplikace, mějte na paměti, že prostá implementace SSL je v zásadě k ničemu, pokud se současně nadále nestaráte i o jeho průběžné testování a odhalování případných nedostatků.
PŘEDPLATNÉ
ČLÁNKY DO MAILU