OpenSSL tvoří knihovna pro šifrování a ověřování totožnosti a k ní příslušející programy. S jejím využitím se setkáte hlavně u „https“ – „HTTP over SSL“ serverů, ale používá se i v jiných situacích, kdy je potřeba při přenosu šifrovat data protokolu, který sám šifrování neimplementuje. Používá se často také pro šifrování pošty – „POP3 over SSL“, „IMAP over SSL“ a „SMTP over SSL“.
Teorie
V prvním dílu se budeme zabývat hlavně principy fungování SSL a osvětlíme si některé pojmy.
Upozornění: Nepovažuji se za nijak velkého odborníka na SSL a šifrování. Zde uvedená teorie slouží hlavně k tomu, aby čtenáři měli alespoň minimální znalosti principů SSL a šifrování a dále uváděné praktické příklady opravdu chápali a ne jen bezmyšlenkovitě opisovali.
Šifrované SSL spojení se vytvoří v principu tak, že hostitelé naváží normální TCP spojení, poté se provede úvodní „potřesení rukou“, při kterém se případně ověří certifikáty a vymění se šifrovací klíče. Pak po spojení začnou téci šifrovaná data zapisovaná a čtená aplikacemi a zašifrovaná OpenSSL.
Certifikát
Certifikát slouží k ověření identity. Dá se používat i pro identifikaci osob, ale my se s ním budeme setkávat zejména jako s prostředkem pro ověření autenticity serveru, ke kterému se připojujeme.
Poznámka na okraj: Pokud vím, tak certifikáty vydávané u nás pro tzv. digitální podpis například pro účely elektronického podání daňového přiznání jsou právě SSL certifikáty.
K čemu ověření identity serveru? Například když budete chtít získat něčí heslo do systému, který není pod vaší kontrolou, můžete na svém serveru vyrobit maketu přihlašovací stránky daného systému. Ta ale bude zadané jméno a heslo posílat vám (útočníkovi). Pak stačí, aby se oběť spojila s vaší maketou místo s pravým serverem (přesměrování IP, pokud máte v moci router, případně ARP poisoning, DNS přesměrování, …) a zadala přihlašovací údaje. A máte vyhráno.
Certifikační řetěz (Certificate Chain)
Ale vygenerovat si certifikát znějící na libovolné jméno není problém, jak ostatně uvidíte dále. Jak tedy poznat, že certifikát serveru je opravdu pravý? V SSL se to řeší tak, že certifikát je vždy podepsán. Buď může být podepsán sám sebou (tzv. Self-signed Certificate), nebo je podepsán jiným certifikátem, tzv. certifikační autoritou (Certificate Authority, CA).
Certifikát CA může být rovněž podepsán nějakou jinou certifikační autoritou. Filozofie je taková, že do uživatelského SW jsou (pokud možno nějakým bezpečným způsobem) nahrány certifikáty těch autorit, kterým uživatel věří. U browserů se při instalaci automaticky nainstalují i certifikáty důvěryhodných veřejných autorit. Například v instalaci Mozilly je jich přes šedesát.
Pokud autorita, které uživatel věří, podepsala nějaký certifikát, bere se za to, že dotyčný certifikát je autentický (pravý, důvěryhodný). Pokud je tímto certifikátem podepsaný nějaký jiný, je tento také pravý. A tak dále. Takže pokud se tímto řetězem dokážeme dobrat až k certifikátu, který nám server poslal, je certifikát pravý.
Další vlastnosti certifikátu
U certifikátu jsou uloženy (kromě podpisu) i tyto údaje:
- Common name (CN): To je důležité pole, udává, koho certifikát identifikuje. Obsahuje tedy například jméno serveru.
- Platnost: Každý certifikát má platnost omezenou, a to počátečním a koncovým datem. Prostě neplatí navěky.
- Veřejný klíč: Používá se při šifrování – viz dále.
- Další údaje: Jméno, e-mail a adresa toho, komu byl certifkát vydán. Jsou orientační, SSL z nich nic neusuzuje.
Klíče
SSL používá klasickou kryptografii s párem soukromý+veřejný klíč. Strany si na začátku vymění veřejné klíče. Když posílají data, zašifrují je veřejným klíčem protistrany a pošlou. Protistrana je rozšifruje svým soukromým klíčem.
Poznámka: Pokud v dalším textu mluvím o „klíči“ bez bližšího určení, zda se jedná o veřejný či soukromý klíč, míním tím soukromý klíč.
Z toho pro nás vyplývá, že k soukromým klíčům by se neměl nikdo dostat, jinak je schopen komunikaci rozšifrovat, a to i „ze záznamu“, tedy v případě, kdy si zaznamená šifrovanou komunikaci, ke klíči se dostane později a tento není dosud změněn.
Proto obsahuje SSL možnost chránit soukromý klíč heslem. Klíč je jím zašifrován a toto heslo je nutné zadat, aby mohl být klíč rozšifrován a použit. Bohužel to znamená lidskou asistenci při startu (například) HTTP serveru. To je ale často nežádoucí, neboť server potom nemůže naběhnout rychle sám v případě nějakého výpadku.
Zneplatněné certifikáty
Některé certifikáty mohou být zneplatněny ještě před uplynutím jejich doby platnosti (například proto, že uniknou jejich klíče). Tyto certifikáty jsou zveřejněny v tzv. Certificate Revocation List (CRL). Ale pro účely obyčejného zabezpečení dat na lokální síti je asi nevyužijete.
To by bylo pro dnešek vše. První díl byl spíše teoretický, ale nebojte se, příště už se podíváme na praktické příklady.