DNS over TLS támogatás érkezhet az Android felhasználókhoz

Titkosítás, biztonság, privát szféra

Az XDA Developers kiszúrta, hogy DNS over TLS támogatással kapcsolatos kódokat commitoltak az AOSP-ba, ami arra utalhat, hogy a következő Android verziókban a felhasználók számára is elérhető funkció lehet a DNS kérések titkosítottan küldése. Természetesen, a funkció megléte önmagában még nem garantálja, hogy teljesen eloszlanak a DNS kérésekkel kapcsolatos privát szféra aggályok ...

Részletek itt.

( uid_4263 v | 2017. 10. 26., cs – 11:10 )

Ugyanakkor legyen a google dns a default! Igy az ISP nem tudja majd, de ők igen!

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Van egy ilyen mániákus Google-gyűlölő haverom. Keresés csak duckduckgo-val. Email címe valami nagyon privacy-aware kicsi szolgáltatónál van, akik pénzért adnak majdnem annyi email tárhelyet mint az ingyen Gmail tizede. Böngészőből valami egyedi tor-ral összegyógyitott firefox (vagy chromium?) forkot használ.
Úgy le szívták vagy fél éve a Paypal számláját mint a részeg matróz a rumosüveget.

jó, de azok a gyíkemberek voltak, és a végén soros nevetett.

tor-ra meg annyit, hogy utóbbi időben folyamatosan látom a hírekben, hogy tor-on keresztüli "dark web" oldalak ip címei kerülnek ki, mert pöcsül konfiguráltak valamit a gépen.

"I'd rather be hated for who I am, than loved for who I am not."

ROM: Lineage OS
Böngésző: firefox (lassú, de legalább nem lop)
Maps: csak vészhelyzetben, böngészőből (ami egyébként töröl minden lokális adatot exitkor, és semmihez sincs joga)
Kereső: duckduckgo
Gmail: itt már rezeg a léc, én K9 appal tolom imapen keresztül. Mivel a mobilnethez nem jár publikus IP cim, igy ebből nem tud földrajzi* adatokat felszivni

Egyébként is a play store az egyetlen (jogoktól fosztott) alkalmazásom a telefonon ami google-ös.
Na jó, ott a waze, de abban meg dummy local-only user van, nem loginoltam be.

*szerk.: javitva

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

A weboldalak kb. 90%-an van Google Analytics. Ez egy nyomkoveto rendszer, innen tudjak az oldaltulajok, hogy mire keresve talalnak rajuk, honnan jonnek a felhasznalok, stb (a referrernel sokkal tobbet).

YT videokbol eleg jol megallapithato az erdeklodesi korod ha eleg sokat hasznalod hozza. A velemenyed mondjuk nem feltetlenul, ha nem szolsz hozza, es nem like-olsz.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Közben leesett hogy mire gondolsz. Na majd ezzel is kezdünk valamit :)
A youtube nalam readonly modeban van: mivel be sem jelentkezem, ezert nem likeolok, nem commentelek, nem iratkozok fel, es fokent nem csinalok listakat vagy toltok fel videokat. Ami erdekel par csatorna azt kezzel kinyitom es megnezem van-e uj video.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

1-2 központi helyen (google,facebook) gyülekezik az emberről mindenféle érzékeny információ. Most már ott tartunk hogy csak a személyi igazolvány azonositód hiányzik a történetből. Én abba a táborba tartozom aki ezt nem kivánatosnak és veszélyesnek tartja.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Ki kötelez arra hogy megadd, vagy valós adatokat adj meg? Ez kutyagumi. Nekem is egy csomó olyan profilom van, ami teljesen kamu adatokkal van kitöltve, csak azért hogy ki legyen töltve. Van egy sima catch-all két mail domain-en. Egyik a mindenféle oldal regisztrációkhoz, oldalneve@domain címekkel regelek, így amint spam jön megvan ki és kinek adta el/szivárogtatta ki a címem. A másik domain szintén catch-all, hivatalos, valós személyazonosságot megkövetelő helyeken van használva, hasonlóan szervezetneve@domain címekkel. A gmail-es címemre alig megy valami.

Androidot használok, alkalmazások telepítése megfontolt módon, jogosultságok racionalitásának átgondolásával történik.

Ugyan nem rettegek a Google-től, de fel vagyok készülve arra, hogy bármikor meg tudjak válni tőle.

A saját ízlésemet nem annyira félek megosztani, hiszen megnézném milyen fogást talál rajtam bárki abból az információból, hogy még mindig hallgatok Iron Maident. Gyanítom a Google szakemberei sem fogják kirámolni a kecót, amíg elmegyek tojásért. Reklámot valóban kapni fogok így is, úgy is, de akkor nekem hasznosabb a proci reklám, mint a tampon vagy a pelenka.

Ha annyira célzottan meg akarják fektetni a biztonságodat, akkor meg fogják tudni, hiába teszel akármit! Valid lesz az SSL, fent lesz a VPN, minden zöld lesz, senki sem sért majd jogot, s mégis!

A legjelentősebb védelmet józan paraszti ésszel, és out-of-the-box gondolkodással tudod elérni. Ha ezek nincsenek, akkor tökmindegy, ha meg valamilyen politikai erő pályázik rád, akkor meg a szolgáltatóidat környékezik meg, nem téged.

S akik ellen ez ér valamit, azt nem fogja érdekelni a Fear of the dark.

--
Where do you want to go today?
[nobody@salcay:~]$_

( ricsip v | 2017. 10. 26., cs – 16:52 )

Naív hülye kérdés: ki(k)nek (melyik szolgáltatóknak) a DNS szervere szólítható meg TLS-en keresztül?
--

( suckit | 2017. 10. 27., p – 09:54 )

#lustavagyokutánaolvasni
Valaki elmagyarázná, hogy:
- ha "to stop ISPs from knowing what websites you visit" a cél, akkor mi értelme ezt az ISP-nek implementálnia (a Google-ön és más hasonló, adatgyűjtésből élő (DNS) szolgáltatókon kívül)? Hiszen ő terminálja a kapcsolatot, tehát pont ugyanannyira fogja látni, mint most. Azaz ez azzal is együtt jár, hogy adathalász DNS-t kell használnod. Ha meg azt használod, az ISP ma is csak akkor látja mit nézel, ha ténylegesen elkapja a feléjük menő forgalmat és feldolgozza azt, amit vsz. kevesen csinálnak. (az ISP-k jellemzően nem adathalászatból élnek)
- a DNS-nél ugye IP címet adunk meg. A certificate CN-jében általában hostnév van. Mire kell itt kiállítani a certificate-et, és ha továbbra is hostname-re, mi értelme az egésznek?

- a DNS-nél ugye IP címet adunk meg. A certificate CN-jében általában hostnév van. Mire kell itt kiállítani a certificate-et, és ha továbbra is hostname-re, mi értelme az egésznek?

a DNSSEC hogy működik? Az csak a tárolt/lekérdezett rekordok tartalmát védi, v. tudja saját magát is hitelesen prezentálni a kliens felé?
(nagy a setétség a fejemben erről.. :))
--

- a DNS-nél ugye IP címet adunk meg. A certificate CN-jében általában hostnév van. Mire kell itt kiállítani a certificate-et, és ha továbbra is hostname-re, mi értelme az egésznek?

Ez jó kérdés, nem tudom a választ, de amit találtam mind hostname-re volt kiállítva. 


me@comp:/# openssl s_client -showcerts -connect 185.49.141.37:853 | openssl x509 -text 
| grep "CN"
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = getdnsapi.net
verify return:1
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject: CN=getdnsapi.net

De majd a DNS szerveren lekéri a hostnamehez tartozó IP-t és ellenőrzi jó-e. (Oh wait :))

A DNSSEC-nél nincsen ott a certes móka, ott a trust anchor az IANA publikus kulcsa (https://www.iana.org/dnssec/files).

A 0. szintet így bele kell égetned a kliensbe. A további szinteknél (legyen N a org. és N+1 a example.org.) ebből a trust anchorból tudsz dolgozni: amikor lekérdezed a root szervert, hogy ki a franc a org., kapsz egy aláírt választ, amit tudsz ellenőrizni, mert tudod a kulcsot. Utána lekérdezed, hogy mi az org. kulcsának a hashe (DS rekord a root szerverektől) ill. mik a névszervereik (NS rekord a root szerverektől). Ezután lekérheted a használt publikus kulcsot a org. névszervereitől (DNSKEY rekord) és összevetheted azzal a hashel, amit a root szervertől kaptál vissza. Innentől ismered a org. publikus kulcsát.
Amikor mész tovább N+1-re, akkor ugyanígy csinálod, lekéred a DS és NS rekordokat a org.-tól, aztán az example.org. névszervereitől a DNSKEY rekordot (összeveted a DS-sel, amit az org. névszervertől kaptál), innentől tudod, hogy milyen kulcsot használ és végül lekéred a kért A rekordot és a hozzá tartozó RRSIG rekordot.

Aztán ha bárhol a DS és a DNSKEY között fura eltérés van, akkor vége, nem szórakozol vele tovább, valaki elbökött valami konfigot vagy aktívan próbálnak megtörni :) Ha egy DNSSEC aláírt zónában van olyan delegáció, ami nem használ DNSSEC-et, akkor a DS kérésre NX-et kapsz vissza (NSEC vagy NSEC3, mert ugye authenticated denial van - vagyis a szervernek kötelessége úgy visszaszólnia, hogy "te, ilyen nincs", hogy az bizonyíthatóan attól a szervertől érkezzen arra a kérdésre [NSEC-nél ezzel gyakorlatilag végig tudsz menni egy teljes zónán és felsorolni a rekordjait, NSEC3-nál.. kevésbé egyszerűen :) ]). Ha mondjuk a org.-tól kaptál vissza DS rekordot, de amikor az example.org. névszervereit kérdezgeted és nem kapsz vissza RRSIG rekordot, akkor próbálnak megtörni (vagy valaki elbökött egy konfigot :) ). És nagyjából ennyi.

Innentől (ha a teljes lánc DNSSEC-kel védett és ismered a root kulcsokat), önmagát is tudja hitelesen prezentálni és a lekérdezett rekordokat is (a roottól lefelé tudod hitelesíteni az összes delegációs szinten). Sajnos szerintem soha nem fog igazán elterjedni (különösen a DANE [bepatkolod az SSL kulcsaidat egy aláírt DNS rekordba, ami ugye a roottól lefelé hitelesíthető, így nincs szükség CA-kra], csak ugye ez egyik oldalon a CA-knak rossz lenne, a másik oldalon meg (talán sok helyen jogosan) sokan nem bíznák a kulcsaikat a hiearchikus rendszerre, mert a fenti példában az IANA el tudja téríteni a teljes eu. zónát (olyan DS/NS rekordot ad vissza, amilyet akar, ugyebár), a org. pedig el tudja téríteni az example.org.-ot (ő is olyan DS/NS rekordot ad vissza, amilyet akar).

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

- a DNS-nél ugye IP címet adunk meg. A certificate CN-jében általában hostnév van. Mire kell itt kiállítani a certificate-et, és ha továbbra is hostname-re, mi értelme az egésznek?

Belenézve az RFC-be... ez még nyitott kérdés :)

The client will then authenticate the server, if required. This
document does not propose new ideas for authentication. Depending on
the privacy profile in use (Section 4), the DNS client may choose not
to require authentication of the server, or it may make use of a
trusted Subject Public Key Info (SPKI) Fingerprint pin set.

A Section 4-ben egy draftot linkelnek, amiben leírnak két módszert, hogy hogyan határozd meg a DNS szerver nevét: ha csak elég az opportunistic privacy, akkor lekéred a használandó DNS szerverek neveit SRV rekordként, aztán öröm-és-bódogság (és továbbra is megtörnek, mint a fene egy MITM-mel :) ). Ha nagyon strict vagy, akkor 1) kézzel beállítod [IP helyett IP és hostnév a kliens DNS konfigja] 2) kézzel beállítod csak a hostnevet, a kliens meg lekéri az SRV rekordot hozzá attól a DNS szervertől, amit talál (DNSSEC-kel alá írva kell lennie a válasznak!) és használja a kapott rekordban levő eredményt vagy 3) kiszórod DHCP-vel a hostnevet is (csak nincs rá DHCP extension :) )

Úgyhogy ránézésre ebből is sokáig-sokáig a legtöbb esetben opportunistic lesz (vagy Strict az OS-sel szállított SPKI fingerprintekkel néhány well-known szerverhez [*]), és előtte még kell hozzá egy DNSSEC.

[*]: a fél világ által használt Google-ös 8.8.8.8 pl. pont nem figyel a 853-on :)

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

( hzsolt94 v | 2017. 10. 28., szo – 01:01 )

Azért az itt egy hatalmas csúsztatás, hogy ez megakadályozná az ISP-t a meglátogatott oldalak domainnevének megfigyelésétől.

Az összes modern böngésző támogatja ugyanis az SNI-t, ami egy TLS kapcsolat kiépítésekor mindenféle titkosítás nélkül átküldi a célszerver domain nevét, ezt az isp bármiféle közbeékelődés nélkül, passzív módon naplózhatja. Ennek fényében hajunkra kenhetjük hogy a névfeloldást nem tudta naplózni...

Az SNI még a TLS réteg, így tudja eldönteni a szerver, hogy melyik certet dobja vissza a klienshez.

Az OpenSSL doksi szerint a ClientHello messageben megy:

-servername name
Set the TLS SNI (Server Name Indication) extension in the ClientHello message.

(https://wiki.openssl.org/index.php/Manual:S_client(1))

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

Nem. Te a HTTP/1.1 Host: fejlécére gondolsz, de az nem ugyan az mint az SNI.

Az SNI simán plaintextben megy át encryption nélkül (ahogy írják is felettem). Egy packetdumpban simán tudsz rá grepelni.

Ráadásul ha valahogy ki is lövöd az SNI-t akkor:
a) a szerver hibás certet fog visszaküldeni, így nem igazán megoldott a biztonságos TLS
b) ha mégis helyes certet küldene, akkor meg abban benne van a meglátogatott domain név, szintén titkosítatlanul

Ennek a DNS over TLS-nek privacy szempontból semmi értelme. Más előnye persze lehet...

Szerintem inkább az a hatalmas csúsztatás, hogy az ISP-ket úgy állítja be, mintha érdekükben állna kémkedni a usereik iránt.
Az ISP-k nagyon kis százaléka reklámoz (egyáltalán) a felhasználónak bármit, ellentétben ugye azzal, aki ezt az egészet most elkezdte nyomni.
Álságos kicsit ez így.