В России начали блокировать протоколы DoH и DoT

[Shaman_RSHU]

Проверил, DoT заблокировали, DoH еще в процессе

[0ka]

сделайте

curl -v https://8.8.8.8:853

непонятно про какой mitm идёт речь

[Shaman_RSHU]

Как-то так

• Trying 8.8.8.8:853…

• ALPN: curl offers h2,http/1.1

• TLSv1.3 (OUT), TLS handshake, Client hello (1):

• SSL Trust Anchors:

• CAfile: /etc/ssl/certs/ca‑certificates.crt

• TLSv1.3 (IN), TLS handshake, Server hello (2):

• TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):

• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):

• TLSv1.3 (IN), TLS handshake, Certificate (11):

• TLSv1.3 (IN), TLS handshake, CERT verify (15):

• TLSv1.3 (IN), TLS handshake, Finished (20):

• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):

• TLSv1.3 (OUT), TLS handshake, Finished (20):

• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / RSASSA‑PSS

• ALPN: server did not agree on a protocol. Uses default.

• Server certificate:

• subject: CN=dns.google

• start date: Aug 10 08:39:52 2026 GMT

• expire date: Nov 2 08:39:51 2026 GMT

• issuer: C=US; O=Google Trust Services; CN=WR2

• Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption

• Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption

• Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption

• subjectAltName: “8.8.8.8” matches cert’s IP address!

• OpenSSL verify result: 0

• SSL certificate verified via OpenSSL.

• Established connection to 8.8.8.8 (8.8.8.8 port 853) from ***.***.***.*** port 31 474

• using HTTP/1.x

GET / HTTP/1.1 Host: 8.8.8.8:853 User‑Agent: curl/8.21.0 Accept: /

• Request completely sent off

• TLSv1.3 (OUT), TLS alert, decode error (562):

• OpenSSL SSL_read: OpenSSL/3.6.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0

• closing connection #0 curl: (56) OpenSSL SSL_read: OpenSSL/3.6.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0

[0ka]

митма не видно. можете сделать так?

q -v A youtube.com @tls://8.8.8.8

клиент https://github.com/natesales/q

[Shaman_RSHU]

DEBU Name: youtube.com
DEBU RR types: [A]
DEBU Server(s): [tls://8.8.8.8]
DEBU Using server 8.8.8.8:853 with transport tls
DEBU Using TLS transport: 8.8.8.8:853
youtube.com. 5m A 172.253.130.136
youtube.com. 5m A 172.253.130.190
youtube.com. 5m A 172.253.130.91
youtube.com. 5m A 172.253.130.93

[0ka]

Всё работает. Очень странно что чекер пишет про какой-то mitm

[Shaman_RSHU]

Запускал на Linux, всякие "специальные средства" были отключены, как на хосте, так и на роутере.

[nojecom]

Там походу баг в программе. Такая же картинка, как у вас, однако:

[Shaman_RSHU]

Да, бага в утилите. Пересобрал на маке - такая же картина.

[0ka]

уберите, пожалуйста, бред из названия, а именно про "начали блокировать протокол DoH".

дикий кликбейт, минус за это.

сами обьяснили в статье почему это невозможно, но оставили название...

но и c DoT вы нормальной проверки не сделали, блокировка хотя бы по порту или "по протоколу" неочевидна

про ттл трюк вообще непонятно: вы его странно описали, в команде не сделали, и первоисточник откуда про это узнали не указали - https://habr.com/ru/articles/1075272/, хотя я уже просил вас

[Lord_of_Rings]

обьяснили в статье почему это невозможно

Я этого не говорил. Это сложнее сделать, но не невозможно. ТСПУ с этим справляется. Иначе бы никто не жаловался в том числе на doh.

Ссылку добавлю.

[0ka]

Тспу справляется с блокировкой популярных резолверов, а не с блокировкой протокола

[galaxy]

Нейросеть статью писала?

TTL-трюк. В некоторых случаях поведение перехвата можно изменить, отправив один и тот же DNS-запрос сначала с небольшим TTL, а затем повторно с обычным TTL. Например:

dig @8.8.8.8 youtube.com +bufsize=512 -4 

Где тут TTL?

curl -v --resolve dns.google:443:8.8.8.8 https://dns.google/dns-query 
-H 'accept: application/dns-json' 
-G --data-urlencode 'name=example.com' --data-urlencode 'type=A'

Бекслешы пропущены. Да и все равно не работает, ибо правильный урл: https://dns.google/resolve

Если поменять только SNI, оставив IP тот же (например, через curl --connect-to ), и трафик пойдёт — вы нашли SNI-фильтрацию, а не блокировку по адресу:

Приведенная ниже команда 1) не меняет SNI, 2) не работает

[Fobian]

Но ведь...

Google Public DNS предоставляет два разных API DoH на этих конечных точках:

• https://dns.google/dns-query – RFC 8484 (GET и POST)

• https://dns.google/resolve? – JSON API (GET)

Правилен и тот, и тот.

[Hellert]

Не знал, что такую неприкрытую нейронку пропускают в статьи.

А еще https://habr.com/ru/articles/1075272/

[maksd_gt]

Не понял. А есть какя то техническая база под тезисом, что блокируется udp трафик на 853 порту? Довольно радикально сбрасывать весь трафик на 853 порт.

[Chris1337]

DoT на 9.9.9.9 вроде как у всех работает, значит никакого сброса по порту не существует.

[Yumado]

Похоже на ростелекоме не работает

[nidalee]

Почему радикально? Значит до популярных CDN-ов троттлить 443 в нулину нормально, а 853 трогать - фу?

[id_Alex]

я если честно удивлён что ркн не прогнул всех операторов в обящательном порядке заворачивать все запросы днс на их Национальную систему доменных имён (НСДИ)!

[nidalee]

Так они только начали.

[Doaxan]

Было бы здорово, если бы кто-то расписал наихудшие сценарии, чтобы не заниматься постоянной перенастройкой

[kenoma]

У вас не будет интернета.

[kukovik]

почему только у него? или это и есть как раз для него наихудший, когда у всех есть, а у него нет?