Комментарии 41
Теперь провайдерам рекомендуется осуществлять фильтрацию не по IP-адресам, а непосредственно по содержимому пакетов:
А как быть с шифрованным трафиком? Например https?
А вообще ждем замедления интернета в связи с нововведениями.
Предлагают блокировать фильтруя DNS запросы. Пользуйтесь DNSCrypt.
*тут могла быть картинка вида «shut up and take my money», но лень.*
SNI ввели как раз для того, чтобы сервер заранее знал, каким сертификатом ему ответить на clienthello. Поэтому зашифровать SNI пока что не получится. Думаю, если распространится DNS TLSA как технология, можно будет шифровать запрос clienthello публичным ключом сервера, выложенным в TLSA, а хинт серверу передавать, скажем, соленым хэшем этого же ключа (ну или ещё как-нибудь, чтобы сервер без расшифровки запроса мог определить, каким именно ключом он зашифрован, и не сильно-то палить в запросе, что это за запрос, к какому он сайту). Но да, это ИМХО дело для TLS1.3, а скорее для TLS2.0.
Client Gateway Hidden
ClientHello#1
+ KeyShare
+ EarlyDataIndication
+ SNI = gateway
(Finished)
(
ClientHello#2
+ KeyShare
+ SNI = hidden
<Finished> //
)
(end_of_early_data alert) ---->
ClientHello#2
+ KeyShare
+ SNI = hidden
<Finished> ---->
ServerHello
+ KeyShare
{EncryptedExtensions}
{ServerConfiguration*}
{Certificate*}
{CertificateRequest*}
{CertificateVerify*}
<------------------------------- {Finished}
{Finished} ------------------------------->
Key to brackets:
() encrypted with Client->Gateway 0-RTT key (either handshake or data)
<> encrypted with Client->Hidden 0-RTT key
{} encrypted with Client->Hidden 1-RTT handshakeБудут блокировать гейты в таком варианте исполнения. Также гейт может быть подменен MitM-провайдером на DPI, оттуда скушан SNI и в случае разрешенного трафика отдан ответ типа required secure renegotiation (вроде бы в ServerHello можно такой отдать), с перенастройкой маршрутизации для клиента, чтобы сессию не перехватывать. Иначе дропать или отдавать страницу блокировки.
фильтруя DNS
То есть по IP можно будет подключаться?
Осталось узнать, кто выдаст провайдерам деньги на DPI?
Сенаторы предложили приравнять зарубежные русскоязычные СМИ к иностранным агентам и блокировать их в Россииhttps://meduza.io/news/2017/06/28/senatory-predlozhili-priravnyat-zarubezhnye-russkoyazychnye-smi-k-inostrannym-agentam-i-blokirovat-ih-v-rossii
Картина мира (ру.нут-а) видится мрачной...
- хана всем иностранным менеджерам.
- наши менеджеры из-за границы тоже закроем (ибо много общаемся с иностранными шпионами).
- хана VPN-ам (только по разрешению, как раньше было с мобильными телефонами).
- хана https с иностранными сертификатами
- хана шифрованной почте с ЭЦП, выданными иностранными центрами
- хана TOR-у
- хана DNSSEC
- весь трафик через ЦЕНТР "обработки данных"
- пакеты всех пользователей пронумеровать и промаркировать и чтобы размером от 500 до 1000 байт(чтобы не задидосили ЦЕНТР "обработки данных"...
В случае, если провайдер получает уже отфильтрованный трафик от вышестоящего оператора, то ему не грозит привлечение к ответственности за неосуществление блокировки противоправной информации, как предусмотрено законодательством. В этом случае решения о наложении штрафов «будут приниматься с учетом условий договоров, заключённых между такими операторами связи».
так в чем проблема: создаешь «дочку» (или не дочку) которая получает отфильтрованный трафик. Но затем она его «расфильтровывает» (пускает через vpn, dnscrypt, etc). Ну а в договоре прописать все как удобно и торговать только услугами «дочки».
Не?
Вчера обнаружил, что из дома перестал работать habrahabr и geektimes.ru потому, что адреса попали в "списки" из-за того, что их внесли в DNS.
$ dig 1520x520s.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> 1520x520s.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8474
;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL:
1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1520x520s.com. IN A
;; ANSWER SECTION:
1520x520s.com. 3600 IN A 31.13.92.36
1520x520s.com. 3600 IN A 91.228.155.94
1520x520s.com. 3600 IN A 100.0.5.6
1520x520s.com. 3600 IN A 87.240.165.80
1520x520s.com. 3600 IN A 192.30.253.112
1520x520s.com. 3600 IN A 178.248.237.68
1520x520s.com. 3600 IN A 95.213.11.181
1520x520s.com. 3600 IN A 134.168.39.186
1520x520s.com. 3600 IN A 104.20.208.21
1520x520s.com. 3600 IN A 116.116.116.117
1520x520s.com. 3600 IN A 104.20.209.21
1520x520s.com. 3600 IN A 100.2.9.44
1520x520s.com. 3600 IN A 185.60.216.35
1520x520s.com. 3600 IN A 134.168.42.58
1520x520s.com. 3600 IN A 192.30.253.113
;; Query time: 89 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Thu Jun 29 08:09:31 MSK 2017
;; MSG SIZE rcvd: 282
Я спросил могут ли они внести habr и geek в "белый список" и смотрят ли они на SNI в TLS-е.
Ответ провайдера звучит вот так:
Мы не имеем права вносить любые поправки, если нет официального письма от РКН. В ином случае, это будет самоуправством. АС Ревизор, который обязывают ставить на стороне ВСЕХ провайдеров, непрерывно проходится по списку блокировок, и если в какой-то момент всплывет доступ к запрещенному сайту, на нас тут же настучат и последует наказание в виде приличного штрафа.
В текущей реализации нет dpi.
Итог в том, что всем провайдерам придется ставить DPI, а платить за него придется абонентам.
Два раза прочитал рекомендации и не понял на какой пункт ткнуть пальцем своему провайдеру.
К сожалению скопировать текст не получается.
В "выгрузке" РКН есть только заблокированный домен 1520x520s.com без указания IP адресов. Провайдер резолвит и блочит. Как применить последнее предложение п. 9.1 к данной ситуации?
«Роскомнадзор» рекомендует фильтровать трафик с помощью DPI