Protokol DANE na CentOS 7 pro vyšší bezpečnost https

28.10.2014

Stejně jako v předchozích článcích zde vycházím z (ne)spolehlivosti a (ne)bezpečnosti holé infrastruktury X.509 certifikátů používaných protokolem SSL/TLS, která je zapříčiněna nedůvěryhodností certifikačních autorit, které původně měly spolehlivost a bezpečnost zajišťovat (viz problémy posledních let, viz kvanta certifikátů kořenových CA, které jsou inkorporované do úložišť nejen browserů).

Běžný koncový uživatel má minimální kontrolu nad tím, zda jeho komunikace, jejíž ochrana šifrováním je založená právě na X.509 certifikátech s výše uvedenými “výhodami”, je opravdu bezpečná nebo zda někde po cestě neprobíhá Man In The Middle útok.

Naopak každý běžný uživatel musí důvěřovat službě DNS, aby vůbec mohl jakoukoliv službu na Internetu používat. Z toho vychází protokol DANE (DNS-based Authentication of Named Entities), přičemž je patrné, že bez bezpečného DNS tento protokol postrádá smysl (ano, narážím na DNSSEC).

Motivem existence tohoto protokolu je myšlenka, že vlastník a provozovatel domény a služeb, které jsou provozovány na serverech domény, je jediná osoba, která ví a může určit, jakými prostředky je komunikace chráněna, tedy jaké certifikáty jsou pro danou službu korektní a důvěryhodné. Jak to dá uživateli vědět?

Majitel domény může použít DNS záznamů, pomocí kterých může software koncového uživatele, který má DANE implementován, zkontrolovat, zda certifikát, který používá pro zabezpečení komunikace konkrétní služby, je správný. Tento protokol není tedy omezen na zabezpečení webových služeb, ale je obecný. Záleží jen na schopnosti softwaru, který používá některou ze síťových služeb, zda je schopen pomocí DANE ověřovat důvěryhodnost certifikátů (dalším sw, který má podporu DANE je například Postfix).

Tento článek bude velmi krátký. Nejprve si popíšeme infratrukturu DANE a potom nástroje, které nám pomohou při ověřování správnosti certifikátů webové služby (na další služby se podíváme jindy).

Základním kamenem DANE je TLSA, což je nově zavedený typ DNS RR, který má následující strukturu:

  • doménové jméno (například: _443._tcp.ahimsa.lamed.cz.) tvořené:
    • protokolem/portem sedmé vrstvy uvozeným podtržítkem (např.: _443 pro https)
    • IP protokolem uvozeným podtržítkem (např.: tcp)
    • hostname/doménou (pro náš server je to FQDN serveru ahimsa.lamed.cz)
  • RDATA, která obsahují:
    • parametr CertificateUsage, který nabývá hodnoty od 0 do 3, přičemž hodnoty mají následující význam:
    • 0: hash je tvořen z certifikátu CA, klient musí validovat celý chain a v něm musí být certifikát CA, jehož hash je v TLSA záznamu
    • 1: hash je tvořen z certifikátu serveru, klient musí validovat celý chain a poslední certifikát musí být certifikát serveru, jehož hash je v TLSA záznamu
    • 2: hash je tvořen z libovolného certifikátu CA, který je tímto klientem nově považován za kořenový, klient musí validovat chain s tímto novým kořenem
    • 3: hash je tvořen z certifikátu serveru a musí odpovídat hashi v TLSA záznamu
  • parametr Selector, který nabývá hodnoty 0 nebo 1, které říkají:
    • 0: hash je generován z celého certifikátu
    • 1: hash je generován pouze z veřejného klíče.
  • parametr Matching type, který říká, jak vznikl hash:
    • 0: místo hashe je použit celý certifikát
    • 1: hash je tvořen algoritmem SHA256
    • 2: hash je tvořen algoritmem SHA512
  • vlastní hash (správně pojmenováno je Certificate Association Data)

Při ověřování klient tedy sestaví DNS request podle služby (protokolu) a jména serveru a chová se podle toho, co dostane jako odpověď. V obecném případě musí mít klient podporu DANE, v případě HTTPS si ukážeme, jak můžeme dosáhnout ověření, i když např. browser nativně takovou podporu nemá.

Pro vytvoření vlastního záznamu musíme mít některý z mnoha nástrojů, kterých je poměrně dost (swede, webové tooly, nebo hash-slinger).

Použil jsem program tlsa z balíku hash-slinger, který lze v CentOSu nainstalovat z repozitáře EPEL. Protože však neexistoval v repozitářách pro CentOS 7, stáhl jsem si jej z repozitáře pro verzi 6:

wget http://ftp.fi.muni.cz/pub/linux/fedora/epel/6Server/x86_64/hash-slinger-2.5-1.el6.noarch.rpm
yum install hash-slinger-2.5-1.el6.noarch.rpm

Vlastní TLSA záznam byl vygenerován příkazem :

tlsa --create --usage 0 --ca-cert /etc/pki/tls/certs  ahimsa.lamed.cz

ze kterého je patrné, že jsem použil CertificateUsage 0, a proto jsem musel zadat i cestu k úložisti certifikátu CA, respektive chainu certifikátů. Program si sám najde správný a zeptá se, zda jej má použít. Defaultně je hash generován z celého certifikátu algoritmem SHA256, a proto je výsledek následující:

_443._tcp.ahimsa.lamed.cz. IN TLSA 0 0 1 bc3f03a436240edba5f83714f6f677e34b37f9b1f0c08c1e558d981e279e8209

Tento řádek je možné vložit do zónového souboru naší domény, zvýšit sériové číslo v SOA záznamu a provést příkaz:

rndc reload

který v našem nasazení způsobí znovupodepsání a nové načtení zóny.

Kontrolu provedeme nejprve na straně DNS serveru:

dig +dnssec @ahimsa.lamed.cz TLSA _443._tcp.ahimsa.lamed.cz

a měli bychom dostat podobný výstup (vypsaná je pouze podstatná část), který obsahuje TLSA RR a jeho podpis:

;; ANSWER SECTION:
_443._tcp.ahimsa.lamed.cz. 3600    IN    TLSA    0 0 1 BC3F03A436240EDBA5F83714F6F677E34B37F9B1F0C08C1E558D981E 279E8209
_443._tcp.ahimsa.lamed.cz. 3600    IN    RRSIG    TLSA 8 5 3600 20141127030954 20141028020954 32340 lamed.cz. P1fpB7E/7g5+5WmZ+z8RZG9NXwdIHJr2v0POfct27mxAsrcKxYzUJjxc gxkZR/en53AwED29vt100fOrFf1jqU9XPBRiNm1KmnwOz2Lxix41cOeE lSLS277COdbRakcOHEpQ6BARL/eFHZCXhc0uSwcFSAL3/9b4PBc2Xm0J AEZmTeqrqPtBC0KW+tQxHTsDpIV4jrqUVgdQyJPBc9JiNFHm48yKHZV9 hGwtUaViuMQmgmfRA8Bi3ZQ/9r4eTYiBGOE1PZTzhNJvu5klmfe7AeG0 Q2N5ZMcO+IfsYrXgnUiGqjnTvz5GPjvadsRZME9NbcnIvOm2wXkxP8Zh l6N0JQ==

Můžeme si také ověřit dostupnost záznamu z jiného počítače:

host -t TLSA _443._tcp.ahimsa.lamed.cz

a výstup bude:

_443._tcp.ahimsa.lamed.cz has TLSA record 0 0 1 BC3F03A436240EDBA5F83714F6F677E34B37F9B1F0C08C1E558D981E 279E8209

Tím máme hotovo.

Webové browsery většinou neoplývají podporou tohoto protokolu, a proto CZ.NIC napsal příjemný plugin pro Internet Explorer, Mozilu Firefox, Chrome/Chromium, Operu a Safari s názvem DNSSEC/TLSA Validator, který je možné stáhnout na URL: https://www.dnssec-validator.cz/.

Tento nástroj ověřuje jak DNSSEC, tak i DANE/TLSA. V případě správného nastavení tohoto pluginu uvidíme v browseru dva symboly u URI řádky, z nichž jeden vypovídá o stavu DNSSEC a druhy o DANE/TLSA. V našem případě jsou oba symboly zelené a po rozklinutí dostaneme více informací.

Nemusíme se však spoléhat pouze na tento sw, ale můžeme si nainstalovat i balík gnutls-utils spolu s balíky gnutls-dane a gnutls pomocí instalátoru yum.

Použití gnu-utils pro validaci:

gnutls-cli --dane ahimsa.lamed.cz

Výstup je poměrně bohatý, takže pouze zkontrolujeme, že se vyskytují řádky:

- Status: The certificate is trusted.
- DANE: Certificate matches.

Na serveru root.cz vyšly pěkné články, které se problematikou zabývají a které mohou být pro zájemce zajímavé:

Obecnější: http://www.root.cz/clanky/protokoly-chranici-proti-neduslednym-a-nebezpecnym-ca/

a přímo k DANE: http://www.root.cz/clanky/protokol-dane-aneb-z-kroceni-zlych-certifikacnich-autorit/.

  • obsah/bezpecnost/centos_dane_https.txt
  • Last modified: 2018/10/17 22:01
  • by profors