DNS-over-HTTPS (DoH) engedélyezése Firefox böngészőben

The DNS-over-HTTPS (DoH) protocol is currently the talk of the town, and the Firefox browser is the only one to support it. [...] This also means that apps that support DoH can effectively bypass local ISPs traffic filters and access content that may be blocked by a local telco or local government -- and a reason why DoH is currently hailed as a boon for users' privacy and security.

A lépésről lépésre beállítás leírása itt. További infók a Mozilla wikijében.

Hozzászólások

Beállítottam "3"-ra (kizárólag DoH), meglátjuk hogy szuperál. Eddig működik.

--
trey @ gépház

"effectively bypass local ISPs traffic filters" ... a macska-egér játék újabb szintre léphet, szivassuk csak a rendszerüzemeltetőket.

Nem csak a rendszer üzemeltetőket:

By planning to support DNS-over-HTTPS, Mozilla is throwing a monkey wrench in many ISPs' ability to sniff on customers' traffic and filter traffic for government-mandated "bad sites."
Source
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Tokre nem olvastam utana semminek, de hogy erinti ez a local DNS szervereket, ha minden bypass? Teszem azt a gep LAN-ban van, es a helyi DNS szerver kiszolgal egy rakas hostnevet ami *CSAK* a belso halorol elerheto.

Akkor most ezek nem fognak feloldodni Firefoxban, vagy mi? Es meg csak nem is filterezni, logolni, meg ilyesmit akarok, erted... Eddig is kurva nagy szopas volt, hogy az userek fele 8.8.8.8-at allitott be DNS szervernek, aztan meg jott rinyalva h. a "host amit megadtal nem letezik", ezt vegul megoldottam ugy h. force-redirect minden kimeno DNS requestet a belso DNS szerverre, most akkor ez ugrott. Remek.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

network.trr.mode == 3 eseten pontosan az a gond van, amit mondasz, lokalis LAN-on elerheto DNS nevek eltunnek a sullyesztoben. 2-es ertek mellett (DoH mellett lesz backup DNS query is) nincs ilyen problema.

Mondjuk nalam out of the box egyaltalan nem mukodott a DoH, meg kellett adni egy network.trr.bootstrapAddress-t is (gyarilag ez ures volt).

Most hogy kiprobaltam, megyek vissza a rendes DNS-re.

Hogy részletesebben leírjam: ki van adva feladatul, hogy facebook.com, stb. nincs a cégnél.
Eddig a lokál DNS-ből behazudtunk egy nem létező címet. A hosts fájlt a user nem tudta birizgálni.

Jövőben? Ha HTTPs feletti webDNS lesz, kénytelenek leszünk kibontani a HTTPs forgalmat.
Pivacy? Nem érzem hogy a fő cél teljesülne a HTTPs forgalomba való belenézéssel.

A macska-egér játék kimenetele így nem biztos, hogy a user érdekét fogja szolgálni.

Hát igen, de jó is lenne, ha a Mozilla már másfél évvel ezelőtt tett volna Group policy támogatást a böngészőjébe, hogy Winen is kényelmesen és központilag lehessen konfigurálni, és ha lenne erre beállítás benne (szerk.: nem tudom, lehet-e sort linkelni fájlban GitHub-on, mindenesetre: https://github.com/mozilla/policy-templates/blob/master/windows/en-US/f… <string id="DNSOverHTTPS">).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mondjuk ha az SNI encryptelve van ezzel a módszerrel, akkor egy kicsit nehezebb lesz a buli, mert nem látod, hogy milyen certet kellene hazudni a kliensnek.

Mondjuk pont ennél DoH-nál kicsit tyúk-tojás, mert ugye a publikus kulcs is a dnsben van, szóval ott ezt vagy nem játszák, vagy a sima dnssel játszák, akkor meg tulajdonképpen bele lehet harákolni egy saját publikus kulcsot. Kivéve, ha DNSsec, bár lehet azellen az se véd.

Szóval azért elsőre nem triviális :)

Az ukrán kollégám mondott valami hasonlót (mindketten Németországban dolgozunk), hogy Oroszországban mintha lenne valami hasonló már most is (vagy jóváhagytak hozzá valami törvényt és éppen vezetik be, nem emlékszem), hogy a szolgáltató felrakatja veled a saját HTTPS certjét mert államilag kötelező, és szétproxyzza a forgalmat mintha sima HTTP lenne, kész. így a hatalom nagyjából abba néz bele amibe akar, szevasz.

Nem kérdéses, hogy céges gépeken is így lesz (vagy már most is így van) ergó még annyi privacy-d sem lesz, mint korábban. GOTO 10.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Ez csak a szokásos játék, amit már az IT is jó pár évtizede nyom: A szoftver cégek igyekeznek egyre biztonságosabb termékeket csinálni (miközben azok komplexitását folyamatosan növelik), miközben csomó mindenkinek meg pont az lenne az érdeke, hogy a programok ne legyenek annyira biztonságosak, szóval elkezdenek újabb és újabb sérülékenységeket keresni, vagy épp megakadályozni, hogy adott technológia használható legyen (így, vagy úgy). Nem véletlenül volt tiltva US-ben az erős encryption jó ideig..
Ez most kb ugyan ez pepitában: Magasabb szinten szeretnék ha a userek mindennapi életébe bele tudnának szólni, de így már nem működne az a megoldás amivel ezt régebben meg tudták oldani.. Nincs itt kérem semmi látni való, csak a szokásos arms-defence race megy még mindig (és nincs sok esély arra, hogy ez valaha megálljon)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Sub

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A linkelt cikk nagyon "jó" elrettentésként öreganyámnak, hogy miért ne állítsa be ezt. Nem is neki való az ilyen beállításokat túrni. Laikusnak hangzatosak a SPoF stb. szavak. A Cloudflare-ezésre pedig ott a cikkben is, hogy egy rakás DoH-kompatibilis szerver közül választsz, de magadnak is felállíthatsz egyet.

--
Sent from my OnePlus 5T

Ez miben más mint az ssh tunnel, vpn vagy a proxy?
Vagy csak egy másik módja, a kliens "elrejtésének"?

Hogy érinti ez azt a fajta tartalomkiszolgálást, ahol a dns geoip alapján próbált a klienshez legközelebbi kiszolgálót visszaadni?
Pár helyen próbáltam utánanézni a doh féle edns client subnet támogatottságának, de mintha ez nem lenne mindenhol teljesen megoldott, vagy lehet, hogy annyira alap része, hogy fel sem tüntetik.

Így elsőre ami legkorábbi találtam az a 99 januári RFC 2459.

Defined options include an Internet electronic mail address, a DNS name, an IP address, and a uniform resource identifier (URI).

Szerk.: fogalmazás van, közel éjfél van :(

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Securing a Public IP Address - SSL Certificates
https://support.globalsign.com/customer/portal/articles/1216536

Note: Only public IP addresses can be used on OrganizationSSL certificates. You must be the owner of the public IP address as per the records held with the RIPE Network Coordination Centre (NCC).

Sőt! Korábban még engedékenyebbek voltak:
"Beginning 1 November, 2015, the CA/Browser Forum will prohibit the use of internal server names and reserved IP addresses in publicly-trusted SSL Certificates. This means if you normally receive SSL Certificates from a public CA (such as GlobalSign), you won't be able to use their certificates for internal server names any more."

Nekem nem mögy, bekapcsoltan nincs névfeloldás - kikapcsolva, majd a mellékelt linket meghívva (https://mozilla.cloudflare-dns.com/dns-query) ez fogad:
Nem kapcsolódott: lehetséges biztonsági probléma

A Firefox egy lehetséges biztonsági kockázatot észlelt, és nem lépett tovább a(z) mozilla.cloudflare-dns.com oldalra, mert ez a webhely biztonságos kapcsolatot igényel.

Mit tehet?

A(z) mozilla.cloudflare-dns.com oldal a HTTP Strict Transport Security (HSTS) nevű biztonsági házirendet használja, amely azt jelenti, hogy a Firefox csak biztonságosan kapcsolódhat hozzá. Nem adhat hozzá kivételt, hogy felkeresse ezt az oldalt.

A probléma valószínűleg a weboldallal van, és semmit sem tehet a megoldása érdekében. Értesítheti a weboldal rendszergazdáját a problémáról.)"
(Hibakód: SSL_ERROR_BAD_CERT_DOMAIN)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség