SSL na Apache: Jak dostat z certifikátu maximum

24.10.2014 | Jindřich Zechmeister

Samotné nasazení SSL certifikátu automaticky nezajistí maximální bezpečnost návštěvníků serveru. Je potřeba protokol HTTPS správně nastavit, aby použité šifrovací metody odpovídaly aktuálním bezpečnostním požadavkům. V dnešním článku se dozvíte, jak HTTPS na Apache nastavit co nejlépe, a využít tak certifikát na maximum.

Jak vyladit zabezpečení Apache

Následujících několik kroků vám pomůže nastavit server Apache v souladu s aktuálními bezpečnostními doporučeními.

Zakažte starý protokol SSLv3 a SSLv2

Protokoly SSL jsou již velice staré, a nejsou považovány za bezpečné. Starší z obou protokolů SSLv2 je již delší dobu považován za nebezpečný. Nedávno byl popsán praktický útok na protokol SSLv3, který je na serverech většinou povolen pouze kvůli kompatibilitě starších klientů. O této zranitelnosti zvané POODLE jsme informovali v článku Jak vyřešit POODLE zranitelnost SSLv3.

Zastaralé protokoly SSL už skutečně nejsou potřeba, a jsou na serveru pouze rizikem (útočníci je používají k tzv. downgrade útoku). Jejich úlohu zastoupily protokoly TLS 1.0 - 1.2, které moderní prohlížeče používají. Oba staré SSL protokoly na serveru zakažte a nepoužívejte.

Nastavte nové pořadí preferovaných a silných šifer, zakažte slabé

Na začátku šifrovaného spojení se klient se serverem domluví, jakým způsobem budou šifrovat. Vymění si krom jiných informací i seznam šifer, které podporují, a pořadí, v jakém je preferují. Celému procesu ustavení šifrované komunikace mezi klientem a serverem se říká Handshake.

Na serveru je v konfiguraci Apache nastaveno, jaké šifrovací algoritmy server preferuje, a v jakém pořadí je bude klientovi nabízet. Jedná se o důležitý prvek zabezpečení, protože staré a slabé šifry jsou dnes neúčinné a snadno prolomitelné.

Nastavení najdete v konfiguračním souboru daného webu. Na Ubuntu serveru je nastavení aktivního webu se SSL v umístění /etc/apache2/sites-enabled/default-ssl.conf.

Najděte si direktivu SSLCipherSuite, kde je uvedeno pořadí šifer. Pokud chcete některou z nich zakázat, stačí před její zkratku uvést vykřičník. Při nastavení se můžete inspirovat doporučením odporníků ze SSLlabs, kteří za vhodné považují toto nastavení:

SSLCipherSuite "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+
aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:
!3DES:!MD5:!EXP:!PSK:!SRP:!DSS"

Pokud nemáte vlastní preference, můžete si tuto direktivu zkopírovat do svého nastavení.

Zakažte použití RC4

Jedním z kroků k vyšší bezpečnosti je omezení použití RC4 šifer, které jsou spojeny s útokem BEAST. Nastavení SSLCipherSuite direktivy uvedené výše zakazuje RC4; pokud používáte svou direktivu, stačí vložit před RC4 vykřičník a tím ji zakázat.

Toto má však svou daň - po zákazu RC4 se na server nedostanou uživatelé IE na Windows XP (jiných prohlížečů se to netýká). Z pohledu kompatibility by to však už neměl být problém, protože Windows XP už nejsou podporovaným systémem.

Přegenerujte certifikát s SHA-2 v podpisu

O konci podpory SHA-1 jsme v našem magazínu informovali už několikrát, naposledy v souvislosti s koncem podpory v Chrome a nepříjemným varováním prohlížeče. Více informací najdete v článku Google Chrome a SHA-1 certifikáty - konec podpory. Microsoft nebude SHA-1 certifikáty podporovat od 1.1.2016.

Upgrade SHA-1 certifikátů na SHA-2 je tedy nevyhnutelný. Uživatelé SSLmarketu mají možnost svůj certifikát zdarma a automaticky přegenerovat (reissue, znovuvydání) s SHA-2. Reissue je možné provést v zákaznické administraci v detailu certifikátu.

Po vydání certifikátu s novým podpisem SHA-2 je nutné použít i nový Intermediate certifikát, který vám SSLmarket zašle s certifikátem. Kořenové certifikáty autorit zatím zůstávají u SHA-1 a nemění se, protože jejich podpis se neověřuje. Ani prohlížeče nebudou upozorňovat na kořenové certifikáty s SHA-1.

Nasaďte (Perfect) Forward Secrecy

Forward Secrecy je metoda výměny klíčů, která zabraňuje zpětnému dešifrování jednou zašifrované komunikace, a to i při znalosti privátního klíče (například při dešifrování odposlechu). Předpokladem Forward Secrecy jsou dvě metody výměny klíčů DHE a ECDHE; RSA Forward Secrecy nepodporuje. Více se o Forward Secrecy dozvíte v článku Perfect Forward Secrecy - zamezte odposlechu svého serveru.

Na serveru je tedy nutné nastavit vysokou prioritu DHE a ECDHE metodám výměny klíčů a upřednostnit je před RSA (nebo ji zakázat). Návštěvníci potom budou moci profitovat z podpory Forward Secrecy na vašem serveru. Pokud použijete direktivu SSLCipherSuite z tohoto článku, bude váš server Forward Secrecy podporovat.

Ověření nového nastavení

Po každé úpravě nastavení serveru musí nastat otestování, které ukáže, zdali byly změny provedeny správně, a zdali server pracuje v pořádku.

Test nastavení HTTPS

Pro test SSL/TLS na vašem serveru doporučuji zřejmě nejpokročilejší nástroj, kterým je SSL Server Test od Qualys. Ten kromě podrobné analýzy hodnotí i míru bezpečnosti nastavení serveru, kterou shrne do známky. Stejně jako na univerzitě dostanou A ty nejlépe nastavené servery, F je naopak známka nedostačujícího zabezpečení.

Při dodržení výše uvedených rad bude váš Apache server ohodnocen známkou A. Potom si můžete být jisti, že jste pro bezpečnost návštěvníků udělali dostatek.

Test kompatibility HTTPS

Kompatibilita je problém, který se u nastavení SSL pravidelně řeší. Zmíněný ověřovač pomůže řešit i tento problém, protože simuluje handshake všemožných kombinací prohlížečů. Pokud je handshake úspěšný, je domluvená šifra zobrazena; pokud by nebylo možné navázat spojení, uvidíte chybu Fail: Protocol or cipher suite mismatch.

Testují se kombinace Androidu 2.3.7. a verzí 4.x.x., Internet Explorer na XP a novějších Windows, různé prohlížeče, Java, OpenSSL a vyhledávací boty. Máte tedy přehled o tom, kteří návštěvníci se zvládnou připojit; pokud by bylo nastavení příliš agresivní (například pouze TLS 1.2), můžete ho snížit a dosáhnout lepší kompatibility.

Zdroje:

Více informací k tomuto tématu najdou případní zájemci v použitých článcích.

1. RC4 in TLS is Broken: Now What?
2. Configuring Apache, Nginx, and OpenSSL for Forward Secrecy