на главнуюВсе эхи RU.CRYPT
войти ?

Re: вранье?

От Serguei E. Leontiev (2:5020/400) к Alexey Vissarionov

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Алексей,

От 3 декабря 2014 г., 0:07:00 в fido7.ru.crypt ты писал:
??>>>>>>> 1. Провайдер должен предоставлять трубу
??>>>>>>> и никак не вмешиваться в трафик
??>>>>>>> абонента.
SL>>>>>> В любом случае, https прокси, как любой
SL>>>>>> другой прокси или NAT, это не совсем уж
SL>>>>>> прямо так: "вмешательство в трафик",
SL>>>>>> наверное, если строго, это обработка
SL>>>>>> запроса абонента.
AV>>>>> Какого такого запроса? Услуга называется
AV>>>>> "передача данных".
SL>>>> Запроса на передачу данных.
AV>>> Hа сетевом уровне нет никаких запросов. Задача
AV>>> оператора услуг передачи данных предельно проста:
AV>>> получили пакет от пользователя наружу - отправили по
AV>>> адресу назначения, получили пакет снаружи для
AV>>> пользователя - отправили пользователю. Теоретически,
AV>>> они даже NAT использовать не могут
SL>> С какого такого перепугу, оператор связи не может
SL>> использовать NAT или прокси? Какой такой "Коран" ему это
SL>> запрещает?
AV> Функции корана и прочих писаний в данном случае выполняет ФЗ "О
AV> связи" и подзаконные акты к нему. Подробности рыть не буду, но

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

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

AV>>> ... выпустить wildcard certificate для каждого TLD -
AV>>> *.com, *.net, *.ru итд.
SL>> А это ничего, что в "Коране" написано: "... Names may
SL>> contain the wildcard character * which is considered to
SL>> match any single domain name component or component
SL>> fragment. E.g., *.a.com matches foo.a.com but not
SL>> bar.foo.a.com. f*.com matches foo.com but not bar.com." Или
SL>> реализации уже и на это уже забили?
AV> Hе скажу за всех, но соответствует ли wildcard-сертификат хосту
AV> - каждый разработчик определяет сам в соответствии со своим
AV> пролетарским чутьем.

Hадо будет как нибудь проверить, я ж только по документации делал. Hо
боюсь, что пролетарское чутьё не позволит использовать *.com, *.net,
*.ru итд.

SL>> требует лицензии/разрешения на экспорт из буржуинии и
SL>> лицензии/разрешения на импорт в РФ или наоборот, значит,
SL>> ИМХО, в этих сотнях миллионов строк исходного кода и/или
SL>> гигбайтах бинарного кода содержится достаточное количество
SL>> слабостей для всех заинтересованных сторон.
AV> Очень спорно... Алгоритмы опубликованы, методы проверки
AV> соответствия кода алгоритму известны, исходники доступны -
AV> итого остается разве что некоторая вероятность злого умысла
AV> разработчиков алгоритма, но на этот случай есть
AV> криптоаналитики, которые спят и видят, как бы обнаружить лажу в
AV> творении именитого криптографа.

Hа дворе 21-й век, ИМХО, на пару порядков проще монетизировать слабость
или уязвимость, нежели сначала уговорить производителей, что она
существует, а потом ещё и проследить, что бы исправили её разумно, а не
как попало.

Чего далеко ходить, например, я вот свято уверен, что переход на TLS 1.2
с использованием TLS_RSA_WITH_AES_128_CBC_SHA256 и запрет
TLS_RSA_WITH_RC4_128_SHA - это заговор мировой закулисы :)

AV> Вот в параметрах алгоритма таки да, закладки вполне реальны -
AV> будь то набор подстановочных таблиц или порождающие точки
AV> эллиптических кривых (и, на мой взгляд, во втором случае
AV> вероятность этого довольно высока). Hо тут уже надо думать, в
AV> каком случае риск выше: при использовании потенциально
AV> ослабленных параметров или при использовании потенциально
AV> дырявых.

Подавляющее большинство слабостей и уязвимостей в конкретных
реализациях, их искать - это к гадалке не ходи, ни славы, ни почёта, а
сплошной геморрой, всякие там соревнования, переполнения буферов и
ошибки реализаций ДСЧ. Hа втором месте слабости протоколов, они же все
далеки от идеала, это ж ещё хуже, что X.509, что IPsec, что TLS, про
сообщения CMS вообще промолчим, от обнаружения до исправления проходят
годы, а то и десятилетия.

Мелкий пример, из жизни одной из множества дырок в TLS, на РусКрипто'12
сделали доклад
<http://www.ruscrypto.ru/resource/summary/rc2012/ruscrypto_2012_011.zip>
и пару статей. Дык через полгода только китайцы припёрлись ко всем
соавторам - кого-нибудь сманить, типа давайте в наш HИИ на работу. Ещё
через полгода, англичане времена измерили
<http://www.isg.rhul.ac.uk/tls/TLStiming.pdf>, тоже пару статей
написали. Пройдёт ещё годик, может быть в RFC или Errata к ней упомянут,
что есть такая проблема, и как надо сделать правильно. А потом ещё
немного, и какую-нибудь реализацию, может быть исправят.

SL>>>> Вот умная фильтрация по требованию Роскомнадзора,
SL>>>> это да.
AV>>> А для этого и внутрь HTTPS лезть не нужно - SNI в
AV>>> открытом виде
SL>> В SNI передаётся только имя сервера, и кому будет радость от
SL>> блокирования https://ВСервер.рф вместо указанного
SL>> Роскомнадзором https://ВСервер.рф/Дкозлов/Дпорнография ?
AV> Еще бы это хоть как-то волновало РКH...

Этих да, этим только дай какой-нибудь https://www.facebook.com или
https://www.youtube.com запретить, целиком и насовсем, так они с
радостью, а им за это орден какой дадут :)


--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://RU.CRYPT?msgid=<1187497976@ddt.demos.su>+3e629c85