Mozilla otestuje ve Firefoxu „DNS over HTTPS“

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.

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.