Forum Debian Users Gang

U mnie też FF nie przechodzi testu na ESNI niby z włączonym network.security.esni.enabled  i ustawionym własnym proxy do dnscrypt. Może coś pozmieniali i coś się popsuło. Jedyne co mogę powiedzieć, to to, że to info opisane w tamtym artykule nie daje już takiego rezultatu jak na fotkach tam zamieszczonych — patrzyłem w wireshark i domena jest widoczna, czyli coś musieli pochrzanić. Pytanie kto, CF czy FF? xD

Ta opcja network.trr.uri jest opisana, tj. ustawiona jest przez GUI. Więc możesz albo przez GUI albo ręcznie przez about:config.

P.S. 2: jeżeli dobrze pamiętam, Debian używa adresu 127.0.2.1. Czy konfigurując 'Local DoH' trzeba użyć właśnie tego adresu czy może to być 127.0.0.1 użyty w twoim tekście?

Ale do czego używa tego adresu?

wiarus napisał(-a):

Cześć Morfik.
Sorry, nie dopisałem o co chodzi - czy czasem Debian nie używa adresu 127.0.2.1 po zainstalowaniu DNSCrypt-Proxy? Przy okazji: jeśli ten adres jest używany i korzystamy z socketów systemd, to konfigurując 'Local DoH' adres powinien być 127.0.0.1 (jak w Twoim arcie) czy mogą być różne: 127.0.2.1 dla DNSCrypt i 127.0.0.1 dla 'Local DoH'? Ma to jakieś znaczenie?

Zwyczajowo localhost jest ustawiony dzięki hosts na 127.0.0.1, natomiast należy pamiętać, że zgodnie z RFC 3330 cała klasa adresowa 127.0.0.0/8 jest zarezerwowana dla komunikacji z lokalnym stosem sieciowym

Cześć.

Urbinek a więc taka konfiguracja jest w porządku - 127.0.2.1 ogólnie dla DNSCrypt-Proxy a w przypadku 'Local DoH', jak w arcie Morfika, 127.0.0.1?

Właśnie, Morfik korzystając z socketów systemd, nie trzeba dodawać np. reguły `net_bind_service` do profilu AppArmor oraz korzystać z opcji user_name, prawda? (W przypadku wyłączenia socketów, trzeba wprowadzić te zmiany).

A tak przy okazji - korzystacie np. tylko z serwerów DNSCrypt albo tylko DoH czy może "mieszacie" wszystkie, jakie są dostępne w pliku public-resolvers.md? A jeszcze wracając do ESNI - z tego, co pamiętam na stronie Wiki (GitHub) jest napisane, że DNSCrypt jest kompatybilny z tym rozszerzeniem i nie trzeba nawet używać protokołu DoH i Cloudflare. A przecież Firefox ignoruje ESNI jeżeli DoH nie jest włączone w przeglądarce (stąd mechanizm 'Local DoH'). Sam już nie wiem...

Chyba pozostaje mieć nadzieję, że - po skonfigurowaniu 'Local DoH' z Cloudflare, jak najwięcej stron www, które zostaną odwiedzone będzie wspierało ESNI/ECH, będzie korzystać z TLS 1.3 itd. :- )

Pozdro.

Ostatnio edytowany przez wiarus (2021-07-29 15:13:00)

Wygląda na to, że ESNI jest już przestarzałe i firefox przeszedł (albo przechodzi) na ECH (Encrypted Client Hello) i cały ten mechanizm ESNI zostanie zastąpiony przez ECH. Dlatego ta strona CF chyba już nigdy nie będzie zwracać na FF, że ESNI jest wspierane, bo już nie będzie, no chyba, że na FF ESR. xD

Tu do poczytania trochę więcej:
https://bugzilla.mozilla.org/show_bug.cgi?id=1667801

Ostatnio edytowany przez morfik (2021-07-31 17:50:29)

Niby mam włączone oba (ESNI i ECH) ale to FF ma jakieś problemy i chyba nie do końca oni wiedzą co tam robią. ESNI wyleci tak czy inaczej, bo jest to lekka patologia, dlatego trwają prace nad ECH, choć i tak potrzebny jest nowszy TLS, bo ten 1.3 ma błędy konstrukcyjne i dlatego takie problemy są z tym SNI.

Ostatnio edytowany przez morfik (2021-08-12 01:49:09)

1.3 od 1.2 może i jest lepszy ale 1.3 miał w założeniu adresować problemy z prywatnością, które były w 1.2, a tego nie zrobił. Dlatego 1.3 jest w zasadzie podobny do 1.2 i potrzebne jest 1.4, a ten idzie jak krew z nosa właśnie przez te ograniczenia w TLS. I potrzebne jest coś innego.

Ostatnio edytowany przez morfik (2021-08-12 15:25:19)

Niech i ja się dorzucę...
Firefox v.78.13.0esr i u mnie test https://www.cloudflare.com/ssl/encrypted-sni/ działa 4x zielono

Jedyne co dziwi- test "Secure DNS", prawie zawsze przy pierwszym jego uruchomieniu jest nieszyfrowany, a powtórne lub nawet i konieczne kolejne ponowienie dopiero potwierdza szyfrowanie. Dlaczego nie natychmiast...?
Ale i przeglądarka Google-Chrome powiela identycznie ten schemat, bez ESNI oczywiście.

Hej.

mark, Fryc w waszym przypadku ESNI jest włączone wg. testu Cloudflare
bo użuywacie Firefoxa w wersji ESR, w której ESNI ma być wspierane.

Jak już pisałem to w wersji 85. mieli to usunąć, ale wygląda na to, że np. w 90. też była
dostępna opcja do włączenia ESNI. Myślę że w teraz, kiedy jest dostępne
ESNI i ECH warto włączyć obie opcje. Dopiero, kiedy ESNI zostanie
porzucone na dobre można będzie zostawić ECH.

A jeśli chodzi o wynik "Secure DNS", to u mnie też często za pierwszym razem nie
wskazywał poprawnej wartości. Czasem nawet po kilku przeładowaniach strony, powtórzeniu testu.

A tak przy okazji - morfik w artykule dotyczącym włączania ESNI
wspomniałeś o zmianie właściciela dla pliku localhost.pem. Po tej zmianie, jako grupa
ustawiony jest root.

Czy myślisz, że dobrym pomysłem jest zmiana tej grupy na nogroup?
Tylko pamiętam, że w którymś miejscu manuala Debiana (https://www.debian.org/doc/manuals/securing-debian-manual/) dotyczącego zabezpieczania systemu, było takie zdanie "it is not a good idea to use nobody or nogroup for every service not running as root" - a przecież DNSCrypt-Proxy nie działa jako root...

Co o tym myślisz? Lepiej zostawić użytkownika _dnscrypt-proxy i grupę root czy zmienić tak, jak opisałem wyżej?

Ostatnio edytowany przez wiarus (2021-09-08 16:22:15)

Cześć. No tak, masz rację. Nie ma sensu zmieniać grupy dla tego pliku.

A tak przy okazji: zawsze jestem zdziwiony, że profil dla DNSCrypt-Proxy, tworzony od podstaw, jest tak prosty i niewielki. Ale to tylko dygresja.

Jeszcze jedno: morfik czy po skonfigurowaniu 'Local DoH', dodaniu wyjątku dla certyfikatu, podczas pierwszego wejścia na adres https://127.0.0.1:3000/dns-query, w Menadżerze Certyfikatów, zakładka Serwery miałeś następujący cert.:

Serwer      Nazwa certyfikatu           Czas życia
----------------------------------------------------
127.0.0.1   Internet Widgits Pty Ltd    Tymczasowy

Pozdrawiam.

Ostatnio edytowany przez wiarus (2021-08-26 11:05:08)

To zależy jak masz skonfigurowane. Jak używasz TCP, to ruch wygląda mniej więcej tak samo jak zwykle https. Jak używasz UDP, to pewnie wygląda jak QUIC albo zwyczajny ruch UDP, tego nie wiem, bo nie wiem jak wygląda QIUC.  xD