Obsah
Úvod
Nejprve vysvětlím několik společných pojmů, které se budou používat v průběhu celého textu.
Asymetrické šifrování
Princip asymetrického šifrování spočívá v tom, že se místo klasického jednoho klíče, kterým se zpráva šifruje i dešifruje, používá pár klíčů - soukromý a veřejný. Zprávu zašifrovanou pomocí veřejného klíče je možná dešifrovat jen pomocí klíče soukromého a naopak.
Veřejný klíč se, jak již název napovídá, zveřejní, soukromý klíč je nutné pečlivě střežit (oblíbenou metodou poslední doby jsou například čipové karty, které znemožňují jej získat a vyžadují pro přístup k němu zadání číselného kódu - PIN). Pokud tedy chcete někomu poslat zprávu, zašifrujete ji veřejným klíčem adresáta - to zajistí, že rozšifrovat ji dokáže jen držitel odpovídajícího soukromého klíče. Naopak, pokud někdo zašifruje zprávu svým soukromým klíčem, dá se jejím úspěšným dešifrováním pomocí veřejného klíče určit autor.
PKI
Problém s přiřazením identity k danému páru klíčů (fakticky stačí ke klíči veřejnému) řeší PKI - Public Key Infrastructure. Jejím cílem je zajistit, že klíč patří tomu, kdo to tvrdí, a že není podvržený.
Poměrně klasickou metodou jsou obvyklé X.509 certifikáty, které znáte například z webu. Obsahují údaje o držiteli (jméno, doména apod.), jeho veřejný klíč a několik doplňkových informací - platnost certifikátu, vystavitele a umístění CRL.
Platnost certifikátu určuje, kdy je certifikát validní - jeho platnost je obvykle omezena (např. na rok).
Vystavitel je osoba nebo organizace, která ručí za správnost uvedených údajů a potvrzuje ji svým podpisem tohoto certifikátu. Vzniká tak stromová struktura, kde v kořeni jsou tzv. kořenové certifikační autority, které je nutné ověřit "ručně".
CRL je zkratka z Certificate Revocation List. To je seznam odvolaných certifikátů. Pokud například někdo o svůj soukromý klíč přijde, může certifikát u nadřazené certifikační autority, která mu jej vydala, zneplatnit jeho uvedením v CRL.
MAC
MAC znamená Message Authentication Code. Slouží k ověření neporušenosti zprávy. Obvykle bývá tvořen pomocí hashovací funkce (např. SHA) z dat, ke kterým náleží, příp. obohacených o nějakou další hodnotu, která má ztížit jeho uhodnutí. Pokud MAC přijaté zprávy nesouhlasí, zpráva je obvykle zahozena s různými dopady na daný protokol (od ignorování až po okamžité rozpojení).
SSL
SSL je zkratka pro "Secure Sockets Layer" - protokol vymyšlený firmou Netscape. Je to obecný transportní protokol, který zajišťuje šifrovanou přenosovou cestu a nestará se o vyšší vrstvy. Může být proto použit jak pro HTTP, tak i ftp (=ftps), telnet apod. Skládá se ze dvou částí - Record Protocol a Handshake Protocol.
Record Protocol je nižší vrstva, která zajišťuje šifrování a slouží později i pro přenos aplikačních dat. Handshake Protocol zajišťuje sestavení spojení a ověření stran.
Record Protocol
Každá zpráva má dvou nebo tříbytovou hlavičku, která určuje délku dat ve zprávě. Ta sestávají ze tří částí:
- MAC - Je tvořen hashem z klíče, dat, paddingu a sekvenčního čísla. Toto číslo je 32b celočíselná hodnota bez znaménka a s každou zprávou roste.
- samotná přenášená data
- padding - Vycpávka, slouží k zarovnání délky zprávy na určenou hodnotu (např. kvůli použité blokové šifře).
Jakákoliv chyba při dešifrování zprávy (např. nesprávný MAC) znamená ukončení spojení.
Handshake Protocol
Handshake nastává při třech různých situacích:
- nové spojení - Žádost o sestavení zcela nového spojení.
- nedávné spojení - Spojení bylo nedávno sestaveno a žádá se o jeho znovupoužití - méně náročné než opakované vytváření spojení od úplného začátku.
- autentifikace uživatele
Nové spojení
Při sestavování spojení nejprve klient pošle serveru zprávu CLIENT-HELLO, ve které uvede "challenge" (kus nějakých dat) a seznam podporovaných šifer. Server na ni odpoví zprávou SERVER-HELLO, která obsahuje ID spojení, serverový certifikát a seznam šifer, které server podporuje. Klient podle svého uvážení vybere nějaký šifrovací algoritmus, který budou oba používat.
Klient ověří totožnost serveru, a pokud je spokojen, pošle mu master-key zašifrovaný veřejným klíčem serveru a další zprávu CLIENT-FINISHED, která obsahuje ID spojení zašifrované zapisovacím klíčem klienta.
Server odpoví zprávou obsahující challenge zašifrovanou svým zapisovacím klíčem a zprávou SERVER-FINISHED, kde pošle ID seance.
Nedávné spojení
Není nutné pokaždé složitě znovu vytvářet novou seanci od začátku, ale je možné použít nějakou nedávno vytvořenou. Sestavení spojení se od předchozího případu liší tím, že klient hned na začátku pošle i ID seance a server odpoví, jestli je ochoten ji znovu použít. Spojení je potom zakončeno stejným postupem jako v předchozím případě, pouze server nevymýšlí nové ID seance.
Použité klíče
V předchozí části o sestavení spojení jsou používány různé klíče:
- master key - z něj, challenge, předem definovaných dat a ID spojení se pomocí hashe vytvářejí čtecí a zapisovací klíče klienta.
- Čtecí klíč klienta odpovídá zapisovacímu klíči serveru a opačně se zapisovacím klíčem klienta. Tyto klíče dokáží vypočítat obě strany, pokud mají master key - klient ho vytváří a server ho získá dešifrováním zprávy od klienta, neboť má k použitému veřejnému klíči odpovídající klíč soukromý. Zbylé hodnoty jsou posílány nešifrovaně.
Ověření serveru
Pro zajištění důvěryhodnosti je potřeba ověřit platnost serverového certifikátu. Ověřují se tyto věci:
- nevypršela platnost certifikátu - ta je uvedena uvnitř, porovnává se s aktuálním časem
- je certifikát důvěryhodný - podepsala ho důvěryhodná certifikační autorita (viz PKI v úvodu)
- souhlasí podpis certifikátu s uváděnou CA - ověření podpisu pomocí veřejného klíče CA z jejího certifikátu
- souhlasí doménové jméno serveru s uváděným v certifikátu - připojujeme se opravdu k tomu, jehož klíč ověřujeme?
Pokud všechny body souhlasí, je serverový certifikát prohlášen za platný. Jinak je spojení ukončeno.
Ověření klienta
SSL umožňuje požadovat autentifikaci i po klientovi - tj. ověřit, kdo se k serveru doopravdy připojuje.
Pokud je požadováno ověření klienta, ten během sestavováni spojení zašle zašifrovaný blok dat, která znají server i klient, a svůj certifikát. Ověření na straně serveru je pak obdobné procesu u klienta. Kromě toho je samozřejmě možné ověřovat i další věci - například přítomnost klienta v nějaké databázi oprávněných osob, určovat podle toho práva uživatele na serveru apod.
Odkazy
Podrobnější informace včetně popisu jednotlivých zpráv a paketů, obrázky a další jsou na následujících stránkách:
http://developer.netscape.com/docs/manuals/security/sslin/index.html
http://www.homeport.org/~adam/ssl.html
http://developer.netscape.com/tech/security/ssl/howitworks.html
SSH
Trocha historie
Původní verze SSH byla v roce 1995 navržena jako bezpečná náhrada unixových programů rsh, rlogin a rcp. O dva roky později byla sdružením IETF navržena verze 2, která řešila některé bezpečnostní problémy a rozšiřovala možnosti protokolu. Z původně jednoúčelového paketového protokolu pro vzdálený přístup se stal protokol flexibilní a vrstevnatý (více v kapitole o kanálech v SSH2).
SSH v1
Protokol SSH verze 1 je dnes již zastaralý a nedoporučuje se jej používat, i když jsou servery většinou zpětně kompatibilní.
Sestavení spojení probíhá následovně: klient nejprve pošle serveru žádost o sestavení spojení a oba se dohodnou na používané verzi. Server pak pošle klientovi svůj veřejný klíč, ten pomocí něj zašifruje vytvořený klíč sezení a pošle ho zpět serveru. V tuto chvíli mají oba společný klíč, který pak používají na šifrování komunikace. Klíč sezení se mění každou hodinu (viz bezpečnostní problémy).
Paket sestává z hlavičky, která určuje jeho délku, náhodného paddingu, typu paketu, dat a MAC. Část padding až data je šifrovaná. Jako MAC se používají funkce CRC32 a HMAC-SHA1. Typ a obsah dat je možné také komprimovat.
Autentifikace uživatele je možná pomocí hesla nebo veřejného klíče (RSA).
SSH v2
Verze 2 přináší zcela nový pohled na tento protokol - již to není jednolitá vrstva, ale je rozdělen na několik úrovní - Transport, Authentication a Connection.
Paket se skládá z hlavičky s délkou, délkou paddingu, dat, paddingu a MAC. Kromě MAC je zbytek šifrovaný. Data mohou být i komprimována. MAC se počítá ze zkomprimovaných, nešifrovaných dat obvykle pomocí algoritmů SHA1 a MD5.
Samotný návrh protokolu počítá s možností proprietárních rozšíření a poskytuje k tomu prostředky (jako např. jejich označování pomocí identifikátor@doména).
Sestavení spojení
Při sestavování spojení nejprve obě strany pošlou zprávu s verzí protokolu, software a poznámkami. Poté obě strany odešlou zprávu SSH_MSG_KEXINIT. Ta obsahuje náhodná data (cookie), algoritmus na výměnu klíčů, algoritmus pro klíč serveru a šifrovací, MAC a kompresní algoritmy a jazyky pro každý směr zvlášť. Poté se vybere vyhovující algoritmus pro výměnu klíčů.
Výměna klíčů
Výsledkem výměny klíčů jsou dvě hodnoty - sdílené tajemství K a hash H. Z nich jsou potom vygenerovány identifikátor sezení (ten se vytváří z první výměny klíčů a později se již nemění) a klíče pro komunikaci klienta a serveru (jsou pro každý směr jiné).
Obvyklý algoritmus pro výměnu klíčů je Diffie-Hellman. Během ní pošle server klientovi svůj klíč a vymění si několik čísel, z nichž posléze oba vypočítají K a H.
Výměnu klíčů je možné kdykoliv opakovat a doporučuje se čas od času to provést (i v závislosti na množství přenesených dat), aby se zabránilo útokům na opakovaní v datech.
Po provedení výměny klíčů již existuje šifrované spojení. Poté klient zažádá o nějakou službu (obvykle autentifikaci).
Autentifikace
Klient požádá o autentifikaci zprávou SSH_MSG_USERAUTH_REQUEST. V ní uvede své uživatelské jméno, požadovanou službu a metody autentifikace, které podporuje. Pokud server autentifikaci odmítne, odpoví zprávou SSH_MSG_USERAUTH_FAILURE, kde uvede, které metody může klient ještě použít.
Uvedu několik základních:
- none - Bez autentifikace, obvykle se používá pro zjištění metod podporovaných serverem
- password - Klasické ověření heslem. Heslo se sice posílá textově, ale celé spojení je již šifrované.
- publickey - Ověření pomocí veřejného klíče. Je to jediná povinná metoda, kterou musí server podporovat. Klient nejprve pošle jméno algoritmu, který veřejný klíč používá, a samotný klíč. Server zkontroluje, zda je tento veřejný klíč možné použít k autentifikaci daného uživatele, a v kladném případě odpoví zasláním těchto údajů zpět klientovi. Ten pošle obdobnou zprávu jako prve, ale na konec připojí podpis svým soukromým klíčem přes identifikaci sezení a celou první zprávu. Server má tyto informace také k dispozici, takže může ověřit, že klient disponuje odpovídajícím soukromým klíčem.
Kanály
Všechna spojení v rámci SSH2 jsou uskutečňována v tzv. "kanálech" - ty jsou pak skládány do jednoho spojení nad transportní vrstvou. Kanály jsou označovány čísly (mohou se na obou stranách lišit) a tok dat v nich je kontrolován tzv. okny, která určují, kolik je jich ještě možné odeslat.
Kanál se otevírá zprávou SSH_MSG_CHANNEL_OPEN, která obsahuje typ kanálu, jeho označení u odesilatele, počáteční velikost okna a maximální velikost paketu.
Data se v kanálech posílají zprávou SSH_MSG_CHANNEL_DATA, která obsahuje délku dat a samotná data. Velikost okna se zmenší o danou délku (nikdy nesmí poslat víc dat, než je aktuální velikost okna). Okno se dá zvětšovat zprávou SSH_MSG_CHANNEL_WINDOW_ADJUST, která obsahuje požadovaný objem zvětšení.
Kanál se zavírá zprávou SSH_MSG_CHANNEL_EOF, příp. SSH_MSG_CHANNEL_CLOSE (kterou musejí poslat obě strany). Spojení se zavře až po uzavření posledního kanálu (např. spojení otevřeného přes port forwarding).
Služby
SSH verze 2 poskytuje množství služeb. Tady je krátký seznam některých z nich:
remote console
Náhrada původního rsh. Umožňuje pracovat vzdáleně na jiné konzoli. Otevírá se žádostí o nový kanál se službou "shell".
Existuje omezená varianta, služba "exec", která pouze spustí na vzdáleném počítači příkaz, ale nepoužívá shell ani konzoli.
port forwarding
Často používanou službou je tzv. tunelování portů - umožňuje posílat data z jednoho konce spojení na druhý. Existují dvě varianty:
- přesměrování místních portů - Všechna data, která přijdou na místní port daného stroje, jsou poslána pomocí ssh na druhý počítač a z něj na zadanou adresu (ta nemusí být nutně na onom stroji). Klasický případ použití je třeba pop3 nebo telnet, kdy ssh zajišťuje šifrování (a volitelně i kompresi).
- přesměrování vzdálených portů - Zrcadlový opak předchozího případu - data ze vzdáleného počítače jsou přenesena na místní a z něj dále rozeslána. Možné použití je například pro překonání NATu nebo firewallu na počítače ve vnitřní síti.
SFTP
Protokol SFTP je náhradou protokolu pro přenos souborů SCP. Poskytuje mnohem vyšší komfort (například navazování, práce s časovými zónami apod.). SFTP je subsystém, tj. není přímo požadovanou součástí samotného protokolu SSH.
X11 forwarding
Dalším obvyklým použitím SSH je forwardování komunikace X serveru, kdy je možné pracovat v grafickém režimu na vzdáleném počítači. I zde může ssh nahrazovat chybějící zabezpečení a poskytovat kompresi přenášených dat.
další
Protokol SSH poskytuje i další možnosti - předávání proměnných prostředí, signálů, návratových hodnot atp.
Odkazy
Základním zdrojem informací je nepochybně přímo specifikace protokolu SSH verze 2. Jako další mohou posloužit třeba tyto stránky:
http://java-hush.sourceforge.net/architecture.html
http://java-hush.sourceforge.net/transport.html
http://java-hush.sourceforge.net/connection.html
http://secu.zzu.edu.cn/book/NetWork/NetWorkingBookshelf_2ndEd/ssh/ch07_04.html
http://secu.zzu.edu.cn/book/NetWork/NetWorkingBookshelf_2ndEd/ssh/ch03_03.html
http://secu.zzu.edu.cn/book/NetWork/NetWorkingBookshelf_2ndEd/ssh/ch03_04.html
http://secu.zzu.edu.cn/book/NetWork/NetWorkingBookshelf_2ndEd/ssh/ch03_05.html