snvoronkov Опубликовано 2 февраля, 2017 · Жалоба Для HTTPS имя домена содержится в серверном сертификате. Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 2 февраля, 2017 · Жалоба И я точно не знаю, но наверное получение данных сертификата сервера происходит уже после инициации шифрования. В TLS младше 1.2 - точно не так. В TLS 1.3 верно для клиентского сертификата. Для серверного - вроде бы нет. И, кстати, это же нетривиально? Просто начинать шифрование не имеет смысла - неизвестно, кто именно нам отвечает, сервер или MitM, поэтому на то, что в сертификате надо сначала все-таки посмотреть. Как проблему решают? Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано. Если имя не совпадет, браузер завопит же? Как можно имя неправильно в сертификате указать и продолжать нормально работать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 февраля, 2017 · Жалоба И я точно не знаю, но наверное получение данных сертификата сервера происходит уже после инициации шифрования. Нельзя установить зашифрованное соединение неизвестно с кем. Поэтому серверный сертификат не шифруется (это и не требуется, он публичный) и домен из него получить можно всегда. Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано. Что угодно там написано быть не может, там либо имя конкретного домена (вернее большой список, в котором перечислен домен пользователя), либо wildcard, покрывающий домены пользователей. Во втором случае DPI должен блокировать домены не по точному соответствию, а по маске. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 2 февраля, 2017 · Жалоба Нельзя установить зашифрованное соединение неизвестно с кем. Можно, в принципе. Это защитит от всех, кто MitM не является, а просто на соединение смотрит. Но вот что дальше делать - непонятно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 2 февраля, 2017 · Жалоба Для крупных хостингов с дешманскими/бесплатными сертификатами там просто х/з чего понаписано. Если имя не совпадет, браузер завопит же? Как можно имя неправильно в сертификате указать и продолжать нормально работать? Сертификат может быть выписан на *.<DOMAIN> или на кучу имен (или и то и то одновременно) сертификат один. блочим или нет? Вообще то в SNI пока передается имя домена запрашиваемого от клиента к серверу, и уже по нему сервер выбирает сертификат. Но это должно уметься обоими сторонами. И в tls1.3 это обещали исправить (т.е. открытым текстом летаться оно не будет). Нельзя установить зашифрованное соединение неизвестно с кем. Можно, в принципе. Это защитит от всех, кто MitM не является, а просто на соединение смотрит. Но вот что дальше делать - непонятно. а дальше все так же как сейчас. от митма не защитит, но внутрь без митма вообще не посмотреть. Если после обмена ключами еще и перепроверить подпись первого (который сначала бы абы кто) что нам не пихнули тунель.... тога смитмив можно узнать на какой домен пытались пойти, но дальше все одно соединение обломится, без митма вообще ничего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 2 февраля, 2017 · Жалоба Вообще то в SNI пока передается имя домена запрашиваемого от клиента к серверу, и уже по нему сервер выбирает сертификат. Но это должно уметься обоими сторонами. И в tls1.3 это обещали исправить (т.е. открытым текстом летаться оно не будет). Вот я не понимаю, как это делается смотрим сюда. Ну ладно, серверный сертификат тут шифрованный (ServerHello), а вот как они нужный выбирают, без получения имени сервера в ClientHello от клиента - неясно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 2 февраля, 2017 · Жалоба Нельзя установить зашифрованное соединение неизвестно с кем. Можно. Для этого надо знать только ключи шифрования. После инициации шифрования получить полный сертификат и проверить с кем именно мы соединились и совпадает ли эти данные с ожидаемыми. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 февраля, 2017 · Жалоба Можно. Для этого надо знать только ключи шифрования. Тогда это уже будет не интернет. Если https-сайт может открыть любой пользователь, значит это может сделать и DPI. А если для открытия сайта нужно предварительно получить ключи (или клиентский сертификат), то это уже не публичный интернет-сайт, а закрытый ресурс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 2 февраля, 2017 · Жалоба Если https-сайт может открыть любой пользователь, значит это может сделать и DPI. Смысл в том, что можно попытаться сделать так, что DPI не узнает, какой именно сайт пользователь открывает. Мне это желание кажется понятным, полезным, но довольно напрасным - метаинформация о хотя бы одной стороне уж больно активно протекает везде где можно. А если для открытия сайта нужно предварительно получить ключи (или клиентский сертификат), то это уже не публичный интернет-сайт, а закрытый ресурс. Ну почему. Строим систему по распространению (namecoin?) большого-большого файла вида сайт->ключ. Который автоматически обновляется, скачивается (какой-нибудь P2P) и у всех одинаковый. Клиент в этот файл смотрит и пользуется. Все публично. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 2 февраля, 2017 · Жалоба Тогда это уже будет не интернет. Если https-сайт может открыть любой пользователь, значит это может сделать и DPI. Открыть свою сессию может, но заглянуть в чужую сессию - нет. Данные от клиента может расшифровать только сервер а данные для клиента - только клиент. Закрытые части ключей не передаются по каналу связи. Это специально разрабатывалось чтобы нельзя было подсмотреть имея дамп полного трафика. То что имя домена передается сейчас нешифрованным - это просто везение, благодаря которому можно еще хоть как-то дифференцировать и фильтровать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 2 февраля, 2017 · Жалоба Открыть свою сессию может, но заглянуть в чужую сессию - нет. Ну тут тоже есть над чем подумать. Можно отслеживать DNS-ответы для клиента, чтобы определить IP-адрес HTTPS-сайта, по которому клиент будет подключаться. Можно подключиться к серверу, получить с него серверный сертификат, проверить на наличие запрещенных доментов и блокировать при их наличии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 2 февраля, 2017 · Жалоба То что имя домена передается сейчас нешифрованным - это просто везение, благодаря которому можно еще хоть как-то дифференцировать и фильтровать. Если у нас на одном адресе несколько доменов, то нужно как-то говорить, какой домен хочется. Скорее всего, до начала шифрования. А если не хотим говорить - то тогда на одном адресе - один домен. Та же проблема - по адресу видно, к кому сайту цепляешься. Я же говорю - это информация так и так просачивается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 2 февраля, 2017 · Жалоба Если у нас на одном адресе несколько доменов, то нужно как-то говорить, какой домен хочется. Скорее всего, до начала шифрования. А если не хотим говорить - то тогда В TLS 1.2 - до шифрования (и то опционально) В TLS 1.3 - вроде как после шифрования В принципе никто не запрещает хостингу сгенерировать общий сертификат на все хостящиеся домены и после этого отключить TLS 1.2 И все, какой домен - не видно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Gilfanov Опубликовано 2 февраля, 2017 · Жалоба В TLS 1.3 - вроде как после шифрования Там выше обсуждение и ссылка на flowchart для TLS 1.3. Как и то, что я не понял, как там можно послать SNI шифрованным. В принципе никто не запрещает хостингу сгенерировать общий сертификат на все хостящиеся домены и после этого отключить TLS 1.2 И все, какой домен - не видно Ну, собственно, они так и пишут Только какой-то подозрительный это способ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bud_on Опубликовано 3 февраля, 2017 · Жалоба У меня вопрос - а этот Ревизор как-нибудь патчится автоматически, включая саму ОС или нет? У нас один из трёх ревизоров пропатчился... Сейчас куча незаблокированных ресурсов вылезла, в понедельник иду в РКН на составление протокола. Статистика остальных операторов по нулям. На сколько обновление было автоматическим не ясно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bud_on Опубликовано 3 февраля, 2017 · Жалоба А есть ли какой-нить DPI, который блокирует некашерную инфу так как того требует РЧЦ и РКН? Из вышенаписанного не понял вообще это в текущих условиях технически реализуемо? Или проблема https не решена на уровне оператора? Думаю, что в Надзоре вещать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 3 февраля, 2017 · Жалоба А есть ли какой-нить DPI, который блокирует некашерную инфу так как того требует РЧЦ и РКН? СКАТ, поставленный в разрыв и с байпассом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 3 февраля, 2017 · Жалоба А есть ли какой-нить DPI, который блокирует некашерную инфу так как того требует РЧЦ и РКН?А нет официальных требований, есть только "рекомендации" непонятной юридической силы, и алгоритм проверки в "ревизоре", который меняется когда левая пятка захочет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bud_on Опубликовано 3 февраля, 2017 · Жалоба СКАТ, поставленный в разрыв и с байпассом. Он https корректно разбирает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 3 февраля, 2017 · Жалоба СКАТ, поставленный в разрыв и с байпассом. Он 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. Косяки бывают (что видно из ченьджлога), но фиксятся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 февраля, 2017 · Жалоба он банит конктерный случай : В базе РКН http://www.youtube.com/*'>http://www.youtube.com/* урлы но https://www.youtube.com/* нег ниодного и в браузере откуда проверяем уже заходили на http://www.youtube.com/ чтобы браузер запомнил что http для youtube.com надо менять на https ? Да или нет ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 3 февраля, 2017 · Жалоба он банит конктерный случай : В базе РКН http://www.youtube.com/*'>http://www.youtube.com/* урлы но https://www.youtube.com/* нег ниодного и в браузере откуда проверяем уже заходили на http://www.youtube.com/ чтобы браузер запомнил что http для youtube.com надо менять на https ? Да или нет ? ХЗ. В понедельник могу проверить. Или кто-нибудь другой, у кого СКАТ стоит раньше это сделает. (Скорее всего, нет, не банит. Но руку на отсечение не дам и в отчетах ББ всегда ровный ноль.) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 февраля, 2017 · Жалоба Я так понимаю некоторых стали нагибать именно за этот (или подобный с другими доменами) кейс Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 3 февраля, 2017 · Жалоба В понедельник могу проверить. Я так понимаю некоторых стали нагибать именно за этот (или подобный с другими доменами) кейс А хрен-то там. Не проверю. Зашел через рабочий ПК. А у меня там IPv6 есть. И у Тытрубы есть. А СКАТ с IPv6 не работает. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 3 февраля, 2017 · Жалоба А если и у ревизора есть ? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...