GnuTLS nyní s podporou DANE (a striktnější než OpenSSL)

20.1.2013 16:43 | Přečteno: 1405× | programování | | poslední úprava: 20.1.2013 16:48

OpenSSL utilita s_client je taková stálice na command-line testování SSL/TLS služeb, ale s poslední verzí GnuTLS 3.1.6 uvažuji, že gnutls-cli budu používat přednostně. Proti openssl má podporu IPv6 a nedávno dostalo alpha podporu DANE protokolu. Pořád to není ekvivalent Qualys SSL Labs testu (který je ale IPv4 only), ale s trochou skriptění by to šlo implementovat. Na konci si trocha zanadáváme na Opera TLS Prober.

Konfigurace GnuTLS pro podporu DANE, ECC, ...

První drobný zádrhel je, že GnuTLS configure skript se snaží příliš věcí uhodnout. Je lepší vypnout zpětnou kompatibilitu s OpenSSL, explicitně specifikovat DNS root trust anchor soubor a CA bundle. CA bundle lze změnit později command-line parametrem --x509cafile, ale DNS root anchor se zatím jen kdesi zadrátuje do binárky libgnutls-dane.so.

Správný DNS root trust anchor soubor se pozná podle toho, že obsahuje DNS RR záznam - buďto DNSKEY nebo DS pro root zónu ".", např.:

.       98799   IN      DNSKEY  257 3 8 AwEAAagAIKlVZrpC6 [...] ;; vypis zkracen

Lze ho například získat utilitou unbound-anchor a v závislosti od distribuce bude typicky součástí balíčku unbound nebo si ho v postinstall skriptu stáhne a uloží do /etc/unbound/.

Prerekvizity GnuTLS jsou libunbound, libnettle >= 2.5, která vyžaduje libgmp. Prefix pro libnettle je v configure jen kvůli tomu, že distribuční libnettle v SL6 byla příliš stará, tak jsem musel zbuildit verzi zo zdrojáků a nainstalovat do $HOME/local/libnettle-2.6/.

#v ramci testu to staci takhle prasacky s RPATH
export LDFLAGS="-Wl,-rpath=$HOME/local/libnettle-2.6/lib64"
./configure --prefix=$HOME/local/gnutls-3.1.6 \
    --enable-libdane \
    --with-libnettle-prefix=$HOME/local/libnettle-2.6 \
    --disable-openssl-compatibility \
    --with-unbound-root-key-file=/etc/unbound/root.anchor \
    --with-default-trust-store-file=/etc/ssl/certs/ca-bundle.crt
make && make install #klasicke dokonceni svate trojice

#predpokladam, ze gnutls-cli je v PATH, at porad nemusim pastovat cestu
export PATH="$HOME/local/gnutls-3.1.6:$PATH"

Po instalaci by gnutls-cli --list na konci výpisu podporovaných algoritmů mělo obsahovat věci jako šifru AES v GCM módu pro různé velikosti klíčů, ECDHE-RSA, ECDHE-ECDSA key-exchange algoritmy a protokol TLS až do verze TLS1.2.

Pojďme oprudit nějaké servery

Vyzkoušíme rovnou všechny nej-über-cool featury, jako TLS-1.2, ECDHE keyexchange, AES v módu GCM, OCSP check a pak test IPv6, můžeme porovnávat s výsledky Qualys SSL Labs testu:

#blbnuti s prioritami
gnutls-cli -d 0 --priority 'NORMAL:+ECDHE-RSA:+SIGN-RSA-SHA384:+AES-256-GCM:!SHA256:+VERS-TLS1.2:!SIGN-RSA-SHA256:!AES-128-CBC:!ARCFOUR-128:!AES-256-CBC' --ocsp www.google.com  < /dev/null
#test IPv6
gnutls-cli -d 0 --priority 'SECURE256:%SAFE_RENEGOTIATION:+VERS-TLS1.2' ipv6.google.com  < /dev/null
#explicitni vyber protokolu a algoritmu
gnutls-cli -d 0 --priority 'NONE:+CTYPE-X.509:+VERS-TLS1.2:+COMP-NULL:+ECDHE-RSA:+CURVE-SECP256R1:+AES-256-GCM:+AEAD' --ocsp www.google.com  < /dev/null
gnutls-cli -d 0 --priority 'NONE:+CTYPE-X.509:+VERS-TLS1.2:+COMP-NULL:+ECDHE-RSA:+CURVE-SECP256R1:+AES-256-CBC:+SHA1' --ocsp www.google.com  < /dev/null

Z parametrů výše je -d debug level, --priority vybírá nebo zakazuje algoritmy a/nebo protokoly. Pluskem se zapíná podpora algoritmu, výkričníkem zakazuje. Speciální makra NORMAL, SECURE256 a NONE obsahují některé předdefinované sady ciphersuites, %SAFE_RENEGOTIATION odmítne připojení k serverům náchylným na bug v TLS renegotiation. Viz dokumentace k priority strings.

Poslední dva řádky s makrem NONE v prioritách je ukázka jak navolit specificky jenom jeden protokol a jednu sadu ciphersuites, gnutls v Client Hello odešle jen TLS_ECDHE_RSA_AES_256_GCM_SHA384 (0xc030), resp. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) v položce Ciphersuites. Trefit správný syntax parametrů je trocha magie a hlavně dost bruteforce. Třeba zápis AEAD u AES-GCM mi chvíli unikal, protože v názvu ciphersuite je napsaný jinak, ale v manuálu to mají popsáno.

Jakou preferenci značí jednotlivá makra nebo nějaký specifický priority string, lze zjistit přes gnutls-cli --priority "SECURE256" --list (za "SECURE256" dosaďte priority string). Takhle jsem zjistil, že ciphersuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 z nějakého důvodu u mně přítomna není. Ani v dokumenaci výše není uvedeno SHA384, i když parametr +SHA384 je brán jako syntakticky správný. Sranda je, že gnutls-cli se v "simple client módu" stejně k serveru připojí, ale nezačne ani handshake, pošle serveru jenom "Alert, level: fatal - handshake failure" a ukončí spojení. Netuším jestli to má nějaký praktický význam, jedině snad, že by chtěl klient serveru říct "došli mi všechny šifry" nebo tak něco.

DANE

GnuTLS je myslím první větší TLS knihovna s podporou DANE protokolu schopná zpracovat DNS TLSA záznamy. Podle námatkových testů to funguje celkem dobře. Zatím nejsou podporovány domény, kde je DNSSEC podpis proveden klíčem z DLV (místo aby se řetězil od podpisu kořenové zóny). Několik příkladů:

#dva pripady kdy retezec certifikatu je validovan uz z trusted CA bundle store
gnutls-cli --dane www.torproject.org  < /dev/null
gnutls-cli --dane wiki.opendnssec.org  < /dev/null
#dva pripady "nezname vydavatelske CA", ale maji v TLSA certificate usage 3
gnutls-cli --no-ca-verification --dane www.nlnetlabs.nl < /dev/null
gnutls-cli --no-ca-verification --dane dane.rd.nic.fr < /dev/null
#pripad schvalne rozbiteho TLSA zaznamu
gnutls-cli --no-ca-verification --dane dane-broken.rd.nic.fr < /dev/null
#fedoraproject.org ma DLV DNSSEC podpisy, tak neprojde; stejne ma rozbity TLSA zaznam
gnutls-cli --dane fedoraproject.org < /dev/null
#IPv6-only, HTTPS-only, "neznama CA", TLSA certificate usage 3
gnutls-cli --no-ca-verification --dane www.ecca.wtmnd.nl < /dev/null

Když DANE test uspěje, bude výpis obsahovat nenápadnou hlášku "Certificate matches."; pokud ne, bude tam místo toho "Verification failed. The certificate differs.". Nebylo by odvěci do těch hlášek přidat string "DANE", trocha špatně se to v tom výpisu hledá.

V příkladech výše se musí uvést option --no-ca-verification u strojů, které nejde validovat z trusted CA bundle, jinak se gnutls-cli abortne ještě před DANE validací. Zřejmě override z TLSA certificate usage 2 a 3 není implementován. Taky asi nesprávně vrací exit code 0 místo chybového 1 pokud selže DANE test při vypnutém certchain testu, protože jinak nevidím rozdíl mezi --insecure a --no-ca-verification.

Web z posledního příkladu - https://www.ecca.wtmnd.nl - je zvláštní hlavně tím, že "normální člověk" se k němu téměř nemá šanci dostat. To je ta část IPv6-only, HTTPS-only. Dále je to snad jediná doména s TLSA záznamem, který má zároveň selector 0 i matching type 0. To znamená, že v DNS TLSA záznamu je uložen celý certifikát a ne jenom hash (viz dig +dnssec -t type52 _443._tcp.www.ecca.wtmnd.nl). Nefungují na něj ani Perspectives notáři, protože ti taky neumí IPv6.

TOFU

V dokumentaci jsem narazil na option --tofu, který zapíná TOFU přístup. To jsem moc nevysvětlil, co? TOFU = "Trust on First Use" je přístup v "SSH-stylu". Klient se při prvním připojení zeptá uživatele, jestli je fingerprint OK a pak si ho uloží. Nebude otravovat, dokud se nezmění. Ukládá se to do souboru ~/.gnutls/known_hosts.

GnuTLS vs OpenSSL - striktnost, featury cmdline

Vypadá, že gnutls-cli si zapíná Server Name Indication automaticky. Nejde třeba vybrat explicitně IP adresu (pokud se FQDN mapuje na vícero A/AAAA záznamů). U openssl s_client je na to oddělené nastavení -connect a -servername.

Dále v gnutls-cli nejde zvolit jak se má chovat v případě přijmutí "rozházeného" non-RFC certchainu. V C API na to option je, ale ten command-line klient ho nemá. V starším gnutls 2.8.5 bylo zapnuté striktní vyžadování správného pořadí certifikátu v certchain, v 3.1.6 je to vypnuto (viz GNUTLS_E_CERTIFICATE_LIST_UNSORTED). Ono se hodí obě chování, striknost je lepší kupříkladu na testování nastavení serverů. Serverů, které "od boku střílí" chain 13 i vícero certifikátů je pořád hodně. OpenSSL ale vždy "tajně" seznam přeuspořádá a AFAIK jí to nejde vymluvit.

Podobně je GnuTLS pořád citlivá na různé violace TLS protokolu, které OpenSSL tiše přehlíží. Příklad - server uzavře spojení s TCP RST bez odeslání close_notify - bez close_notify nemá klient šanci rozeznat, zda je to legitimní ukončení nebo MitM (náhodný server exhibitující tohle chování - www.zotero.org).

Opera TLS Prober

Nedávno uvolněný Opera TLS Prober vypadal, že by mohl být tím správním nástrojem. Má jenom tři vady: dokumentace je extrémně zavádějící, kód je rozbitý víc než šlapací hajzl v Rychlíku sjednocení a ta třetí vada vyplývá z první dvou: je to absolutně nepoužitelné. Strávil jsem ad-hoc opravovaním a workaroundovaním chyb několik hodin, než jsem to vzdal. Pohleďme:

• v probedb/certs/models.py se musí přidat related_name v definici DB sloupců, jinak python manage.py syncdb zahučí
• weekly/setup_node.sh zařve, protože má natvrdo zadrátované cesty a jména branchů v gitu (zato přidá do crontabu vyvolání, které pak failují)
• special_run.py nemá žádný option --source, který by měl podle README mít
• queue_setup.py očekává jiný formát CSV než je v README (jen hostname nestačí)
• README je plné překlepů a vůbec některé věty ani nejsou dokončeny

Nejpoužitelnější část by TLS Proberu byla tlscommon, který implementuje samotný scan, ale opravit a extrahovat ji taky nebude triviální. Musím říct, že ad-hoc definici prázdné třídy uprostřed kódu metody a pak ad-hoc přidávání atributů jsem ještě v pythonu neviděl (a to má být exponované API, ne nějaký dočasný hack).

       

Komentáře

[Bedňa]

Rád by som vedel aká je bezpečnosť, keď narazím na link a musím potvrdiť certifikát, pretože na danej stránke má byť odpoveď na otázku čo hľadám a pritom neviem či si niekto len zo mňa nespravil žart a čaká ma tam nemilé prekvapenie. Celý ten humbug okolo cerifikátov mi pripadá ako voliť Fica, ja vám chcem predsa dobre, voľte ma.

[Bedňa]

Teda skoro vždy keď narazím na https: mám pocit, že niekto so mnou chce vyjebat.

[limit_false]

Asi se nechytám. Šlo by to rozvést? Nebo nějaký příklad?

[Bedňa]

Príklad https://www.abclinuxu.cz/ v čom je bezpečnejšie ako http://www.abclinuxu.cz/ ? V odklikaní certifíkatu? To čo väčšina ľudí ani nečíta? Nechcem robiť HATE POST, len mi to príde ako zbytočné, teda ja si čítam certifikáty, ale poznám väčšinu ľudí čo to odkliká a nevidím v tom žiadnu bezpečnosť. Teda ani nevidím rozdiel medzi tým slobodne brúzdať cez tor a prípadne dôverovať autoritám o ktorých neviem nič, prípadne viem ako sklamali.

Tento prístup sa mi zdá zlý od podstaty.

[Jendа]

Príklad https://www.abclinuxu.cz/ v čom je bezpečnejšie ako http://www.abclinuxu.cz/ ? V odklikaní certifíkatu?

Já mám CA, kterou je to podepsané, mezi důvěryhodnými, ale chápu, že jiní to tak mít nemusí. Nicméně:

• Pokud na tebe někdo MITM útok nebude dělat všude a neustále, dozvíš se to (za předpokladu, že tvůj prohlížeč umí sledovat změnu certifikátu).
• Můžeš si identitu protistrany ověřit i nějak jinak (SSL notaries).
• Nestačí pasivní odposlech, je potřeba MITM útok. Třeba na jedné populární bezdrátové síti (pššt :) je sniffing jednoduchý, ale MITM je technicky velmi obtížný.

[Bedňa]

Len mi tam stále vŕta ta dôvera autorite. Nehovorím že je to vyslovene zlý prístup. Skôr spolieham na blacklisty, teda stále je to o dôvere.

[Jendа]

Len mi tam stále vŕta ta dôvera autorite.

Taky to moc nefunguje…

Skôr spolieham na blacklisty, teda stále je to o dôvere.

Blacklisty čeho?

[limit_false]

S důvěrou v CA to není ideální, ale za tím je mnohem víc politiky než cokoliv technického (to je na velmi dlouho, ale ešte ještě o tom bude řeč v budoucnu). Třeba seznam vládních CA v Microsoftím Root programu je napováženou, a mnohé z nich jsou i v jiných trusted CA storech (Mozillím, Googlím...).

Jak psal Jenda, projekt Perspectives je velmi účinný a k tomu dost jednoduchý (používam taky dlouho, tam bývá občas problém vytíženost defaultních Perspectives notářů). Dále má pomoci v blogpostu zmíněné DANE a navrhované Certificate Transparency.

Ale platí jednoduchá věc: HTTPS z principu nemůže být méně bezpečné než HTTP, i kdyby člověk odklikal pryč všechny warningy. HTTPS a TLS obecně je účinné proti pasivnímu odposlechu (a různých krabiček na to je po netu dost), aktivní MitM nastává velmi zřídka (pokud nepočítám captive portals na hotelech).

[CH]

"HTTPS z principu nemůže být méně bezpečné než HTTP"

To ano, ale muze davat falesny pocit bezpeci. Stejne jako neoverovani fingerprintu pri pripojovani klienta k SSH serveru.

[pavlix]

Ale platí jednoduchá věc: HTTPS z principu nemůže být méně bezpečné než HTTP

Bohužel neplatí. To S na konci té zkraty (zvláště pak v URL) často způsobuje změnu chování uživatele na základě pocitu bezpečí. Většina uživatelů pracuje navíc s bezpečností jako s binární hodnotou, tudíž to S pro ně znamená bezpečné.

aktivní MitM nastává velmi zřídka (pokud nepočítám captive portals na hotelech).

Aktivní mitm se často používá ve větších sítí jako standardní nástroj pro zabezpečení a dohled nad aktivitou zaměstnanců.

pokud nepočítám captive portals na hotelech

Nepočítat toto už je samo o sobě zásadní chybou. I když aktivní útok lze provést na většině sítí bez administrátorského přístupu k infrastruktuře, takže to vůbec není omezeno na hotely.

[Jendа]

Většina uživatelů pracuje navíc s bezpečností jako s binární hodnotou, tudíž to S pro ně znamená bezpečné.

Jde to nějak jinak? Konečné rozhodnutí je snad vždy binární (buď tam to heslo nezadám nebo zadám).

[pavlix]

Jde to nějak jinak?

U téhle otázky mám pocit, že zrovna ty si ze mě děláš srandu.

Konečné rozhodnutí je snad vždy binární

Jenže nebyla řeč o konečném rozhodnutí, ale o posouzení daného zabezpečení.

[limit_false]

Závisí Pokud je to například jenom stránka typu forum nebo archiv mailinglistu, tak je to většinou celkem jedno (ale je lepší dát jenom dočasnou výjimku než trvalou). Kdyby tam bylo požadováno zadání něčeho důležitého (hesla, nebo jiného textu, který má být tajný), tak bych si to rozmyslel.

"Nemilé prekvapenie" - je tým myšlen nějaký malware? Protože HTTPS a certifikáty s malwarem mají společné minimum. Na hacknutém serveru si může útočník přidat do HTML stránky cokoliv, nezávisle jestli putuje později ke klientovi via HTTP nebo HTTPS. Pokud ale přidá HTTP link na skript, tak některé browsery můžou odmítnout ten skript stáhnout z důvodu "mixed scripting". Chrome se myslím tohle snaží prosadit (což by bylo jedině dobře). Problém je v tom, že je mnoho legitimních webů s mixed-content, které by přestali fungovat.

[petr_p]

Existuje taková poučka, je bezpečnost je proces. Takže vaše návodná otázka je mimo. Ale teď už vážně.

Pokud se chcete podívat na webovou stránku a nic víc, tak samozřejmě nějaký certifikát je naprosto zbytečná věc. Při otázce na dostatečnost úrovně zabezpečení je totiž první krok stanovení, proti čemu se chceme bránit. Ve vašem případě se bránit nepotřebujeme, takže ve vašem případě je zabezpečení dostatečné.

[Jendа]

Pokud se chcete podívat na webovou stránku a nic víc, tak samozřejmě nějaký certifikát je naprosto zbytečná věc.

No, pokud se chce podívat na nějakou konkrétní stránku, tak se zabezpečení taky může hodit. Třeba když se chce podívat na seriózní deník Infobaden a nějaký vtipálek mu tam podvrhne obsah z recesistického idnes.cz.

[Bedňa]

Firemná paranoická politika ma naučila pred kliknutím sa pozrieť, kde idem.

[Jendа]

No právě. A proto bys určitě nerad, aby se ti po kliknutí na nezávislé seriózní zpravodajství vyskočil nějaký odpadek z idnes. Jenže co když ti ho někdo podvrhne?

[Bedňa]

Mám pocit, že keď kliknem na odkaz s webom o informáciach, keď niečo hľadám a je tam nutnosť potvdiť certifikát, vždy vo mne hlodá myšlienka prečo?

[Bedňa]

Dík za potvrdenie môjho názoru na https pre bežné weby.

[limit_false]

Nechtěl jsem tam psát standardní otázku, která zaručeně všechny otráví: "And what is your threat model?"

Víc mě trápí existence nespočet eshopů, kde jde všechno přes obyčejné HTTP, až na konci se to přesměruje na nějakou platební bránu, kde ani není napsáno, komu vlastně člověk platí. Týká se to i nejmenovaného eshopu, kde se kupují kupony na prolomené RFID karty.

[rADOn]

Ad-hoc definice tridy kdekoliv je v pythonu zcela legalni zpusob jak delat fabricke metody a podobne vylomeniny. Atributy do trid ani jinak nez ad-hoc pridavat nejde