Skype – bezpečnost a soukromí (2.)

V předchozích dvou dílech jsme si popsali základy fungování Skype a první část analýzy bezpečnosti a soukromí. V té nyní budeme pokračovat dále.

Síťové předpoklady provozu za firewall/NAT

Skype si v nouzi vystačí s jediným povoleným, z počítače iniciovaným spojením přes port 80 na protokolu TCP. Protože touto třídou soketů je poptáván běžný webový provoz, Skype bude (s pomocí retranslace) pracovat za téměř jakýmkoliv NAT/firewallem. Podle dokumentace [PDF, 661 kB] Skype ale bude blokován tehdy, pokud firewall bude kontrolovat přítomnost protokolu HTTP v 80/TCP, protože do něj se provoz Skype již nebalí.

Pozn.: až na další overhead v principu ale není problém nakonec zabalit veškerý provoz do regulérního HTTP. Umí to dávno např. Groove, což byla první P2P síť, u níž jsem bolehlav bezpečnostních specialistů, tunelování se skrz HTTP, viděl. Groove byla založena Rayem Ozziem (autorem Lotus Notes) po jeho odchodu z IBM, nyní patří Microsoftu. U Groove jsou releovací servery provozovány buď zákazníkem, nebo k dispozici jako placená služba.

Skype však bude preferovat, pokud mu povolíte všechna odchozí spojení pro TCP i UDP na porty 1024 a vyšší. NAT/firewall by přitom na odchozí pakety UDP měl reagovat stylem „stavové inspekce paketů“, tj. povolit a správně adresovat zpět všechny odpovědní pakety UDP, přičemž stav by měl zůstat zapsán aspoň 30 sekund, doporučuje se ale až hodinu (můj názor: nastavte minutu).

Pro UDP hole punching Skype preferuje, aby NAPT překládal odchozí UDP port z počítače konsistentně, tj. pro shodný UDP port z počítače u rámců jdoucích na různé veřejné adresy používal i shodnou veřejnou IP adresu a shodný UDP port. Kromě portu 80 bude Skype povděčen i za otevření 443/TCP (tj. běžně pro HTTPS) na NAT/firewall. Inklinace k UDP je logická, neboť se těmito rámci lépe přenáší hlasové proudy, TCP je naopak vhodnější pro bezpečnou signalizaci.

Na počítači se Skype se při běhu vždy otevře aspoň jeden port (je možné jej v konfiguraci programu změnit, implicitně mívá náhodnou hodnotu z čísel nad 1023) pro příchozí i odchozí komunikaci v UDP. Kromě toho Skype používá porty (v testu od 1030 výše) pro různá spojení TCP. Supernody zřejmě ještě otvírají porty 80 a 443 pro příchozí komunikaci.

Vestavěný firewall ve Windows XP si Skype přizpůsobí pro svůj provoz většinou sám, jiné musíte nastavit. Podrobněji viz dokumentaci výrobce [PDF, 661 kB].

Náběh programu po přihlášení

Zkonfigurovaný program Skype v1.3.0.45 od spuštění až do oznámení stavu login (přihlášení) navázal v mém případě během 25 sekund spojení pomocí UDP s asi 45 různými počítači, pravděpodobně supernody, z toho jen tři protějšky neodpověděly. Některé z nich jsou uvedeny v souboru shared.xml, jiné nikoliv. V rámci náběhu se zřejmě provádí login, zprostředkovaný přes supernody. Během náběhu vzniknou dvě TCP spojení hned na počátku (ta jsou později ukončena) a dvě pár vteřin před dokončením loginu. Je možné, že Skype provádí autentizaci (login) paralelně dvojcestně pro vyšší spolehlivost. Zdá se mi, že strategií Skype je nejprve navázat spojení na co nejvíce supernodů a získat adresy i dalších supernodů, než má ve svém souboru shared.xml, teprve pak probíhá login. Zpoždění začátku loginu by mohlo být způsobeno generací páru klíčů RSA. Vlastní autentizace běží spíše přes druhý pár TCP spojů než přes ten prvotní. Po náběhu a loginu druhá dvojice spojení udržuje v kombinaci spoje TCP i UDP zasíláním krátkých paketů, poněkud arytmicky s intervaly 10 nebo 20 sekund. Zdá se, že tento způsob udržované komunikace je používán pro „pohotovostní“ spojení k některým supernodům a vysvětloval by 30sekundový požadavek na držení stavu spoje UDP na firewallech.

Během náběhu vzniká jediný otevřený dotaz HTTP na server ui.skype.com s obsahem čísla použité verze programu Skype a hash hodnoty uživatele (ačkoliv klient měl nakonfigurováno netestovat přítomnost nových verzí).

Vrácená odpověď 1.1.0.79 je nejasná. Smysl může spočívat v porovnání schopnosti projít protokolem HTTP s průchodností postupu login přes P2P síť. Skype by tak měl zpětnou vazbu, jaká část uživatelů se do sítě hlásí a neuspěje kvůli zádrhelům na firewallech apod.

Jiné analýzy uvádí, že Skype příležitostně zjišťuje stav své konektivity do Internetu komunikačními testy s některým protějškem. Po náběhu ze sítě též obdrží informace o stavu připojení svých kontaktů, případně může natáhnout informace o svém profilu; pokud se přihlašuje z jiného počítače než původně, mohou mu dojít nacachované chatové zprávy apod.

Provoz při volání a kodeky

Při začátku volání otevřel můj Skype další dva TCP spoje (možná i volání je paralelní), přičemž první z nich se nakonec použil pro proud hlasu. Brzy po počátku volání byl dvakrát zkoušen UDP hole punching vůči veřejné adrese protějšku (15 rámců s postupně se zvyšujícím číslem portu), ale bez úspěchu. Komunikace pak pokračuje přes čerstvě kontaktovaný supernode, před navázáním spojení se s ním otvírá ještě třetí TCP spoj. Prvotní spojení hovoru se s protějškem navazovalo skoro minutu (další pokusy jsou již v řádu několika sekund). Všechny tyto tři TCP spoje jsou doprovázeny i pakety UDP. Jeden hlavní spoj TCP+UDP je pro přenos hlasu, další dva mohou sloužit buď jako záložní trasy, nebo pro případný přenos souborů nebo chatu, nebo jako záloha signalizace, kdo ví. Druhé dva spoje byly opět udržovány s arytmií 10sekundových a 20sekundových pauz.

Wikipedia uvádí, že Skype užívá kodek iLBC, pro nějž existuje i zdarma otevřená a šiřitelná verze. Ve studii [PDF, 286 kB] se uvádí, že Skype používá asi iLBC nebo iSAC, a ověřilo se, že kodek je schopen přenášet frekvence 50–8000 Hz, tj. jedná se o tzv. širokopásmový kodek (v kontrastu s 0,3–3,4 kHz tradičního telefonního kanálu). Mé testy ukazovaly rámce s periodou 60 ms, kterou má nativně iSAC. Alternativně by možná přicházelo do úvahy sdružení dvou rámců iLBC s periodou 30 ms za cenu vložení zpoždění jednoho paketu – tomu by zas dobře odpovídala velikost dat v rámcích. V mnou prováděných testech ale docházelo k mírnému nárůstu provozu, pokud na lince hovořily obě osoby zároveň – to by opět hovořilo spíše ve prospěch kodeku iSAC, který se adaptuje.

Je možné, že Skype používá i oba kodeky. Každopádně má v této oblasti Skype něco společného s firmou Global IP Sound (která licencuje iLBS i iSAC), protože ta jej vede jako svou zákaznickou referenci.

Efektivní průměrná zátěž provozu na ethernetu (tj. pro oba směry hovoru celkem a včetně ethernetových + IP + UDP nebo TCP režií) při hovoru byla cca 5,5 kB/s, s maximem asi 7,5 kB/s. Vlastní přenášená data v každém směru měla velikost 110 bytů (TCP), resp. 108 bytů (UDP) s výše uvedenou periodou cca 60 ms. U proudů TCP pakety fluktuovaly o +/- 20 ms, u UDP byla hodnota lepší – jen +/- 10 ms.

Je možné, že pokud bych u sebe použil výkonnější počítač, byla by vyšší i rychlost vzorkování nebo jinak kvalitnější zpracování zvuku a výsledně vyšší datový tok. Hodnota toku 5 kB/s by ale přesně odpovídala studii [PDF, 286 kB]. Podle ní Skype prohlašuje, že zátěž sítě může být 3–16kB/s.

Protože oba naše pražské nody byly za NAT, hovorový kanál byl vesměs retranslován přes supernode, který byl lokalizován v Atlantě (USA). Můj odchozí směr hlasu šel vždy přes TCP, zatímco příchozí přes UDP. Při čtvrtém volání se Skype na chvíli podařilo prorazit (punch hole) přes můj NAT – příchozí směr přicházel v UDP přímo z veřejné adresy mého protějšku, zatímco odchozí stále retransloval v TCP přes supernode. Fluktuace rámců UDP přitom dále klesla asi na +/- 5 ms.

Můj protějšek používal pro monitoring spojení program NetLimiter. Podle něj se prý jeho hlavní retranslační protějšek občas měnil (včetně např. adresy 164.235.249.2), i když u mě zůstával neměnný. Je tedy možné, že směrovací cesty hovorů v síti Skype nevedou vždy podle obrázku z minulé části, ale vinou se poměrně různě. Mimochodem např. NetLimiter by asi byl použitelný pro přidělení pásma jednotlivým aplikacím a mohl by Skype udržet před přechodem do režimu supernode, nebo alespoň omezit rozsah čerpaného pásma. Podobně by asi posloužil NetPeeker, používaný ve zmiňované studii pro laboratorní „přiškrcení kanálu“.

Kvalita hovoru

S kvalitou hovoru jsem byl a nebyl spokojen. Na jedné straně je totiž hlas přes Skype běžně „plnější“, zároveň ale kvalita během hovoru kolísá, hlas se může tlumit nebo „plechovatět“ a občas (např. po hodině) se spojení dokonce rozpadne – lze ho ale znovu rychle navázat. Nepříjemné je zpoždění – při releování přes supernode v USA bylo zjištěné zpoždění (asi 400 ms), pro hovor mezi dvěma uživateli v Česku již nepříjemné. Hovor s protějškem z Kalifornie měl paradoxně zpoždění menší a byl přirozenější (zda je supernodem, nevím).

Změny Skype

Naprosto se nelze spoléhat na to, že jednou zjištěné věci o Skype budou platné i zítra nebo později. Např. ve studii [PDF, 286 kB] ze září 2004 se uvádělo, že tabulka Host Cache je uložena v registrech Windows. U sledované verze 1.2 (a zřejmě i 1.3) tomu tak není – v registrech nic podobného nalezeno nebylo, zato je 200 IP adres a portů (z nichž s některými se skutečně komunikovalo) v souboru shared.xml. Tato implementace je i logičtější z hlediska multiplatformní implementace Skype. Další změnou vůči zmiňované studii je, že program Skype jako node již asi nekomunikuje s login serverem přímo, ale prostřednictvím supernodů. Příčinou bylo asi to, že po odhalení IP adresy login serveru bylo na firemních firewallech příliš snadné tuto adresu zakázat a znemožnit tak běh Skype. Platformy použité ve studii na provoz Skype verzí 1.2 a 1.3 nedostačují. Obdobně nelze zaručit, že nezastarají informace z tohoto článku.

Pozn.: chcete-li ve firmě zamezit spuštění Skype, koncentrujte se ne až na síťový provoz a firemní firewall, ale spíše na nástroje pro správu aplikací na desktopech a řízení jejich přístupu do sítě.

Resumé

Skype mi přijde jako určitý přelom v éře Internetu. Možná dá vzniknout nové úrovni globalizace, neboť levná hlasová (a později i video) komunikace představuje kvalitnější úroveň spojení než dosavadní e-mail, který je navíc zaspamovaný. Logickým trendem by pak bylo zvyšování profesní specializace a sestavování rozptýlených týmů.

Hlas přes IP a jeho provedení ve Skype určitě je killing aplikací pro xDSL („broadband“). Po Skype se již nelze vymlouvat na to, že pásmo a dostatečné limity potřebují jen stahovači. Skype také poskytuje důkaz konceptu, že internetová telefonie je již možná. Skype může zamotat hlavu tradičním telefonním operátorům včetně Českého Telecomu. Vehementně totiž útočí na segment domácností a malých firmiček, ve kterém se dosud konkurence uplatňovala jen těžko.

Pro mne zůstává významným bezpečnostním záporem, že se jedná o zcela uzavřené protokoly i software, o nichž neexistuje ani žádné bezpečnostní hodnocení vytvořené důvěryhodnou třetí stranou, např. v metodologii Common Criteria apod. Na mé hlavní pracovní počítače Skype zatím nesmí.