Názory k článku
Mozilla otestuje ve Firefoxu „DNS over HTTPS“
-
DANE bude, až bude mít svět plošně nasazený DNSSEC a až nebudou rozbité koncové sítě, ve kterých se dnes často klient nedostane k jiným informacím než k A záznamu. Tohle je naopak podle mě cesta, jak tu poslední míli vyřešit. Pokud se nedostanu k podpisům, přejdu na DNS over HTTPS a tam mi nikdo ty záznamy blokovat nebude.
-
A do té doby tam nebude fungovat HTTPS? Tohle si už dnes nemůžeme dovolit, podle mě je lepší jít právě nějakou cestou, která umožní uživateli se k těm podpisům v každém případě dostat. Mimochodem, třeba Google podobnou službu nabízí na dns.google.com.
Aby nedošlo k mýlce: já jsem zuřivým podporovatelem DNSSEC a DANE, ale zároveň vidím ty problémy, které za hurá nasazením stojí.
-
j (neregistrovaný)
To jiste, ono nejak https souvis s dns? Jo aha, vubec nijak ... copak asi tak soudruh browser udela, kdyz se mu nepovede overit revokaci certifikatu prave ted? Neudela vubec nic, v klidku a pohode si pokracuje dal. Co asi tak udela, kdyz mu DNS vrati uplne jinou IP? Zase vubec nic ... atd atd atd.
DANE by jeno umoznilo bezpecneji (nikoli bezpecne) komunikovat tem kteri by o to stali, a to se soudruhum v chrozille a guuglu nehodi do kramu, protoze prave oni by byli zcela ze hry.
-
HTTPS teď s DNS nijak přímo nesouvisí. Pokud bychom ale do DNS začali vkládat otisky certifikátů (DANE), tak to začne souviset velmi úzce. Takový otisk má smysl jen ve chvíli, kdy jsem ho dostal bezpečnou cestou – podepsaný pomocí DNSSEC. Pokud si ho přečtu někde napsaný nechráněně, pak mi ho kdokoliv může změnit a já se připojím s jeho klíčem. Nic by pak nebránilo komukoliv po cestě změnit ten záznam a unést mi HTTPS spojení. Některé vlády na to krabice mají. HTTPS bez autentizace nedává smysl.
-
By mě zajímalo, která cerifikační autorita (kterou má uživatel ve svém key storu) by vydala útočníkovi/vládě/atd. duplicitní certifikát např. pro www.facebook.com, aby mi útočník mohl podstrčit falešný certifikát a unést mi spojení a přitom abych si jako uživatel ničeho nevšimnul.
Jinak s vámi nesouhlasím, protože dle vaší logiky by nemělo smysl ani rozbíhat DNSSEC, protože ne všichni ISP na svých DNS serverech mají DNSSEC.
Pokud začneme vkládat DANE do DNS, tak to ochrání ty uživatele/ISP, kteří podporu pro DANE mají a ostatní holt musí akceptovat riziko. Je to to samé jako DNSSEC. Nasazené to již mnohdy je a je samozřejmě "chráněn" jen ten uživatel, který má u sebe (resp. u ISP DNS) plnou podporu. Taky nevoláte po zastavení nasazení DNSSEC, protože ne každý uživatel/ISP má implementován DNSSEC. -
> Pokud začneme vkládat DANE do DNS, tak to ochrání ty uživatele/ISP, kteří podporu pro DANE mají a ostatní holt musí akceptovat riziko.
To na první pohled zní rozumně, problém je skryt v detailech. Nabízejí se tu dvě možnosti:
a. Uživatel si musí nastavit, že DNSSEC chce. Pak mu počítač odmítne spojení v případě absence DNSSEC. Čisté, ale takto to bude mít jen pár nadšenců, a provozovatelé sítí nepřejících DNSSEC se k tomu nejspíš postaví „tak si to vypněte“.
b. DNSSEC se použije automaticky, pokud je k dispozici. To fungovat bude, až na to, že to málokdy bude schopno zabránit útoku. Pokud útočník ovládá poslední míli (asi nejčastější případ), zajistí, aby DNSSEC dostupné nebylo. Stejná situace je ve chvíli, kdy stát ovládá veškeré připojení na svém území. (Nejsem si jist s Tureckem, ale vypadá to, že to by mohlo být ten případ.) Toto by pomohlo hlavně v situaci, kdy útočník ovládne síť někde u serveru, ale už nemá možnost ovládnout spojení k DNSSEC. Jako lepší než nic, ale pořád je to poněkud slabé ve srovnání s vynaloženým úsilím. Navíc by to byla i slabá motivace pro správce nasazovat DNSSEC. Proto chápu snahu to vyréšit jinak. -
Existenci DNSSEC nelze před validátorem popřít. Nadřazená zóna obsahuje vždy informaci o veřejném klíči podřazené nebo informaci o tom, že podřazená není podepsaná, ale i tato informace musí být podepsaná. Nelze jednoduše podvrhnout informaci "root.cz není podepsaný, tak to neřeš". Takový DNSSEC by nedával smysl.
-
Ani v jednom bodě nemáte pravdu.
ad a) Takto DNSSEC nefunguje. Pokud doména nemá DNSSEC, tak nic se neděje. Nedochází k žádnému blokování spojení. Proč by měl počítač odmítat spojení v případě absence DNSSEC?!? Pouze v případě, kdy koncový uživatel má podporu DNSSEC (příp. DNS server u ISP), tak v případě nevalidní odpovědi (tzn. dojde k podvržení DNS záznamu), tak klient/ISP pozná, že je něco v nepořádku.
ad b) Netušíte, jak DNSSEC funguje. Informace o DNSSEC vždy drží nadřazená doména, tzn. pro firma.cz má informaci o zabezpečení správce NIC.CZ, informaci o zabezpečení serverů NIC.CZ mají zase kořenové servery. Tzn. nelze klientovi vnutit falešný DNS záznam s tím, že doména nemá DNSSEC zabezpečení, pokud klient umí pracovat s DNSSEC.
-
Kamui (neregistrovaný)
Tak v přechodném období by se mohlo používat jak DANE, tak klasika CA. Ale cílový stav by mělo být opuštění DV certifikátů. Jen pokud by DANE nefungovalo, tak by prohlížeč upozornil uživatele, že jeho připojení k internetu je rozbité a že od 1.1.20XX může dojít k problémům, a ať to řeší s poskytovatelem.
-
Ondřej CaletkaZlatý podporovatelDANE a DNSSEC naprosto nijak nesouvisi.
To jsou mi zase alternativní fakta ;) V našem vesmíru je DANE definováno v RFC 6698, kde se mimo jiné píše:
This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be protected by DNSSEC.
The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSA record has not been altered.
-
Ondřej CaletkaZlatý podporovatel
Pane j Nováku, toho soudrucha si nechte od cesty.
Takže vy tvrdíte, že když někde není napsáno MUST, tak spolu dané věci naprosto nijak nesouvisi? To je opět krásný příklad ohýbání reality. No dobrá, tak se pojďme začíst do kapitoly 4.1:
A TLSA RRSet whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and MUST be considered unusable.
-
Palo M. (neregistrovaný)
- Vzhladom na tom, ze https pouziva ten isty port 443, tak je filtrovatelny priblizne rovnako. Respektive, na odhalenie DNScrypt po TCP treba DPI (financne narocnejsie) - podla vsetkeho prave preto zvolili pre DNScrypt port 443, aby sa to nedalo odfiltrovat jednoducho podla portu, a tiez aby bola vacsia sanca prejst cez proxy servery.
- To, ze DNScrypt nepouziva certifikacne autority, sa da povazovat za bezpecnostnu vyhodu.Ja by som este pridal nasledujuce rozdiely:
- DNScrypt proxy moze byt velmi jednoducho postavene "vedla" kazdeho existujuceho resolvera (na tom istom hoste, iny port) s minimalnym usilim ("DNS over HTTPS" bude potrebovat to plne https, s vlastnym certifikatom, takze pravdepodobne aj nieco ako ACME klienta na jeho automaticku spravu).
- DNScrypt sice nema RFC (v ociach IETF ako protokol "neexistuje"), ale funguje v reale, staci nainstalovat klienta a pripojit sa na verejne pristupne proxy. Alebo si aj sam nainstalovat svoju privatnu proxy a pouzivat tu. Zatialco "DNS over HTTPS" je este len v priprave.
ČLÁNKY DO MAILU