вранье?
От Alexey Vissarionov (2:5020/545) к Serguei E. Leontiev
В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)
Доброго времени суток, Serguei!
02 Dec 2014 19:27:20, ты -> мне:
??>>>> 1. Провайдер должен предоставлять трубу и никак не вмешиваться
??>>>> в трафик абонента.
SL>>> "должен" в данном контексте это юридический термин или некое
SL>>> "понятие"? Оно требует пояснения.
SL>>> В любом случае, https прокси, как любой другой прокси или
SL>>> NAT, это не совсем уж прямо так: "вмешательство в трафик",
SL>>> наверное, если строго, это обработка запроса абонента.
AV>> Какого такого запроса? Услуга называется "передача данных".
SL> Запроса на передачу данных.
На сетевом уровне нет никаких запросов. Задача оператора услуг передачи данных предельно проста: получили пакет от пользователя наружу - отправили по адресу назначения, получили пакет снаружи для пользователя - отправили пользователю. Теоретически, они даже NAT использовать не могут (хотя на это все уже давно и качественно забили болт).
То есть, если типовой "хомячок" (от "home user") посылает пакет куда-то наружу, ответ он должен получить именно от целевого хоста. Единственное исключение - ответ транзитного маршрутизатора о невозможности доставки пакета c диагностикой наподобие ICMP_DEST_UNREACH или там ICMP_TIME_EXCEEDED).
??>>>> 2. Трафик шифруется как раз для того, чтобы никто не мог
??>>>> влезть в него и что-то подменить, либо вытащить пароли.
SL>>> Это требование, я склонен полагать, обеспечивается, как на
SL>>> юридическом, так и на техническом уровне.
AV>> Hикак оно не обеспечивается... любой УЦ по запросу "органов"
AV>> выпустит левый сертификат для любого домена. В полном
AV>> соответствии с законом, ага.
SL> Ой, всякое конечно бывает, но ИМХО вряд ли они будут возиться,
SL> рассекречивать потребное им имя сервера и идентификаторы клиента,
SL> им проще
... выпустить wildcard certificate для каждого TLD - *.com, *.net, *.ru итд.
SL> так взломать и прочитать трафик без всей этой мышиной возни.
Так взломать - это как?
SL> Вот умная фильтрация по требованию Роскомнадзора, это да.
А для этого и внутрь HTTPS лезть не нужно - SNI в открытом виде передается. Кстати, я в свое время уже описывал в RU.FTN.DEVELOP, как можно реализовать одновременную работу нескольких HTTPS-сайтов на одном хосте и порте:
==== хрум ====
C: OPTIONS * HTTP/1.0
C: Connection: Keep-Alive
C: Hash-Algo: SHA256, SHA512, GOST3411
S: HTTP/1.1 200 OK
S: Content-Length: 0
S: Keep-Alive: timeout=5, max=100
S: Connection: Keep-Alive
S: Server-Hash-Salt: SHA256:ToEIYRTu8zMlBh1pEvoIgJj6EECGtviYqaMftqGHr3g
C: OPTIONS * HTTP/1.0
C: Connection: Keep-Alive
C: Server-Hash: SHA256:LX9CQHP8kt37Xxi+1KLzNEuyvtwUJdKF6qebcqA8Cc8
А дальше UPGRADE и работаем как обычно.
В чем смысл обмена значениями Server-Hash-Salt и Server-Hash: клиент вычисляет
(по указанному сервером алгоритму из Hash-Algo) хеш имени нужного ему сервера,
XORит его с Server-Hash-Salt, вычисляет хеш результата и сообщает окончательный
результат серверу, а сервер, в свою очередь, вычисляет аналогичные хеши (с тем
же Server-Hash-Salt) для всех своих виртуальных хостов и, сравнивая их с хешом,
вычисленным клиентом, определяет, с каким хостом хочет работать клиент.
Недостаток у данного метода ровно один: каждое соединение требует вычисления
кучки хешей на сервере. Разумеется, первые хеши (непосредственно для имен)
вычисляются заранее и хранятся в памяти, но "соленые" считать все же придется.
==== тьфу ====
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii
... У дураков мысли монотонны и ограничены
--- /bin/vi
* Origin: http://openwall.com/Owl/ru (2:5020/545)
Ответы на это письмо:
From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку
From: Username
Или коротким