Jak na OpenSSL 3

Konfigurace serveru

Certifikát (vygenerovaný v minulém dílu) nezačne server používat automaticky, ale je potřeba mu říci, kde ho má hledat. Například u Apache se soubory obsahující klíč a certifikát určují pomocí direktiv SSLCertificate­KeyFile a SSLCertificateFile. Ostatní servery mají podobné direktivy nastavující soubory, ze kterých má být klíč a certifikát čten. Pokud vám nechce konfigurace ze „záhadných“ důvodů fungovat, ověřte si, že server může číst jak soubor certifikátu, tak i klíče. Často bývá klíč čitelný pouze vlastníkem (což je správně), ale server běží na vyhrazeného uživatele, který je různý od vlastníka klíče.

Ověření

K ověření, zda a jaký SSL certifikát server používá, nám poslouží opět starý známý program openssl. Tentokrát v módu klienta, například:

openssl s_client -connect klient1.ebanka.cz:https

Parametry:

• s_client – Mód SSL klienta
• -connect <server>:<port> – Kam se budeme spojovat

Program vypíše certifikát, certifikační řetěz atp. Podstatný je první článek řetězu: Certificate chain
0 s:/C=CZ/ST=Czech Republic/L=Pra­gue/O=Expandia Banka a.s./OU=Expandia Banka a.s./OU=Terms of use at www.verisign.com/RPA ©01/CN=klient1­.ebanka.cz

Vidíme, že certifikát byl vydán Expandia Bance na jméno (CN) klient1.ebanka.cz. Pokud chceme zjistit detaily certifikátu, můžeme si ho uložit do souboru (například pomocí copy-paste textu od BEGIN certificate do END certificate včetně) a pak vypsat v textové podobě. V tomto případě můžeme detaily o certifikátu získat i z WWW browseru, ale výše uvedený postup funguje na všechny služby používající SSL, například pop3s.

Problémy s 56bitovým šifrováním na Windowsech

Některé starší verze Windows ještě podléhaly exportním opatřením na vývoz „silných“ šifrovacích technologií, a proto se dodávaly jen s 56bitovým šifrováním. To může působit problémy některým aplikacím vyžadujícím 128bitové šifrování.  Jak silné šifrování prohlížeč podporuje, se lze dočíst v dialogu O programu (About).

Řešením je nainstalovat 128bitové šifrování (je na to poměrně malý balíček, bohužel jsem nenašel žádný veřejný odkaz :-( ), nebo nainstalovat novější verzi Exploreru.

Problémy HTTP přes SSL

SSL se často používá pro bezpečný přenos HTTP (https: protokol). Zde ovšem narážíme na jeden poměrně zásadní problém. V současné době je velmi rozšířen tzv. name virtual hosting – na jednom počítači je uloženo více webů, které jsou přístupné pod různými DNS jmény. A zde naráží kosa na kámen.

Klient porovnává jméno uvedené v certifikátu se jménem počítače, na který se připojuje. Když se připojuje na www.marketa.cz a dostane (byť důvěryhodný) certifikát pro www.alzbeta.cz, tak uživateli řekne, že certifikát zní na špatné jméno. Ba co více. Pokud je certifikát vydán pro marketa.cza klient se spojuje s www.marketa.cz, rovněž protestuje.

Řeknete si, dobře, tak proč server nepošle certifikát na jméno, se kterým se browser spojuje? Jednoduše proto, že ho neví. (Tedy až na jeden speciální případ zmíněný níže.) Certifikáty se vyměňují už při navazování spojení, ale HTTP požadavek, který jméno obsahuje, se může poslat až po navázání.

Jak to tedy řešit? Je několik možností, ale každá má své mouchy:

• Smířit se s hlášeními browseru a odklikávat je.
• Mozilla akceptuje (nebo to v některé verzi uměla) certifikát pro doménu pro všechny servery v této doméně. Tedy pokud jste si udělali certifikát pro firma.cz, mohl ho server posílat i pro servery mzdy.firma.cz, dochazka.firma.cz atd.  a Mozilla nic neříkala. Bohužel, co vím, funguje pouze v Mozille.
• Mít na počítači (respektive jeho rozhraní) tolik IP adres, kolik mám SSL webů. Potom mohu pro každé IP/jméno posílat správný certifikát. Ale to je dosti náročné na konfiguraci a na IP adresy (i když možná s příchodem IPv6 se situace změní a toto bude standardní řešení).
• Mít na počítači jen jeden SSL web a v jeho podadresářích vlastní weby/aplikace. Například na https://ssl.fir­ma.cz/mzdy/ jsou mzdy, https://ssl.fir­ma.cz/dochazka/ je docházka atp. Poměrně dobré řešení, má dvě nevýhody:
• Jméno webu se neukazuje v liště jako jméno počítače – to může být poněkud matoucí pro uživatele a u „značkových“ webů nevhodné z marketingových důvodů.
• Nefungují absolutní odkazy na webech. Respektive fungují, ale musí obsahovat jméno webu – trochu tím trpí přenositelnost HTML kódu.

Objekty z nezabezpečeného serveru

Při použití SSL na WWW stránkách se můžete setkat ještě s jedním problémem. Stránky často dotahují obrázky z jiného serveru. Prohlížeče (jmenovitě Internet Explorer) však vyžadují, aby všechny komponenty stránky stahované přes SSL byly rovněž posílány přes SSL zabezpečené spojení. To je poměrně logický požadavek, podstrčením špatného obsahu rámce (frame, iframe), javascriptu nebo v některých případech i obrázku by se dala také nadělat pěkná neplecha. Pokud máme nad těmito komponenty kontrolu, není toto většinou problém. Horší je, pokud musíme do stránky umisťovat kód třetích stran (reklama). Cizí administrátoři se obtížně přesvědčují, že by měli rozjet HTTPS server s důvěryhodným certifikátem.

Malý kvíz na závěr

Tím bych náš krátký seriál skončil. Ale ještě vám dám něco na potrápení vašich mozkových buňek: Kdyby prohlížeče akceptovaly certifikát znějící na IP adresu, výše uvedené problémy by neexistovaly. Ale neakceptují ho a má to dobrý důvod. Přijdete na něj?