Přeskočit na hlavní obsah

Zabezpečení transportní vrstvy

  • Pří správné implementaci poskytuje TLS tyto výhody
    • Ochrana před útočníkem, který by mohl číst přenášená data
    • Ochrana proti útočníkovi, který přenášená data modifikuje nebo opakuje požadavky na server
    • Umožňuje ověřit, zda je klient připojen ke správnému serveru
  • TLS je využíván dalšími protokoly k zajištění šifrování a integrity

SSL vs TLS​

  • SSL (Secure Socket Layer) byl původním protokolem pro šifrování HTTP přenosů
  • Existovaly SSL verze 2 a 3, ale obě mají závažné kryptografické nedostatky a neměly by se používat
  • Z různých důvodů byla další verze tohoto protokolu (SSL 3.1) pojmenována TLS (Transport Layer Security) verze 1
  • Následně byly vydány verze TLS 1.1, 1.2 a 1.3
  • Pojmy SSL, SSL/TLS a TLS se často zaměňují a v mnoha případech se při odkazování na modernější TLS používá právě SSL

Konfigurace serveru​

Podporujte pouze silné protokoly​

  • Protokoly SSL mají mnoho slabých míst a neměly by se v žádném případě používat
  • Webové aplikace by měly ve výchozím nastavení používat TLS 1.3 (v případě potřeby 1.2) a všechny ostatní protokoly by měly být vypnuty
  • V případě, že server musí podporovat starší klienty s prohlížeči jako Internet Explorer 10, může být pro zajištění podpory povolen TLS 1.0
  • Tam, kde jsou vyžadovány starší protokoly, by mělo být povoleno rozšíření TLS_FALLBACK_SCSV
  • PCI DSS však zakazuje používání starších protokolů, jako je TLS 1.0

Podporujte pouze silné šifry​

  • TLS podporuje velké množství šifer, které poskytují různou úroveň zabezpečení
  • Pokud je to možné, měly by být povoleny pouze GCM šifry
  • Pokud je nutné podporovat starší klienty, mohou být vyžadovány jiné šifry
  1. Zakažte následující šifry
    • Null šifry
    • Anonymní šifry
    • EXPORT šifry

Použijte silné Diffie-Hellman parametry​

  • Pokud se používají šifry, které používají Diffie-Hellmanovu výměnu klíčů (DHE nebo EDH v názvu šifry), měly by se používat dostatečně bezpečné parametry (alespoň 2048 bitů)
  • Pro vygenerování 2048 bitových parametrů lze požít následující příkaz
openssl dhparam 2048 -out dhparam2048.pem
  • Weak DH poskytují návod, jak lze servery nakonfigurovat tak, aby používaly tyto parametry

Zakažte kompresi​

  • Vypněte TLS kompresi z důvodu ochrany před CRIME zranitelností
  • CRIME umožňuje získat citlivé informace (session cookie), které mohou být útočníkem obnoveny

Záplatujte kryptografické knihovny​

  • Kromě SSL a TLS zranitelností existuje velké množství zranitelností v SSL a TLS knihovnách
  • Nejznámější je Heartbleed
  1. Zajistěte, aby byly knihovny aktualizovány a up-to-date

Otestujte konfiguraci serveru​

Certifikáty​

Používejte a zabezpečte silné klíče​

  • Privátní klíč použitý k vygenerování šifrovacího klíče musí být dostatečně silný pro předpokládanou dobu životnosti privátního klíče a příslušného certifikátu
  • Doporučuje se zvolit klíč o velikosti alespoň 2048 bitů
  • Privátní klíč by měl být chráněn před neoprávněným přístupem pomocí filesystem oprávnění a dalších technických a administrativních mechanismů
  • Další informace o životnosti klíčů a jejich síle najdete v NIST SP 800-57

Použijte silné kryptografické hashovací algoritmy​

  • Certifikáty by měly používat hashovací algoritmus SHA-256
  • Nepoužívejte starší algoritmy jako jsou MD5 nebo SHA1
    • Mají řadu nedostatků a pro moderní prohlížeče nejsou důvěryhodné

Používejte správná doménová jména​

  • Doménové jméno (nebo subject) certifikátu se musí shodovat s názvem serveru, který certifikát předkládá
  • Historicky bylo jméno uloženo v commonName (CN) certifikátu
  • Chrome však atribut CN ignoruje a vyžaduje, aby FQDN (doménové jméno) bylo v subjectAlternativeName (SAN) atributu
  • Primární FQDN by mělo být v CN a celý seznam jmen v SAN
  1. Zvažte zahrnutí “www”
  2. Nezahrnujte nekvalifikované hostnames
  3. Nezahrnujte IP adresy
  4. Nezahrnujte názvy interních domén do certifikátů, které jsou vystavovány ven
  5. Nakonfigurujte server s více certifikáty, pokud je přístupný pomocí interních a externích FQDN

Pečlivě zvažte použití wildcard certifikátů​

  • Wildcard certifikáty porušují princip nejmenšího oprávnění (least privilege), protože jeden certifikát je platný pro všechny subdomény (např. *.example.org)
  • Pokud certifikát sdílí více systémů, zvyšuje se pravděpodobnost kompromitace privátního klíče, protože klíč může být přítomen ve více systémech
  • Výrazně se tedy zvyšuje “cena” klíče, čímž je pro útočníky atraktivním cílem
  1. Používejte wildcard certifikáty pouze v případech, kdy je to skutečně nutné, ne kvůli pohodlí
    1. Zvažte použití ACME, které umožní systémům automaticky žádat o vlastní certifikáty a aktualizovat je
  2. Nikdy nepoužívejte wildcard certifikáty pro systémy z různých úrovní důvěryhodnosti
    • Dvě VPN mohou používat sdílený wildcard certifikát
    • Více instancí webové aplikace může sdílet certifikát
    • VPN a veřejný web server by neměly sdílet wildcard certifikát
    • Veřejný web server a interní server by neměly sdílet wildcard certifikát
  3. Zvažte použití reverse proxy serveru, který provádí ukončení TLS, takže wildcard privátní klíč je přítomen pouze v jednom systému
  4. Veďte seznam všech systémů sdílejících certifikát, aby bylo možné je všechny aktualizovat v případě vypršení platnosti nebo jeho kompromitace
  5. Omezte rozsah wildcard certifikátu pro subdoménu (např. *.foo.example.org) nebo pro samostatnou doménu

Použijte vhodnou certifikační autoritu​

  • Aby uživatelé certifikátům důvěřovali, musí být podepsány důvěryhodnou certifikační autoritou
  • Měla by to být jedna z autorit, která je dobře známá a automaticky důvěryhodná pro operační systémy a prohlížeče
  • Autorita LetsEncrypt poskytuje bezplatné certifikáty s ověřením domény, kterým důvěřují všechny hlavní prohlížeče
  • Pro interní aplikace lze použít interní certifikační autoritu
  1. Zvažte, zda je zakoupení certifikátu od certifikační autority výhodné

Použijte CAA záznamy k omezení autorit, které mohou certifikáty vydávat​

  • CAA = Certification Authority Authorization
  • Lze je použít k určení autorit, které mohou vydávat certifikáty pro danou doménu
  • Záznamy obsahují seznam autorit a každá autorita, která není v tomto seznamu uvedena, by měla odmítnout vydat certifikát pro danou doménu
  • To může pomoci zabránit utočníkovi získat neoprávněné certifikáty pro doménu prostřednictvím méně důvěryhodné autority
  • Při použití na subdoménách je užitečná i z hlediska správy, protože omezuje autority, které mohou správci nebo vývojáři používat a brání jim v získání neoprávněných wildcard certifikátů

Vždy poskytněte všechny potřebné certifikáty​

  • Aby bylo možné ověřit pravost certifikátu, musí prohlížeč prozkoumat certifikát a porovnat jej se seznamem certifikačních autorit, kterým systém důvěřuje
  • V mnoha případech není certifikát podepsán přímo root autoritou, ale zprostředkovanou autoritou, která je podepsána root autoritou
  • Pokud uživatel tuto zprostředkovanou autoritu nezná, ověření certifikátu selže, i když uživatel důvěřuje root autoritě
  • Aby se tomu předešlo, měly by být všechny zprostředkující certifikáty poskytovány společně s root certifikátem

Zvažte použití EV certifikátů​

  • EV = Extended Validation
  • Tyto certifikáty poskytují vyšší úroveň ověření subjektu
  • Kontrolují, zda je žadatel legitimní právnickou osobou a neověřují pouze vlastnictví doménového jména jako běžné certifikáty
    • “Tento web je provozován společností Example s.r.o” vs “Tato doména je skutečně example.org”
  • Historicky se certifikáty v prohlížečích zobrazovaly odlišně
    • V adresním řádku se zobrazoval název společnosti nebo zelená ikona či pozadí
  • Od roku 2019 indikátory prohlížeče Chrome a Firefox nezobrazují, protože podle nich neposkytují žádnou dodatečnou ochranu
  • Používání EV certifikátů nemá žádné bezpečnostní nevýhody
  • Jsou však výrazně dražší než certifikáty pro ověření domény
  1. Posuďte, zda pro vás poskytují dodatečnou hodnotu

Aplikace​

Používejte TLS na všech stránkách​

  • Protokol by se měl používat na všech stránkách a ne jen na těch, které jsou považovány za citlivé (login page)
  • Stránky nevynucující TLS poskytují útočníkovi příleřitost k odposlechu a získání session tokenů nebo injektování škodlivého kódu do odpovědi a provedení dalších útoků na uživatele
  • Je vhodné nešifrované HTTP spojení na portu 80 okamžitě trvale přesměrovat (HTTP 301) na šifrované spojení
  1. Zabraňte přístupu přes HTTP za využití HSTS hlavičky (HTTP Strict Transport Security)

Nemixujte obsah s TLS a bez TLS​

  • Stránka dostupná přes TLS by neměla obsahovat soubory (Javascript, CSS), které se načítají přes nešifrovaný HTTP protokol
  • Nešifrované zdroje útočníkovi umožňují odposlech session cookies nebo do stránky vkládat škodlivý kód
  • Moderní prohlížeče blokují pokusy o načtení obsahu přes nešifrovaný HTTP protokol do zabezpečených stránek
  • Všechny cookies by měly být označeny atributem [Secure](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies)
  • Ten prohlížeči přikazuje, aby je odesílal pouze prostřednictvím šifrovaných HTTPS připojení
  • Je to důležité v případě, kdy webová stránka neposlouchá na HTTP portu 80, protože útočník může pomocí man-in-the-middle útoku podstrčit jiný web server na portu 80 a ukrást tak cookies

Necachujte citlivá data​

  • TLS sice poskytuje ochranu dat během jejich přenosu, ale neposkytuje žádnou ochranu dat poté, co dorazí do systému
  • Data mohou být uložena v mezipaměti prohlížeče nebo na proxy serverech, které jsou nakonfigurovány tak, aby prováděly TLS dešifrování
  1. Použijte HTTP hlavičky, které prohlížeči a proxy serverům říkají, aby tato data neukládaly do mezipaměti v případě, že posíláte citlivé údaje
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
  • Tím zabráníte jejich uložení a vrácení jiným uživatelům

Použijte HSTS​

  • HSTS = HTTP Transport Security
  • Dává prohlížeči pokyn, aby vždy požadoval HTTPS protokol a brání uživateli obejít varování před certifikátem
  • Další informace najdete v HSTS cheat sheetu

Zvažte použití client side certifikátů​

  • V typické konfiguraci se protokol TLS používá s certifikátem na serveru
  • Díky tomu klient ověří identitu serveru a zajistí šifrované spojení
  • Tento přístup má však dvě hlavní slabiny
    1. Server nemá mechanismus pro ověření identity klienta
    2. Připojení může zachytit útočník, který je schopen získat platný certifikát pro danou doménu
      • Toho nejčastěji využívají firmy k provádění kontroly TLS přenosů instalací CA certifikátu do klientských systémů
  • Klientské certifikáty řeší oba tyto problémy
  • Vyžadují, aby klient prokázal serveru svou identitu
  • Nejenže je zajištěno silné ověření identity klienta, ale také zabraňuje zprostředkující straně provést TLS dešifrování, i když má důvěryhodný certifikát CA autority
  • Klientské certifikáty se však používají zřídka kvůli řadě problémů
    • Vydávání a správa přináší značné náklady na administraci
    • Netechničtí uživatelé mohou mít problém s instalací certifikátů
    • TLS dešifrování používané mnoha organizacemi způsobí selhání ověřování certifikátů
  • Certifikáty by měly být zváženy u high-value aplikací nebo API
  • Zejména by měly být použity tam, kde je malý počet technicky zdatných uživatelů nebo kde jsou všichni uživatelé součástí stejné organizace

Zvažte použití public key pinningu​

  • Public key pinning lze použít k zajištění toho, že certifikát serveru je nejen platný a důvěryhodný, ale také se shoduje s očekávaným certifikátem pro daný server
  • Poskytuje ochranu proti útočníkovi, který je schopen získat platný certifikát buď zneužitím procesu ověřování, kompromitací důvěryhodné certifikační autority nebo získáním administrátorského přístupu ke klientovi
  • Public key pinning byl do prohlížečů přidán v HTTP Public Key Pinning (HPKP) standardu
  • Kvůli řadě problémů ho již moderní prohlížeče nepodporují ani nedoporučují
  • Stále však může být přínosný pro zabezpečení mobilních aplikací a server-to-server komunikaci
  • Podrobněji se tomu věnuje pinning cheat sheet

Kam dál​

Checklisty​