<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Doh on Morfitronik</title>
    <link>https://morfikov.github.io/tags/doh/</link>
    <description>Recent content in Doh on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Mon, 21 Nov 2022 17:42:00 +0100</lastBuildDate><atom:link href="https://morfikov.github.io/tags/doh/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Oblivious DoH (ODoH) z dnscrypt-proxy na Debian Linux</title>
      <link>https://morfikov.github.io/post/oblivious-doh-odoh-z-dnscrypt-proxy-na-debian-linux/</link>
      <pubDate>Mon, 21 Nov 2022 17:42:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/oblivious-doh-odoh-z-dnscrypt-proxy-na-debian-linux/</guid>
      <description>&lt;p&gt;Parę miesięcy temu natrafiłem na taki oto &lt;a href=&#34;https://blog.cloudflare.com/oblivious-dns/&#34;&gt;artykuł na blogu Cloudflare&lt;/a&gt;, który poświęcony jest
poprawie prywatności wykonywanych przez klientów zapytań DNS za sprawą wykorzystania mechanizmu
zwanego Oblivious DoH (ODoH). Oczywiście postanowiłem już wtedy zbadać czym ten ODoH jest ale
standardowe narzędzia dostępne w linux&#39;ie (Debian/Ubuntu) jeszcze (przynajmniej wtedy) nie dojrzały
do obsługi ODoH. Obecnie już jest trochę lepiej ale Oblivious DoH wciąż jest w fazie
eksperymentów (&lt;a href=&#34;https://datatracker.ietf.org/doc/html/rfc9230&#34;&gt;RFC9230&lt;/a&gt;). Póki co, jedynym znanym mi narzędziem, które posiada wsparcie dla
ODoH jest &lt;a href=&#34;https://dnscrypt.info/&#34;&gt;dnscrypt-proxy&lt;/a&gt;, którego instalację i konfigurację do współpracy z &lt;code&gt;dnsmasq&lt;/code&gt;
już &lt;a href=&#34;https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/&#34;&gt;jakiś czas temu opisywałem&lt;/a&gt;. Mając wsparcie dla ODoH w &lt;code&gt;dnscrypt-proxy&lt;/code&gt; możemy pokusić się
o wdrożenie Oblivious DoH w swoim systemie i sprawdzić czy faktycznie taki zabieg przyczyni się do
poprawy prywatności wykonywanych przez nas zapytań DNS i właśnie temu zagadnieniu będzie poświęcony
niniejszy wpis.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Szyfrowany DNS z dnscrypt-proxy i dnsmasq na Debian linux</title>
      <link>https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/</link>
      <pubDate>Sat, 19 Sep 2020 14:13:00 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/szyfrowany-dns-z-dnscrypt-proxy-i-dnsmasq-na-debian-linux/</guid>
      <description>&lt;p&gt;Ostatnio na forum dug.net.pl jeden z użytkowników &lt;a href=&#34;https://forum.dug.net.pl/viewtopic.php?id=31524&#34;&gt;miał dość spory problem&lt;/a&gt; z ogarnięciem
zadania polegającego na zaszyfrowaniu zapytań DNS z wykorzystaniem &lt;a href=&#34;https://dnscrypt.info/&#34;&gt;dnscrypt-proxy&lt;/a&gt; i
&lt;a href=&#34;http://www.thekelleys.org.uk/dnsmasq/doc.html&#34;&gt;dnsmasq&lt;/a&gt;. Ładnych parę lat temu opisywałem &lt;a href=&#34;https://morfikov.github.io/tags/resolver/&#34;&gt;jak skonfigurować te dwa narzędzia na Debianie&lt;/a&gt;
(i też na OpenWRT), choć od tamtego czasu w świecie linux&#39;owym trochę rzeczy się pozmieniało. Dla
przykładu, dnscrypt-proxy przeszedł gruntowną przebudowę, no i też systemd jest w powszechniejszym
użyciu niż to miało miejsce w tamtych czasach, przez co w sporej części przypadków usługi takie jak
&lt;code&gt;systemd-networkd.service&lt;/code&gt; czy &lt;code&gt;systemd-resolved.service&lt;/code&gt; są już włączone domyślnie. Zatem sporo
informacji zawartych w tych napisanych przeze mnie artykułach już niekoniecznie może znaleźć
obecnie zastosowanie. Dlatego też pomyślałem, że nadszedł już czas, by ździebko zaktualizować tamte
wpisy. Ostatecznie stanęło jednak na tym, by w oparciu o te artykuły napisać kompletnie nowy tekst
na temat szyfrowania zapytań DNS na linux przy wykorzystaniu oprogramowania &lt;code&gt;dnscrypt-proxy&lt;/code&gt; oraz
&lt;code&gt;dnsmasq&lt;/code&gt; i zawrzeć w nim te wszystkie ciekawsze informacje, które udało mi się pozyskać przez te
ostatnie lata w kwestii poprawy bezpieczeństwa i prywatności przy przeglądaniu stron WWW.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak włączyć w Firefox ESNI (Encrypted SNI)</title>
      <link>https://morfikov.github.io/post/jak-wlaczyc-w-firefox-esni-encrypted-sni/</link>
      <pubDate>Mon, 10 Aug 2020 18:15:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-wlaczyc-w-firefox-esni-encrypted-sni/</guid>
      <description>&lt;p&gt;Obecnie szyfrowanie zapytań DNS staje się powoli normą za sprawą protokołu DoH (&lt;a href=&#34;https://en.wikipedia.org/wiki/DNS_over_HTTPS&#34;&gt;DNS over HTTPS&lt;/a&gt;)
lub DoT (&lt;a href=&#34;https://en.wikipedia.org/wiki/DNS_over_TLS&#34;&gt;DNS over TLS&lt;/a&gt;). Można by zatem pomyśleć, że wraz z implementacją szyfrowania tego
kluczowego dla działania internetu protokołu (przynajmniej z naszego ludzkiego punktu widzenia),
poprawie ulegnie również nasza prywatność w kwestii odwiedzanych przez nas stron WWW. Niemniej
jednak, w dalszym ciągu można bez problemu wyciągnąć adresy domen, które zamierzamy odwiedzić. Nie
ma przy tym żadnego znaczenia ile stron jest hostowanych na danym adresie IP, ani nawet fakt, że
ruch do serwera WWW będzie szyfrowany (w pasku adresu wpiszemy &lt;code&gt;https://&lt;/code&gt; ) z wykorzystaniem
protokołu SSL/TLS (w tym również TLS v1.3). Wszystko przez rozszerzenie SNI (&lt;a href=&#34;https://en.wikipedia.org/wiki/Server_Name_Indication&#34;&gt;Server Name
Indication&lt;/a&gt;), którego to zadaniem jest umożliwienie jednemu serwerowi na prezentowanie wielu
certyfikatów hostowanych w jego obrębie domen. Dzięki takiemu rozwiązaniu, każda domena może
szyfrować ruch niezależnie od siebie na linii serwer&amp;lt;-&amp;gt;klient (używać innych kluczy szyfrujących).
Niemniej jednak, podczas nawiązywania szyfrowanego połączenia, w pakiecie ClientHello przesyłanym
do takiego serwera musi znaleźć się nazwa domeny, której to certyfikat serwer będzie musiał nam
przedstawić. Niestety ten pakiet jest przesyłany przez sieć otwartym tekstem, przez co każdy, kto
podsłuchuje naszą komunikację (w tym też nasz ISP), bez problemu może ustalić na jakie strony
internetowe wchodzimy. Ostatnimi czasy jednak pojawiły się dwa rozszerzenia ECH (&lt;a href=&#34;https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello&#34;&gt;Encrypted Client
Hello&lt;/a&gt;) oraz ESNI (&lt;a href=&#34;https://tools.ietf.org/html/draft-ietf-tls-esni-07&#34;&gt;Encrypted SNI&lt;/a&gt;), które mają zaadresować problemy związane z prywatnością
przez pełne zaszyfrowanie pakietu ClientHello lub też zaszyfrowanie jedynie pola SNI w tym pakiecie.
Póki co, prace nad tymi rozszerzeniami nie są jeszcze skończone ale Firefox w połączeniu z
CloudFlare powoli testują ESNI. Postanowiłem zatem dobrowolnie przyłączyć się do grupy testerów i
wdrożyć na swoim linux&#39;ie to rozszerzenie ESNI dla przeglądarki Firefox.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
