Перейти к содержимому
Калькуляторы

Опубликована Процедура блокировки некошерной инфо

Для HTTPS имя домена содержится в серверном сертификате.

Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И я точно не знаю, но наверное получение данных сертификата сервера происходит уже после инициации шифрования.

В TLS младше 1.2 - точно не так. В TLS 1.3 верно для клиентского сертификата. Для серверного - вроде бы нет. И, кстати, это же нетривиально?

Просто начинать шифрование не имеет смысла - неизвестно, кто именно нам отвечает, сервер или MitM, поэтому на то, что в сертификате надо сначала все-таки посмотреть.

Как проблему решают?

 

Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано.

Если имя не совпадет, браузер завопит же? Как можно имя неправильно в сертификате указать и продолжать нормально работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И я точно не знаю, но наверное получение данных сертификата сервера происходит уже после инициации шифрования.

Нельзя установить зашифрованное соединение неизвестно с кем.

Поэтому серверный сертификат не шифруется (это и не требуется, он публичный) и домен из него получить можно всегда.

 

Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано.

Что угодно там написано быть не может, там либо имя конкретного домена (вернее большой список, в котором перечислен домен пользователя), либо wildcard, покрывающий домены пользователей.

Во втором случае DPI должен блокировать домены не по точному соответствию, а по маске.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нельзя установить зашифрованное соединение неизвестно с кем.

Можно, в принципе. Это защитит от всех, кто MitM не является, а просто на соединение смотрит. Но вот что дальше делать - непонятно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано.

Если имя не совпадет, браузер завопит же? Как можно имя неправильно в сертификате указать и продолжать нормально работать?

 

Сертификат может быть выписан на *.<DOMAIN> или на кучу имен (или и то и то одновременно)

 

сертификат один. блочим или нет?

 

Вообще то в SNI пока передается имя домена запрашиваемого от клиента к серверу, и уже по нему сервер выбирает сертификат. Но это должно уметься обоими сторонами. И в tls1.3 это обещали исправить (т.е. открытым текстом летаться оно не будет).

 

Нельзя установить зашифрованное соединение неизвестно с кем.

Можно, в принципе. Это защитит от всех, кто MitM не является, а просто на соединение смотрит. Но вот что дальше делать - непонятно.

а дальше все так же как сейчас. от митма не защитит, но внутрь без митма вообще не посмотреть. Если после обмена ключами еще и перепроверить подпись первого (который сначала бы абы кто) что нам не пихнули тунель.... тога смитмив можно узнать на какой домен пытались пойти, но дальше все одно соединение обломится, без митма вообще ничего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообще то в SNI пока передается имя домена запрашиваемого от клиента к серверу, и уже по нему сервер выбирает сертификат. Но это должно уметься обоими сторонами. И в tls1.3 это обещали исправить (т.е. открытым текстом летаться оно не будет).

Вот я не понимаю, как это делается смотрим сюда. Ну ладно, серверный сертификат тут шифрованный (ServerHello), а вот как они нужный выбирают, без получения имени сервера в ClientHello от клиента - неясно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нельзя установить зашифрованное соединение неизвестно с кем.

Можно. Для этого надо знать только ключи шифрования. После инициации шифрования получить полный сертификат и проверить с кем именно мы соединились и совпадает ли эти данные с ожидаемыми.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно. Для этого надо знать только ключи шифрования.

Тогда это уже будет не интернет.

Если https-сайт может открыть любой пользователь, значит это может сделать и DPI.

А если для открытия сайта нужно предварительно получить ключи (или клиентский сертификат), то это уже не публичный интернет-сайт, а закрытый ресурс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если https-сайт может открыть любой пользователь, значит это может сделать и DPI.

Смысл в том, что можно попытаться сделать так, что DPI не узнает, какой именно сайт пользователь открывает. Мне это желание кажется понятным, полезным, но довольно напрасным - метаинформация о хотя бы одной стороне уж больно активно протекает везде где можно.

 

А если для открытия сайта нужно предварительно получить ключи (или клиентский сертификат), то это уже не публичный интернет-сайт, а закрытый ресурс.

Ну почему. Строим систему по распространению (namecoin?) большого-большого файла вида сайт->ключ. Который автоматически обновляется, скачивается (какой-нибудь P2P) и у всех одинаковый. Клиент в этот файл смотрит и пользуется. Все публично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тогда это уже будет не интернет.

Если https-сайт может открыть любой пользователь, значит это может сделать и DPI.

Открыть свою сессию может, но заглянуть в чужую сессию - нет.

Данные от клиента может расшифровать только сервер а данные для клиента - только клиент. Закрытые части ключей не передаются по каналу связи.

 

Это специально разрабатывалось чтобы нельзя было подсмотреть имея дамп полного трафика.

То что имя домена передается сейчас нешифрованным - это просто везение, благодаря которому можно еще хоть как-то дифференцировать и фильтровать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Открыть свою сессию может, но заглянуть в чужую сессию - нет.

Ну тут тоже есть над чем подумать.

Можно отслеживать DNS-ответы для клиента, чтобы определить IP-адрес HTTPS-сайта, по которому клиент будет подключаться.

Можно подключиться к серверу, получить с него серверный сертификат, проверить на наличие запрещенных доментов и блокировать при их наличии.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

То что имя домена передается сейчас нешифрованным - это просто везение, благодаря которому можно еще хоть как-то дифференцировать и фильтровать.

Если у нас на одном адресе несколько доменов, то нужно как-то говорить, какой домен хочется. Скорее всего, до начала шифрования. А если не хотим говорить - то тогда

на одном адресе - один домен. Та же проблема - по адресу видно, к кому сайту цепляешься. Я же говорю - это информация так и так просачивается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если у нас на одном адресе несколько доменов, то нужно как-то говорить, какой домен хочется. Скорее всего, до начала шифрования. А если не хотим говорить - то тогда

В TLS 1.2 - до шифрования (и то опционально)

В TLS 1.3 - вроде как после шифрования

 

В принципе никто не запрещает хостингу сгенерировать общий сертификат на все хостящиеся домены и после этого отключить TLS 1.2

И все, какой домен - не видно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В TLS 1.3 - вроде как после шифрования

Там выше обсуждение и ссылка на flowchart для TLS 1.3. Как и то, что я не понял, как там можно послать SNI шифрованным.

 

В принципе никто не запрещает хостингу сгенерировать общий сертификат на все хостящиеся домены и после этого отключить TLS 1.2

И все, какой домен - не видно

Ну, собственно, они так и пишут Только какой-то подозрительный это способ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня вопрос - а этот Ревизор как-нибудь патчится автоматически, включая саму ОС или нет?

У нас один из трёх ревизоров пропатчился... Сейчас куча незаблокированных ресурсов вылезла, в понедельник иду в РКН на составление протокола. Статистика остальных операторов по нулям. На сколько обновление было автоматическим не ясно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А есть ли какой-нить DPI, который блокирует некашерную инфу так как того требует РЧЦ и РКН? Из вышенаписанного не понял вообще это в текущих условиях технически реализуемо? Или проблема https не решена на уровне оператора?

Думаю, что в Надзоре вещать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А есть ли какой-нить DPI, который блокирует некашерную инфу так как того требует РЧЦ и РКН?

СКАТ, поставленный в разрыв и с байпассом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А есть ли какой-нить DPI, который блокирует некашерную инфу так как того требует РЧЦ и РКН?
А нет официальных требований, есть только "рекомендации" непонятной юридической силы, и алгоритм проверки в "ревизоре", который меняется когда левая пятка захочет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

СКАТ, поставленный в разрыв и с байпассом.

Он https корректно разбирает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

СКАТ, поставленный в разрыв и с байпассом.

Он https корректно разбирает?

Вот из его changelog про HTTPS:

* Wed Feb  1 17:00:00 2017 VAS Experts <info@vasexperts.ru> 5.6.1 Katyusha
- Bug fix for MAC address swap in SNI block
* Wed Jan  4 17:00:00 2017 VAS Experts <info@vasexperts.ru> 5.5.1 Katyusha
- Small fix for black list check when SNI is absent
* Wed Dec 28 17:00:00 2016 VAS Experts <info@vasexperts.ru> 5.5 Katyusha
- SNI improved recognition
* Tue Dec  6 17:00:00 2016 VAS Experts <info@vasexperts.ru> 5.4 Katyusha
- SNI and Full Cone fixes
* Tue Oct 11 17:00:00 2016 VAS Experts <info@vasexperts.ru> 5.3 Katyusha
- Support of SNI for HTTPS and QUIC
* Sun Aug 14 17:00:00 2016 VAS Experts <info@vasexperts.ru> 5.1 Katyusha
- Star prefixed domains in black and white lists
* Sun Aug 14 17:00:00 2016 VAS Experts <info@vasexperts.ru> 4.6 Leningrad 872
- Star prefixed domains in black and white lists
* Wed Mar 30 17:00:00 2016 VAS Experts <info@vasexperts.ru> 4.2 Leningrad 872
- Addition of match any CN whitelist
...

 

Из статистики по блокировке:

	ssl/lock=44179823/44913 ( 0,29032,0 )( 9,28745,28736,480000 )
		cna/lock=1259000/777 ( 0,28842 )
		sni/lock=42920823/44136 ( 0,190 )

	ccheck/ip_check/lock=2208147939/27795948/3880

 

Т.е., что касается HTTPS, то банит по IP/SNI/CNA. Косяки бывают (что видно из ченьджлога), но фиксятся.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

он банит конктерный случай : В базе РКН http://www.youtube.com/*'>http://www.youtube.com/* урлы но https://www.youtube.com/* нег ниодного и в браузере откуда проверяем уже заходили на http://www.youtube.com/ чтобы браузер запомнил что http для youtube.com надо менять на https

? Да или нет ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

он банит конктерный случай : В базе РКН http://www.youtube.com/*'>http://www.youtube.com/* урлы но https://www.youtube.com/* нег ниодного и в браузере откуда проверяем уже заходили на http://www.youtube.com/ чтобы браузер запомнил что http для youtube.com надо менять на https

? Да или нет ?

ХЗ. В понедельник могу проверить. Или кто-нибудь другой, у кого СКАТ стоит раньше это сделает.

(Скорее всего, нет, не банит. Но руку на отсечение не дам и в отчетах ББ всегда ровный ноль.)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я так понимаю некоторых стали нагибать именно за этот (или подобный с другими доменами) кейс

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В понедельник могу проверить.

Я так понимаю некоторых стали нагибать именно за этот (или подобный с другими доменами) кейс

А хрен-то там. Не проверю. Зашел через рабочий ПК. А у меня там IPv6 есть. И у Тытрубы есть. А СКАТ с IPv6 не работает. :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.