вранье?

[Sergey Zabolotny]

Hello *All.*

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

правда это или таки сабж?

[Vitaly Zaitsev]

Здpавствуй, Sergey!

Четверг 27 Hоября 2014 15:04, ты писал(а) All:

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

Смотря какие алгоритмы используются. А вскрыть HTTPS как нечего делать -
банальная MITM атака. Как показывает практика провайдеров, большинство хомячков
бездумно принимают палёный сертификат.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Vitaly,

27 Nov 14 19:38, you wrote to Sergey Zabolotny:

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

VZ> Смотря какие алгоритмы используются. А вскрыть HTTPS как нечего делать
VZ> - банальная MITM атака. Как показывает практика провайдеров,
VZ> большинство хомячков бездумно принимают палёный сертификат.

Да, неоднократно наблюдал, как люди кликают "Всё равно продолжить" на сообщение
о недействительном сертификате. Ростелеком в частности приучает к этому:
http://runog.spb.ru/pipermail/runog/2014-May/000500.html

Еще можно вспомнить распространенную корпоративную практику перехвата HTTPS
трафика сотрудников на HTTP прокси (так называемый SSL bump).

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Ivan Novikov]

Привет, Victor!

28 Nov 14, Victor Sudakov накропал письмо к Vitaly Zaitsev:

[хрумх]

VS> Да, неоднократно наблюдал, как люди кликают "Всё равно продолжить" на
VS> сообщение о недействительном сертификате.

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

VS> Ростелеком в частности приучает к этому:
VS> http://runog.spb.ru/pipermail/runog/2014-May/000500.html
а причём тут ростелеком?
https://victor-sudakov.dreamwidth.org/
Warning! The server's certifiate chain is incomplete, and the signer(s) are not
registered. Accept?
Server name victor-sudakov.dreamwidth.org
Certificate errors:
The certificate for "*.dreamwidth.org" is signed by the unknown Certificate
Authority "*.dreamwidth.org". It is not possible to verify than this is a valid
certificate.

и что прикажешь делать?

не так давно при открытии youtube шла ругань на неизвестное authority
"google.com"
ясен пень, что все на это забивали.


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Пятница 28 Hоября 2014 19:15, ты писал(а) Victor Sudakov:

IN> так что из вариантов не посмотреть сайт или забить на какой-то там
IN> сертификат, выбирается однозначно второй.

Подключаться посредством VPN к хосту, расположенному в нормальной стране.

IN> и что прикажешь делать?

Использовать VPN.

IN> не так давно при открытии youtube шла ругань на неизвестное authority
IN> "google.com" ясен пень, что все на это забивали.

Какой провайдер? У вас, в ЕКБ, некоторые провайдеры (например Convex) нагло
подменяют сертификаты Google, подсовывая левый для google.com, с CA google.com,
который они сами и создали. У самого гугла давно свой CA, который в доверенных
уже много лет.

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

28 Nov 14, Vitaly Zaitsev накропал письмо к Ivan Novikov:

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

IN>> и что прикажешь делать?
VZ> Использовать VPN.
угу. и всю контору туда завернуть.

IN>> не так давно при открытии youtube шла ругань на неизвестное authority
IN>> "google.com" ясен пень, что все на это забивали.
VZ>
VZ> Какой провайдер? У вас, в ЕКБ, некоторые провайдеры (например Convex)
кстати, да.
дома не конвекс, но тоже ругалость в то же время. где-то это недели две назад
было, или три.

VZ> нагло подменяют сертификаты Google, подсовывая левый для google.com, с
VZ> CA google.com, который они сами и создали. У самого гугла давно свой
VZ> CA,

оно писало, да, мол, гугл.ком, только мы его проверить не можем никак.

VZ> который в доверенных уже много лет.
хм, у меня в опере нету, например. и в штатном виндовом хранилище тоже нет.


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Понедельник 01 Декабря 2014 20:26, ты писал(а) мне:

VZ>> Подключаться посредством VPN к хосту, расположенному в нормальной
VZ>> стране.
IN> ага. щас. уже бегу.

ССЗБ если готов терпеть MITM.

VZ>> Использовать VPN.
IN> угу. и всю контору туда завернуть.

Для юридических лиц обычно нет никакой фильтрации.

VZ>> нагло подменяют сертификаты Google, подсовывая левый для
VZ>> google.com, с CA google.com, который они сами и создали. У самого
VZ>> гугла давно свой CA,
IN> оно писало, да, мол, гугл.ком, только мы его проверить не можем никак.

Это поддельный самопальный сертификат.

VZ>> который в доверенных уже много лет.
IN> хм, у меня в опере нету, например. и в штатном виндовом хранилище тоже
IN> нет.

Hастоящий сертификат был выдан GeoTrust Global CA. Вот он (выкачал только что):
https://www.easycoding.org/files/google_original.crt

Сертификат вилдкардовый на *.google.com с расширением на кучу региональных.

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

02 Dec 14, Vitaly Zaitsev накропал письмо к Ivan Novikov:

VZ> Для юридических лиц обычно нет никакой фильтрации.

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


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Среда 03 Декабря 2014 19:48, ты писал(а) мне:

VZ>> Для юридических лиц обычно нет никакой фильтрации.
IN> фильтрация по списку имени роскомнадзора обязана быть везде
IN> провайдеры пытаются выполнять, ибо невыполнять им черевато анальными
IN> карами.

Ради теста брал VPS у российского хостера, поднимал там OpenVPN и пробовал
зайти на сайты из реестра - всё замечательно, никаких блокировок.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Ivan,

28 Nov 14 19:15, you wrote to me:

VS>> Да, неоднократно наблюдал, как люди кликают "Всё равно
VS>> продолжить" на сообщение о недействительном сертификате.

IN> дык, всё правильно. других-то действий не предлагается.
IN> так что из вариантов не посмотреть сайт или забить на какой-то там
IN> сертификат, выбирается однозначно второй.

А какое действие тут можно предложить? Пользователю говорят "туда не ходи, снег
башка упадет", а он идет. За руки хватать?

VS>> Ростелеком в частности приучает к этому:
VS>> http://runog.spb.ru/pipermail/runog/2014-May/000500.html
IN> а причём тут ростелеком?
IN> https://victor-sudakov.dreamwidth.org/
IN> Warning! The server's certifiate chain is incomplete, and the
IN> signer(s) are not registered. Accept? Server name
IN> victor-sudakov.dreamwidth.org Certificate errors: The certificate for
IN> "*.dreamwidth.org" is signed by the unknown Certificate Authority
IN> "*.dreamwidth.org". It is not possible to verify than this is a valid
IN> certificate.

Не знаю что тебе и сказать. Настоящий *.dreamwidth.org подписан УЦ GeoTrust,
Inc. У меня в FireFox этот УЦ есть.

IN> и что прикажешь делать?

Срочно выяснять, кто тебе подсовывает левый сертификат на *.dreamwidth.org,
подписанный кем-то неизвестным.

IN> не так давно при открытии youtube шла ругань на неизвестное authority
IN> "google.com" ясен пень, что все на это забивали.

Это наверное одни и те же парни тебе суют и левый google, и левый dreamwidth.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Vitaly Zaitsev]

Здpавствуй, Victor!

Суббота 29 Hоября 2014 11:07, ты писал(а) Ivan Novikov:

IN>> for "*.dreamwidth.org" is signed by the unknown Certificate
IN>> Authority "*.dreamwidth.org". It is not possible to verify than
IN>> this is a valid certificate.
VS> Срочно выяснять, кто тебе подсовывает левый сертификат на
VS> *.dreamwidth.org, подписанный кем-то неизвестным.

Его провайдер. Hа провайдеры из ЕКБ куча жалоб на MITM. Самый отличившийся в
этом - Convex. Они подменяют сертификаты даже на главной Google, которой никак
не может быть в реестре.

IN>> не так давно при открытии youtube шла ругань на неизвестное
IN>> authority "google.com" ясен пень, что все на это забивали.
VS> Это наверное одни и те же парни тебе суют и левый google, и левый
VS> dreamwidth.

http://forum.convex.ru/showthread.php?t=75635

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

30 Nov 14, Vitaly Zaitsev накропал письмо к Victor Sudakov:

VZ> http://forum.convex.ru/showthread.php?t=75635

а вот это уже кое что
спасибо за ссылку, будем разбираться.


С приветом, Ivan.

[Serguei E. Leontiev]

Виталий, привет,

Post by Vitaly Zaitsev

Post by Victor Sudakov
Это наверное одни и те же парни тебе суют и левый google, и левый
dreamwidth.

http://forum.convex.ru/showthread.php?t=75635

Лиха беда начало, постепенно научатся.

[Ivan Novikov]

Привет, Serguei!

Post by Vitaly Zaitsev

Post by Victor Sudakov
Это наверное одни и те же парни тебе суют и левый google, и левый
dreamwidth.

http://forum.convex.ru/showthread.php?t=75635

SEL>
SEL> Лиха беда начало, постепенно научатся.

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

как-то мне это всё равно не нравится...


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Вторник 02 Декабря 2014 18:28, ты писал(а) Serguei E. Leontiev:

IN> провайдер сознался, что они ставят гугловый кэш

Что за кэш?

IN> и какой-то очередной вариант сорма.

СОРМ предназначен для других целей. Здесь же банальная цензура роскомцензуры и
их идиотские запреты.

IN> как-то мне это всё равно не нравится...

Смени провайдера, либо используй VPN.

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

03 Dec 14, Vitaly Zaitsev накропал письмо к Ivan Novikov:

IN>> провайдер сознался, что они ставят гугловый кэш
VZ> Что за кэш?
гугл выдаёт сервера, которые кэшируют популярные ролики в ютубе, чем разгружают
свои основные сервера и внешний канал провайдеру.

IN>> и какой-то очередной вариант сорма.
VZ>
VZ> СОРМ предназначен для других целей.
а методы те же - перехват требуемого траффика. в данном случае - httpsного

IN>> как-то мне это всё равно не нравится...
VZ>
VZ> Смени провайдера, либо используй VPN.

рано или поздно и остальных провайдеров заставят сделать подобное безобразие


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Пятница 05 Декабря 2014 20:11, ты писал(а) мне:

VZ>> Что за кэш?
IN> гугл выдаёт сервера, которые кэшируют популярные ролики в ютубе, чем
IN> разгружают свои основные сервера и внешний канал провайдеру.

MITM главной гугла и Gmail они тоже называют "кэшированием".

VZ>> СОРМ предназначен для других целей.
IN> а методы те же - перехват требуемого траффика. в данном случае -
IN> httpsного

СОРМ всего лишь зеркалит весь трафик на железку, предоставленную ФСБ. MITM они
не осуществляют (по крайней мере пока).

VZ>> Смени провайдера, либо используй VPN.
IN> рано или поздно и остальных провайдеров заставят сделать подобное
IN> безобразие

Hормальные блокируют HTTPS строго по IP. В VPN влезть им вообще не удастся.

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

07 Dec 14, Vitaly Zaitsev накропал письмо к Ivan Novikov:

VZ>>> Что за кэш?
IN>> гугл выдаёт сервера, которые кэшируют популярные ролики в ютубе, чем
IN>> разгружают свои основные сервера и внешний канал провайдеру.
VZ> MITM главной гугла и Gmail они тоже называют "кэшированием".
ну, в собирании поисковых запросов и почты тоже есть своя вигода.

VZ>>> СОРМ предназначен для других целей.
IN>> а методы те же - перехват требуемого траффика. в данном случае -
IN>> httpsного
VZ>
VZ> СОРМ всего лишь зеркалит весь трафик на железку, предоставленную ФСБ. MITM
VZ> они не осуществляют (по крайней мере пока).
а может уже?

IN>> рано или поздно и остальных провайдеров заставят сделать подобное
IN>> безобразие
VZ> Hормальные блокируют HTTPS строго по IP.
роскомнадзор предписывает по URL


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Понедельник 08 Декабря 2014 19:25, ты писал(а) мне:

VZ>> СОРМ всего лишь зеркалит весь трафик на железку, предоставленную
VZ>> ФСБ. MITM они не осуществляют (по крайней мере пока).
IN> а может уже?

Hет.

VZ>> Hормальные блокируют HTTPS строго по IP.
IN> роскомнадзор предписывает по URL

Иногда вносят в реестр и IP.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Ivan,

05 Dec 14 20:11, you wrote to Vitaly Zaitsev:
VZ>>
VZ>> СОРМ предназначен для других целей.
IN> а методы те же - перехват требуемого траффика. в данном случае -
IN> httpsного

Нет. СОРМ не занимается перехватом трафика. По крайней мере в его нынешнем виде
он просто не в состоянии сделать это в том виде, как это делает АНБ:

http://victor-sudakov.livejournal.com/178491.html

Российский СОРМ просто осуществляет пассивный съем трафика, который ему
оператор отдает через порт-монитор или вот такие съемники:

http://victor-sudakov.livejournal.com/172154.html

"Впрыснуть" свои пакеты через это комплекс СОРМ не может.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alexey Vissarionov]

Доброго времени суток, Victor!
08 Dec 2014 09:03:44, ты -> Ivan Novikov:

VZ>>> СОРМ предназначен для других целей.
IN>> а методы те же - перехват требуемого траффика. в данном случае -
IN>> httpsного
VS> Нет. СОРМ не занимается перехватом трафика. По крайней мере в его
VS> нынешнем виде он просто не в состоянии сделать это в том виде, как
VS> это делает АНБ
VS> Российский СОРМ просто осуществляет пассивный съем трафика, который
VS> ему оператор отдает
VS> "Впрыснуть" свои пакеты через это комплекс СОРМ не может.

Им это в большинстве случаев и не нужно: в отличие от своих заокеанских
"коллег", наши "органы" в основе своей деятельности держат человеческую
деятельность, а не технические средства.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... Рожденный ползать, уйдите со взлетной полосы!

[Victor Sudakov]

Dear Alexey,

08 Dec 14 10:00, you wrote to me:
VZ>>>> СОРМ предназначен для других целей.
IN>>> а методы те же - перехват требуемого траффика. в данном случае -
IN>>> httpsного
VS>> Нет. СОРМ не занимается перехватом трафика. По крайней мере в его
VS>> нынешнем виде он просто не в состоянии сделать это в том виде,
VS>> как это делает АНБ Российский СОРМ просто осуществляет пассивный
VS>> съем трафика, который ему оператор отдает "Впрыснуть" свои пакеты
VS>> через это комплекс СОРМ не может.

AV> Им это в большинстве случаев и не нужно: в отличие от своих
AV> заокеанских "коллег", наши "органы" в основе своей деятельности держат
AV> человеческую деятельность, а не технические средства.

Однако же именно им принадлежит мудрость "Чтобы следить за всем населением
СССР, придется нанять всё население Китая". А технические средства облегчают
массовую слежку.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Ivan Novikov]

Привет, Victor!

29 Nov 14, Victor Sudakov накропал письмо к Ivan Novikov:
VS>>> Да, неоднократно наблюдал, как люди кликают "Всё равно
VS>>> продолжить" на сообщение о недействительном сертификате.
VS>
IN>> дык, всё правильно. других-то действий не предлагается.
IN>> так что из вариантов не посмотреть сайт или забить на какой-то там
IN>> сертификат, выбирается однозначно второй.
VS>
VS> А какое действие тут можно предложить? Пользователю говорят "туда не ходи,
VS> снег башка упадет",

нееее! пользователю говорят: "тут сертификат небезопасный, принять или нет?"
откуда ему знать какой такой сертификат-шметификат? ну, небезопасный и посрать.
надо чтоб было:
"сертификат небезопасный" и конкретное разъяснение почему - "выдан хрен знает
кем, утверждающим, что он ...(нужное вписать)"
"ежели вы будете его использовать, то все ваши данные, отправленные через этот
сайт, попадут к этому хрену".
причём сразу, а не как в ютубе - уже после загрузки, видимо, какой-то скрипт
куда-то лез и всплывало окно с предупреждением.
с другой стороны, юзер может подумать "а ну и хрен с ними, данными этими. я тут
котиков в яндексе ищу"

IN>> The certificate for "*.dreamwidth.org" is signed by the unknown
IN>> Certificate Authority "*.dreamwidth.org". It is not possible to
IN>> verify than this is a valid certificate.
VS>
VS> Не знаю что тебе и сказать. Настоящий *.dreamwidth.org подписан УЦ
VS> GeoTrust, Inc. У меня в FireFox этот УЦ есть.
ну вот две буржуазные чекалки выдают одинаковое:

Common name: *.dreamwidth.org
SANs: *.dreamwidth.org, dreamwidth.org
Valid from April 7, 2014 to May 9, 2016
Serial Number: 1165242 (0x11c7ba)
Signature Algorithm: sha1WithRSAEncryption
Issuer: RapidSSL CA

Common name: GeoTrust Global CA
Organization: GeoTrust Inc.
Location: US
Valid from May 20, 2002 to August 20, 2018
Serial Number: 1227750 (0x12bbe6)
Signature Algorithm: sha1WithRSAEncryption
Issuer: Equifax

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

IN>> и что прикажешь делать?
VS>
VS> Срочно выяснять, кто тебе подсовывает левый сертификат на
VS> *.dreamwidth.org, подписанный кем-то неизвестным.

каким способом?


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Понедельник 01 Декабря 2014 20:31, ты писал(а) Victor Sudakov:

IN> нееее! пользователю говорят: "тут сертификат небезопасный, принять или
IN> нет?" откуда ему знать какой такой сертификат-шметификат? ну,
IN> небезопасный и посрать.

В следующих версиях браузера (Firefox 35+) кнопки принять уже не будет и это
замечательно. В случае MITM на популярные ресурсы из его базы данных браузер
просто закроет соединение.

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

Так написано же. Кнопка "Подробнее" объясняет почему сертификату нет доверия.

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

02 Dec 14, Vitaly Zaitsev накропал письмо к Ivan Novikov:

IN>> нееее! пользователю говорят: "тут сертификат небезопасный, принять
IN>> или нет?" откуда ему знать какой такой сертификат-шметификат? ну,
IN>> небезопасный и посрать.
VZ>
VZ> В следующих версиях браузера (Firefox 35+) кнопки принять уже не будет и
VZ> это замечательно.
жду с нетерпеньем
хоть вой со стороны юзеров поднимется. должны ж провайдеры как-то это разрулить
будут.

IN>> надо чтоб было: "сертификат небезопасный" и
IN>> конкретное разъяснение почему - "выдан хрен знает кем, утверждающим,
IN>> что он ...(нужное вписать)" "ежели вы будете его использовать, то все
IN>> ваши данные, отправленные через этот сайт, попадут к этому
IN>> хрену".
VZ>
VZ> Так написано же. Кнопка "Подробнее" объясняет почему сертификату нет
VZ> доверия.

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



С приветом, Ivan.

[Ivan Novikov]

Hello Victor.

29 Nov 14 11:07, you wrote to me:
IN>> https://victor-sudakov.dreamwidth.org/
IN>> Warning! The server's certifiate chain is incomplete, and the
IN>> signer(s) are not registered.
VS>
VS> Срочно выяснять, кто тебе подсовывает левый сертификат на
VS> *.dreamwidth.org, подписанный кем-то неизвестным.
чую - любимый провайдер
ибо вот с другого:
openssl s_client -connect victor-sudakov.dreamwidth.org:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
-+-
Certificate chain
0 s:/serialNumber=-cgFXl6i3N/zQxsgiCkBPQ6DbmJ8i3g//OU=GT89324387/OU=See
www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated -
RapidSSL(R)/CN=*.dreamwidth.org
i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
2 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA


а вот с нашего
openssl s_client -connect victor-sudakov.dreamwidth.org:443
CONNECTED(00000003)
depth=0 serialNumber = -cgFXl6i3N/zQxsgiCkBPQ6DbmJ8i3g/, OU = GT89324387, OU =
See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated -
RapidSSL(R), CN = *.dreamwidth.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 serialNumber = -cgFXl6i3N/zQxsgiCkBPQ6DbmJ8i3g/, OU = GT89324387, OU =
See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated -
RapidSSL(R), CN = *.dreamwidth.org
verify error:num=21:unable to verify the first certificate
verify return:1
-+-
Certificate chain
0 s:/serialNumber=-cgFXl6i3N/zQxsgiCkBPQ6DbmJ8i3g//OU=GT89324387/OU=See
www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated -
RapidSSL(R)/CN=*.dreamwidth.org
i:/serialNumber=-cgFXl6i3N/zQxsgiCkBPQ6DbmJ8i3g//OU=GT89324387/OU=See
www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated -
RapidSSL(R)/CN=*.dreamwidth.org

очень интересно, как это им удаётся


Ivan

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Понедельник 01 Декабря 2014 23:13, ты писал(а) Victor Sudakov:

IN> очень интересно, как это им удаётся

Гонят и http, и https через свой прокси (тот же самый squid).

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Vitaly!

02 Dec 14, Vitaly Zaitsev накропал письмо к Ivan Novikov:

IN>> очень интересно, как это им удаётся
VZ>
VZ> Гонят и http, и https через свой прокси (тот же самый squid).

тогда бы оно выдавало другой сертификат, а тут тот же, только поломанный.


С приветом, Ivan.

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Среда 03 Декабря 2014 19:54, ты писал(а) мне:

VZ>> Гонят и http, и https через свой прокси (тот же самый squid).
IN> тогда бы оно выдавало другой сертификат, а тут тот же, только
IN> поломанный.

Так оно и выдаёт их поддельный сертификат.

С уважением, Vitaly (***@easycoding.org)

[Sergey Kusnetsov]

Hello Ivan,

Mon, 01 Dec 2014 23:13:38, you wrote to Victor Sudakov:

IN> чую - любимый провайдер

"эр-телеком" прямо сейчас в ответ на github.com выдаёт ip 92.255.241.100 что
соответствует net241.255.92-100.holding.ertelecom.ru , а там:

========================= begin 8< =========================
openssl s_client -connect github.com:443
Loading 'screen' into random state - done
CONNECTED(0000012C)
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
AddTrust Externa
l CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
-+-
Certificate chain
0 s:/C=RU/postalCode=614000/ST=Permskij
Kraj/L=Perm/street=Gorod/street=Monastyrskaja Uli
ca, 15/O=CJSC ER-Telecom Holding/OU=IT/OU=Hosted by JSC Regional Network
Information Cente
r/OU=PremiumSSL Wildcard/CN=*.ertelecom.ru
i:/C=RU/O=JSC Regional Network Information Center/OU=IT/CN=RU-CENTER High
Assurance Ser
vices CA
1 s:/C=RU/O=JSC Regional Network Information Center/OU=IT/CN=RU-CENTER High
Assurance Ser
vices CA
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External
CA Root
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External
CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External
CA Root
-+-
Server certificate
-----BEGIN CERTIFICATE-----
MIIF7TCCBNWgAwIBAgIRAOSr859pyrL1hp0UgEu5EHswDQYJKoZIhvcNAQEFBQAw
ezELMAkGA1UEBhMCUlUxMDAuBgNVBAoTJ0pTQyBSZWdpb25hbCBOZXR3b3JrIElu
Zm9ybWF0aW9uIENlbnRlcjELMAkGA1UECxMCSVQxLTArBgNVBAMTJFJVLUNFTlRF
UiBIaWdoIEFzc3VyYW5jZSBTZXJ2aWNlcyBDQTAeFw0xMzA2MDcwMDAwMDBaFw0x
NTA2MDcyMzU5NTlaMIIBGTELMAkGA1UEBhMCUlUxDzANBgNVBBETBjYxNDAwMDEW
MBQGA1UECBMNUGVybXNraWogS3JhajENMAsGA1UEBxMEUGVybTEOMAwGA1UECRMF
R29yb2QxIDAeBgNVBAkTF01vbmFzdHlyc2thamEgVWxpY2EsIDE1MSAwHgYDVQQK
ExdDSlNDIEVSLVRlbGVjb20gSG9sZGluZzELMAkGA1UECxMCSVQxOjA4BgNVBAsT
MUhvc3RlZCBieSBKU0MgUmVnaW9uYWwgTmV0d29yayBJbmZvcm1hdGlvbiBDZW50
ZXIxHDAaBgNVBAsTE1ByZW1pdW1TU0wgV2lsZGNhcmQxFzAVBgNVBAMUDiouZXJ0
ZWxlY29tLnJ1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuIN4GFRW
uPCV7yOS9WBurbpstLCu2ynSNGVNMk0x5Xl/No6pjf9E9Nd4folF96ARR/3IGip0
bmVIcaAeDBxkV0jE3wyKIb9hHL/B0JbAi47it2rFZ9LTEq2g1GMGnl49mr4KYxoc
7cjk5aSFMp9M0UE13j6fS69uijTYgM4b1MyKJqJ2vGsgAsej2COWP6msaNyqJOkS
AtdJDLAGzNkvRmTxl3zSaY1GLOAM0FQuIMDFircsIJa0uRpFnTQwdTNEJc71kIxt
019eK/tWeI81BdUzMtQIAsrEaeam9yKkstajHyjgi5ViU5OnK8L+bEc4fAIh9vK9
qU41AmTfDyS3ZwIDAQABo4IByjCCAcYwHwYDVR0jBBgwFoAUUKA8udaix1Mj0CvJ
DvmhYWBHT24wHQYDVR0OBBYEFHtMeM07O5ZvSSFH2/OHWcm5PG76MA4GA1UdDwEB
/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjBLBgNVHSAERDBCMDYGCysGAQQBsjEBAgIQMCcwJQYIKwYBBQUHAgEWGWh0
dHBzOi8vY3BzLnVzZXJ0cnVzdC5jb20wCAYGZ4EMAQICME4GA1UdHwRHMEUwQ6BB
oD+GPWh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9SVS1DRU5URVJIaWdoQXNzdXJh
bmNlU2VydmljZXNDQS5jcmwwgYAGCCsGAQUFBwEBBHQwcjBJBggrBgEFBQcwAoY9
aHR0cDovL2NydC51c2VydHJ1c3QuY29tL1JVLUNFTlRFUkhpZ2hBc3N1cmFuY2VT
ZXJ2aWNlc0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0
LmNvbTAnBgNVHREEIDAegg4qLmVydGVsZWNvbS5ydYIMZXJ0ZWxlY29tLnJ1MA0G
CSqGSIb3DQEBBQUAA4IBAQBQcGjFyzbWacqM6sC232sw+omD21vR/VVe5WpD2MJl
TehMbn4Od7tyhpH/GX87mhL3pB6xvD6WEJdqpCgMCYPnFaEjGQ5j+93lKZ1SV+Fz
PVKCu2HefQoHEx8hlP3BnlU927+ObVk0QltO+euVMAeWtvjn8Zk9cpwZqGrWDUtK
XBVUpLmEjHwmQwvpe/+gfAg5CX9c6zfiaxS86MZjHqr0Qhj7X/ghPM8g0weJpUpo
n/U47GKQ2aBdpL2gfptoilWMOMZrCxYP+dF59syrhh3VPeKHrmcvX4K8ZJXtc2Og
U6DN5gDydZanKwbe2IbxWIIaWJx3u7G9hD6OreXOMt4u
-----END CERTIFICATE-----
subject=/C=RU/postalCode=614000/ST=Permskij
Kraj/L=Perm/street=Gorod/street=Monastyrskaja
Ulica, 15/O=CJSC ER-Telecom Holding/OU=IT/OU=Hosted by JSC Regional Network
Information Ce
nter/OU=PremiumSSL Wildcard/CN=*.ertelecom.ru
issuer=/C=RU/O=JSC Regional Network Information Center/OU=IT/CN=RU-CENTER High
Assurance S
ervices CA
-+-
========================== end 8< ==========================

Sincerely yours,
Sergey Kusnetsov.

[Victor Sudakov]

Dear Sergey,

03 Dec 14 09:56, you wrote to Ivan Novikov:

IN>> чую - любимый провайдер

SK> "эр-телеком" прямо сейчас в ответ на github.com выдаёт ip
SK> 92.255.241.100 что соответствует
SK> net241.255.92-100.holding.ertelecom.ru ,

Черт, когда уже DNSSEC повсеместно будет. Задолбали умники DNS переписывать.

А если ты спросишь github.com например у 8.8.8.8, "эр-телеком" тоже "исправит"
ответ? Или "исправляет" только ответы собственных DNS серверов?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Sergey Kusnetsov]

Hello Victor,

Wed, 03 Dec 2014 14:33:48, you wrote to me:

VS> Черт, когда уже DNSSEC повсеместно будет. Задолбали умники DNS
VS> переписывать.

Да уж.

VS> А если ты спросишь github.com например у 8.8.8.8, "эр-телеком" тоже
VS> "исправит"
VS> ответ? Или "исправляет" только ответы собственных DNS серверов?

Конечно исправит!

========================= begin 8< =========================
nslookup github.com 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8

Non-authoritative answer:
Name: github.com
Address: 92.255.241.100
========================== end 8< ==========================

Sincerely yours,
Sergey Kusnetsov.

[Vitaly Zaitsev]

Здpавствуй, Sergey!

Среда 03 Декабря 2014 20:30, ты писал(а) Victor Sudakov:

SK> Конечно исправит!

Используй dnscrypt.

С уважением, Vitaly (***@easycoding.org)

[Vitaly Zaitsev]

Здpавствуй, Victor!

Среда 03 Декабря 2014 14:33, ты писал(а) Sergey Kusnetsov:

VS> А если ты спросишь github.com например у 8.8.8.8, "эр-телеком" тоже
VS> "исправит" ответ? Или "исправляет" только ответы собственных DNS
VS> серверов?

Исправляют. У меня знакомый их абонент. Он поставил dnscrypt и проблема
исчезла.

С уважением, Vitaly (***@easycoding.org)

[Ivan Novikov]

Привет, Sergey!

03 Dec 14, Sergey Kusnetsov накропал письмо к Ivan Novikov:
IN>> чую - любимый провайдер
SK>
SK> "эр-телеком" прямо сейчас в ответ на github.com выдаёт ip 92.255.241.100
SK> что соответствует net241.255.92-100.holding.ertelecom.ru , а там:
SK>
SK> ========================= begin 8< =========================
SK> openssl s_client -connect github.com:443
SK> Loading 'screen' into random state - done
SK> CONNECTED(0000012C)
SK> depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN =
SK> AddTrust Externa l CA Root verify error:num=19:self signed certificate in
SK> certificate chain verify return:0 -+- Certificate chain 0
SK> s:/C=RU/postalCode=614000/ST=Permskij
SK> Kraj/L=Perm/street=Gorod/street=Monastyrskaja Uli ca, 15/O=CJSC ER-Telecom
SK> Holding/OU=IT/OU=Hosted by JSC Regional Network Information
SK> Cente r/OU=PremiumSSL Wildcard/CN=*.ertelecom.ru

ну эти хоть не скрываясь подменяют
щас проверил - у местного та же фигня
Verify return code: 19 (self signed certificate in certificate chain)


С приветом, Ivan.

[Sergey Kusnetsov]

Hello Ivan,

Wed, 03 Dec 2014 19:58:58, you wrote to me:

IN> ну эти хоть не скрываясь подменяют

И ответы со всяких там 8.8.8.8 тоже подменивают.

IN> щас проверил - у местного та же фигня
IN> Verify return code: 19 (self signed certificate in certificate chain)

Похоже это уже повсеместно. Севкорея.

Sincerely yours,
Sergey Kusnetsov.

[Vitaly Zaitsev]

Здpавствуй, Sergey!

Среда 03 Декабря 2014 09:56, ты писал(а) Ivan Novikov:

SK> "эр-телеком"

Эти уроды давно влезают в HTTPS трафик.

С уважением, Vitaly (***@easycoding.org)

[Vitaly Zaitsev]

Здpавствуй, Victor!

Пятница 28 Hоября 2014 09:05, ты писал(а) мне:

VS> Да, неоднократно наблюдал, как люди кликают "Всё равно продолжить" на
VS> сообщение о недействительном сертификате. Ростелеком в частности
VS> приучает к этому:

Hекоторые провайдеры уже подменяют сертификаты Google, а ТП говорит, что это
нормально и надо установить их CA в качестве доверенного. К счастью, привязка
сертификатов в Chromium/Firefox уже на подходе (тестируется в бете).

VS> Еще можно вспомнить распространенную корпоративную практику перехвата
VS> HTTPS трафика сотрудников на HTTP прокси (так называемый SSL bump).

Там как раз всё OK ибо CA организации посредством политик устанавливается в
доверенные на всех ПК.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Vitaly,

28 Nov 14 20:07, you wrote to me:

VS>> Да, неоднократно наблюдал, как люди кликают "Всё равно
VS>> продолжить" на сообщение о недействительном сертификате.
VS>> Ростелеком в частности приучает к этому:

VZ> Hекоторые провайдеры уже подменяют сертификаты Google, а ТП говорит,
VZ> что это нормально и надо установить их CA в качестве доверенного. К
VZ> счастью, привязка сертификатов в Chromium/Firefox уже на подходе
VZ> (тестируется в бете).

VS>> Еще можно вспомнить распространенную корпоративную практику
VS>> перехвата HTTPS трафика сотрудников на HTTP прокси (так
VS>> называемый SSL bump).

VZ> Там как раз всё OK ибо CA организации посредством политик
VZ> устанавливается в доверенные на всех ПК.

Я надеюсь, что привязка сертификатов и эту малину если не поломает, то сильно
усложнит жизнь любителям покопаться в чужом трафике.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Vitaly Zaitsev]

Здpавствуй, Victor!

Суббота 29 Hоября 2014 11:17, ты писал(а) мне:

VZ>> Там как раз всё OK ибо CA организации посредством политик
VZ>> устанавливается в доверенные на всех ПК.
VS> Я надеюсь, что привязка сертификатов и эту малину если не поломает, то
VS> сильно усложнит жизнь любителям покопаться в чужом трафике.

В Firefox будет опционально отключаться в about:config, поэтому администраторы
могут отключить это для всех.

С уважением, Vitaly (***@easycoding.org)

[Serguei E. Leontiev]

Привет Виктор,

От 28 ноября 2014 г., 9:05:10 в fido7.ru.crypt ты писал:
VS> Да, неоднократно наблюдал, как люди кликают "Всё равно
VS> продолжить" на сообщение о недействительном сертификате.
VS> Ростелеком в частности приучает к этому:
VS> http://runog.spb.ru/pipermail/runog/2014-May/000500.html

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

VS> Еще можно вспомнить распространенную корпоративную практику
VS> перехвата HTTPS трафика сотрудников на HTTP прокси (так
VS> называемый SSL bump).

При грамотной настройке и администрировании запрет "прямого" HTTPS
скорее всего окажется надёжнее, чем попытка распространения надёжных
политик TLS во всевозможные приложения пользователей.

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Vitaly Zaitsev]

Здpавствуй, Serguei!

Понедельник 01 Декабря 2014 18:12, ты писал(а) Victor Sudakov:

SEL> Как это описано - это безусловно нехорошо. Есть же нормальные средства
SEL> и возможность нормального описания с установкой корневого сертификата
SEL> от поставщика Интернет.

Вмешательство в зашифрованный трафик абонента никак не может быть нормальным.

С уважением, Vitaly (***@easycoding.org)

[Serguei E. Leontiev]

Привет Виталий,

От 1 декабря 2014 г., 21:25:24 в fido7.ru.crypt ты писал:
SEL>> Как это описано - это безусловно нехорошо. Есть же
SEL>> нормальные средства и возможность нормального описания с
SEL>> установкой корневого сертификата от поставщика Интернет.
VZ> Вмешательство в зашифрованный трафик абонента никак не может
VZ> быть нормальным.

Почему? В чём проблема? (То как большинство browser-ов "защищают"
соединение вызывает столько вопросов, что лучше б не защищали бы вовсе,
оно было бы понятнее)

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Vitaly Zaitsev]

Здpавствуй, Serguei!

Понедельник 01 Декабря 2014 20:41, ты писал(а) мне:

SEL> Почему? В чём проблема?

1. Провайдер должен предоставлять трубу и никак не вмешиваться в трафик
абонента.

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

С уважением, Vitaly (***@easycoding.org)

[Serguei E. Leontiev]

Виталий, привет,

Post by Vitaly Zaitsev
SEL> Почему? В чём проблема?
1. Провайдер должен предоставлять трубу и никак не вмешиваться в трафик
абонента.

"должен" в данном контексте это юридический термин или некое "понятие"? Оно
требует пояснения.

В любом случае, https прокси, как любой другой прокси или NAT, это не
совсем уж прямо так: "вмешательство в трафик", наверное, если строго, это
обработка запроса абонента.

Post by Vitaly Zaitsev
2. Трафик шифруется как раз для того, чтобы никто не мог влезть в него и что-то
подменить, либо вытащить пароли.

Это требование, я склонен полагать, обеспечивается, как на юридическом, так
и на техническом уровне.

[Alexey Vissarionov]

Доброго времени суток, Serguei!

Post by Vitaly Zaitsev
1. Провайдер должен предоставлять трубу и никак не вмешиваться в
трафик абонента.

SL> "должен" в данном контексте это юридический термин или некое
SL> "понятие"? Оно требует пояснения.
SL> В любом случае, https прокси, как любой другой прокси или NAT,
SL> это не совсем уж прямо так: "вмешательство в трафик", наверное,
SL> если строго, это обработка запроса абонента.

Какого такого запроса? Услуга называется "передача данных".

Post by Vitaly Zaitsev
2. Трафик шифруется как раз для того, чтобы никто не мог влезть в
него и что-то подменить, либо вытащить пароли.

SL> Это требование, я склонен полагать, обеспечивается, как на
SL> юридическом, так и на техническом уровне.

Никак оно не обеспечивается... любой УЦ по запросу "органов" выпустит левый
сертификат для любого домена. В полном соответствии с законом, ага.

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

[Serguei E. Leontiev]

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

От 2 декабря 2014 г., 18:18:18 в fido7.ru.crypt ты писал:
??>>> 1. Провайдер должен предоставлять трубу и никак не
??>>> вмешиваться в трафик абонента.
SL>> "должен" в данном контексте это юридический термин или некое
SL>> "понятие"? Оно требует пояснения.
SL>> В любом случае, https прокси, как любой другой прокси или
SL>> NAT, это не совсем уж прямо так: "вмешательство в трафик",
SL>> наверное, если строго, это обработка запроса абонента.
AV> Какого такого запроса? Услуга называется "передача данных".

Запроса на передачу данных.

??>>> 2. Трафик шифруется как раз для того, чтобы никто не
??>>> мог влезть в него и что-то подменить, либо вытащить
??>>> пароли.
SL>> Это требование, я склонен полагать, обеспечивается, как на
SL>> юридическом, так и на техническом уровне.
AV> Hикак оно не обеспечивается... любой УЦ по запросу "органов"
AV> выпустит левый сертификат для любого домена. В полном
AV> соответствии с законом, ага.

Ой, всякое конечно бывает, но ИМХО вряд ли они будут возиться,
рассекречивать потребное им имя сервера и идентификаторы клиента, им
проще так взломать и прочитать трафик без всей этой мышиной возни. Вот
умная фильтрация по требованию Роскомнадзора, это да.

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Alexey Vissarionov]

Доброго времени суток, 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) для всех своих виртуальных хостов и, сравнивая их с хешом,
вычисленным клиентом, определяет, с каким хостом хочет работать клиент.

Недостаток у данного метода ровно один: каждое соединение требует вычисления
кучки хешей на сервере. Разумеется, первые хеши (непосредственно для имен)
вычисляются заранее и хранятся в памяти, но "соленые" считать все же придется.
==== тьфу ====

[Serguei E. Leontiev]

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

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

С какого такого перепугу, оператор связи не может использовать NAT или
прокси? Какой такой "Коран" ему это запрещает? ИМХО это просто твоё,
вполне себе произвольное пожелание, которому можно следовать, а можно и
не следовать.

??>>>>> 2. Трафик шифруется как раз для того, чтобы
??>>>>> никто не мог влезть в него и что-то подменить,
??>>>>> либо вытащить пароли.
SL>>>> Это требование, я склонен полагать, обеспечивается,
SL>>>> как на юридическом, так и на техническом уровне.
AV>>> Hикак оно не обеспечивается... любой УЦ по запросу
AV>>> "органов" выпустит левый сертификат для любого домена.
AV>>> В полном соответствии с законом, ага.
SL>> Ой, всякое конечно бывает, но ИМХО вряд ли они будут
SL>> возиться, рассекречивать потребное им имя сервера и
SL>> идентификаторы клиента, им проще
AV> ... выпустить wildcard certificate для каждого TLD - *.com,
AV> *.net, *.ru итд.

А это ничего, что в "Коране" написано: "... Names may contain the
wildcard character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but not
bar.foo.a.com. f*.com matches foo.com but not bar.com."

Или реализации уже и на это уже забили?

SL>> так взломать и прочитать трафик без всей этой мышиной возни.
AV> Так взломать - это как?

Как? Как? Hаверное в рамках оперативно-розыскных мероприятий или как там
это у них называется. Ибо, все Вассенаарские соглашения более или менее
выполняют, зря что ли подписывали, так что если что-то не требует
лицензии/разрешения на экспорт из буржуинии и лицензии/разрешения на
импорт в РФ или наоборот, значит, ИМХО, в этих сотнях миллионов строк
исходного кода и/или гигбайтах бинарного кода содержится достаточное
количество слабостей для всех заинтересованных сторон.

А если даже и встретится реальный параноик, который попытается навестить
парочку "бронещитков", то он первое что сделает - это забъёт болт на
всякие там готовые https или gpg и всё переделает. :)

SL>> Вот умная фильтрация по требованию Роскомнадзора, это да.
AV> А для этого и внутрь HTTPS лезть не нужно - SNI в открытом виде

В SNI передаётся только имя сервера, и кому будет радость от
блокирования https://ВСервер.рф вместо указанного Роскомнадзором
https://ВСервер.рф/Дкозлов/Дпорнография ?

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Alexey Vissarionov]

Доброго времени суток, Serguei!
02 Dec 2014 21:35:34, ты -> мне:

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

Функции корана и прочих писаний в данном случае выполняет ФЗ "О связи" и
подзаконные акты к нему. Подробности рыть не буду, но хорошо помню, как мы
бодались с тогдашним Связьнадзором (щас Роскомнадзор) после жалобы усера,
которому не понравился прозрачный прокси с антивирусной проверкой...

SL> ИМХО это просто твоё, вполне себе произвольное пожелание, которому
SL> можно следовать, а можно и не следовать.

Увы - я тогда возглавлял NOC, так что все технические аспекты переписки
свалились на меня.

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

Не скажу за всех, но соответствует ли wildcard-сертификат хосту - каждый
разработчик определяет сам в соответствии со своим пролетарским чутьем.

SL>>> так взломать и прочитать трафик без всей этой мышиной возни.
AV>> Так взломать - это как?
SL> Как? Как? Hаверное в рамках оперативно-розыскных мероприятий или как
SL> там это у них называется.

Это уже специальные технические мероприятия (СТМ) в ходе ОРД. Впрочем, они
обычно сводятся к "дайте нам %s", ибо толковых специалистов у них мало.

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

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

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

SL> А если даже и встретится реальный параноик, который попытается
SL> навестить парочку "бронещитков", то он первое что сделает - это
SL> забъёт болт на всякие там готовые https или gpg и всё переделает. :)

Если при этом его решение сохранит совместимость с "недоверенными" - why бы,
собственно, и not?

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

Еще бы это хоть как-то волновало РКН...

[Serguei E. Leontiev]

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

От 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: ***@CryptoPro.ru

[Alexey Vissarionov]

Доброго времени суток, Serguei!
03 Dec 2014 06:07:32, ты -> мне:

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

Зато вполне позволит трактовать "*" как /[a-z0-9.-]+/ вместо /[a-z0-9-]+./

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

До первого пострадавшего, который поднимет шум.

SL> нежели сначала уговорить производителей, что она существует, а потом
SL> ещё и проследить, что бы исправили её разумно, а не как попало.

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

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

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

AV>> Вот в параметрах алгоритма таки да, закладки вполне реальны
SL> Подавляющее большинство слабостей и уязвимостей в конкретных
SL> реализациях, их искать - это к гадалке не ходи, ни славы, ни почёта,
SL> а сплошной геморрой,

Реализации - тут да... "гладко было на бумаге, а потом полезли баги".

SL> всякие там соревнования, переполнения буферов

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

SL> и ошибки реализаций ДСЧ.

Здесь чуть сложнее... Мне, например, нравится реализация /dev/random в Linux:
информация от разных источников подмешивается в пул энтропии с использованием
хеш-функции (на данный момент это SHA-256, но никто не мешает использовать и
любую другую).

SL> Hа втором месте слабости протоколов, они же все далеки от идеала,
SL> это ж ещё хуже, что X.509, что IPsec, что TLS,

Там изначально дурацкая иерархическая модель. В этом отношении мне ближе
концепция PGP/GPG: если я доверяю ключу X (например, получил его при личной
встрече), а X подписал ключ Y, то у меня к этому ключу чуть больше доверия,
нежели к неподписанному, но меньше, чем в ситуации, когда ключ Y помимо X
дополнительно подписали A, B и C.

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

Да у них вся работа - сплошная имитация бурной деятельности...

[Serguei E. Leontiev]

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

От 3 декабря 2014 г., 11:33:22 в fido7.ru.crypt ты писал:
SL>>>> ИМХО, в этих сотнях миллионов строк исходного кода
SL>>>> и/или гигбайтах бинарного кода содержится
SL>>>> достаточное количество слабостей для всех
SL>>>> заинтересованных сторон.
AV>>> Очень спорно... Алгоритмы опубликованы, методы проверки
AV>>> соответствия кода алгоритму известны, исходники
AV>>> доступны - итого остается разве что некоторая
AV>>> вероятность злого умысла разработчиков алгоритма, но на
AV>>> этот случай есть криптоаналитики, которые спят и видят,
AV>>> как бы обнаружить лажу в творении именитого
AV>>> криптографа.
SL>> Hа дворе 21-й век, ИМХО, на пару порядков проще
SL>> монетизировать слабость или уязвимость,
AV> До первого пострадавшего, который поднимет шум.

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

SL>> нежели сначала уговорить производителей, что она
SL>> существует, а потом ещё и проследить, что бы исправили её
SL>> разумно, а не как попало.
AV> Отправить им письмо с описанием, а ровно через месяц независимо
AV> ни от чего опубликовать в нескольких общедоступных конференциях.

А толку то? ИМХО, если исправление нетривиально, то проблема обычно
игнорируется.

Я за этим особо не слежу, но можно и нервы сильно потрепать, так
помнится когда-то были такие судебная тяжба: Adobe и/или народ США
против Скляров из Элкомсофт. Оно очень кому надо?

SL>> Чего далеко ходить, например, я вот свято уверен, что
SL>> переход на TLS 1.2 с использованием
SL>> TLS_RSA_WITH_AES_128_CBC_SHA256 и запрет
SL>> TLS_RSA_WITH_RC4_128_SHA - это заговор мировой закулисы :)
AV> Если на то пошло, следовало бы до сих пор использовать SSLv2,
AV> добавив в него современные алгоритмы... А впрочем, RSA,
AV> Blowfish и RIPEMD на тот момент уже существовали, что
AV> (теоретически) позволяло еще тогда создать криптосредства,
AV> которые сохранили бы актуальность и поныне.

RIPEMD - по-моему, для неё коллизии уже строили, лет так 10 назад, она
же ближе к MD5, чем к SHA-1 (чистоту "репутации" которой блюдёт АHБ,
теми или иными способами :) ). Хотя HMAC-RIPEMD это не особо затрагивает.

RSA-OAEP и RSA-PSS, да существовали, но народу это по сию пору не интересно.

AV> Реализации - тут да... "гладко было на бумаге, а потом полезли
AV> баги".
SL>> всякие там соревнования, переполнения буферов
AV> Погромистов, допускающих подобные ошибки, к реализации
AV> криптоалгоритмов даже близко подпускать нельзя.

В 99% процентах реализаций прикладное ПО имеет доступ к ключам. А есть
же ещё целый пласт алгоритмов, протоколов и ПО связанных с получением
обновлений ОС и пакетов от производителей, их вообще мало кто исследует.

SL>> и ошибки реализаций ДСЧ.
AV> Здесь чуть сложнее... Мне, например, нравится реализация
AV> /dev/random в Linux: информация от разных источников
AV> подмешивается в пул энтропии с использованием хеш-функции (на
AV> данный момент это SHA-256, но никто не мешает использовать и
AV> любую другую).

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

SL>> Hа втором месте слабости протоколов, они же все далеки от
SL>> идеала, это ж ещё хуже, что X.509, что IPsec, что TLS,
AV> Там изначально дурацкая иерархическая модель. В этом отношении

Я ж не про принципы, я ж про детали, например, такие как: "X.509
Certificates NUL Character Spoofing", навязывание IV, и т.д., которые не
исправляются многие и многие годы (проблемы в CBC были опубликованы аж в
2001-2004, прошло больше десятка лет и по сию пору они актуальны для
TLS, актуальны ли они ещё для SSH не скажу).

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Alexey Vissarionov]

Доброго времени суток, Serguei!
03 Dec 2014 14:12:52, ты -> мне:

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

Зачем крутой? Достаточно говнистого :-)

AV>> Отправить им письмо с описанием, а ровно через месяц независимо
AV>> ни от чего опубликовать в нескольких общедоступных конференциях.
SL> А толку то? ИМХО, если исправление нетривиально, то проблема обычно
SL> игнорируется.

Значит, будет zero day.

SL>>> Чего далеко ходить, например, я вот свято уверен, что
SL>>> переход на TLS 1.2 [...] - это заговор мировой закулисы :)
AV>> Если на то пошло, следовало бы до сих пор использовать SSLv2,
AV>> добавив в него современные алгоритмы... А впрочем, RSA,
AV>> Blowfish и RIPEMD на тот момент уже существовали, что
AV>> (теоретически) позволяло еще тогда создать криптосредства,
AV>> которые сохранили бы актуальность и поныне.
SL> RIPEMD - по-моему, для неё коллизии уже строили, лет так 10 назад,
SL> она же ближе к MD5, чем к SHA-1 (чистоту "репутации" которой блюдёт
SL> АHБ, теми или иными способами :) ). Хотя HMAC-RIPEMD это не особо
SL> затрагивает.

Тем не менее, во времена SSLv2 оно уже было и позволяло 256-битные хеши.
Собственно, оно нужно-то в основном для отбеливания ключевой информации.

SL>>> всякие там соревнования, переполнения буферов
AV>> Погромистов, допускающих подобные ошибки, к реализации
AV>> криптоалгоритмов даже близко подпускать нельзя.
SL> В 99% процентах реализаций прикладное ПО имеет доступ к ключам.
SL> А есть же ещё целый пласт алгоритмов, протоколов и ПО связанных
SL> с получением обновлений ОС и пакетов от производителей, их вообще
SL> мало кто исследует.

Ну вот, например, я исследую... И во многом именно поэтому рекомендую
использовать Linux-системы с пакетным менеджером RPM.

SL>>> и ошибки реализаций ДСЧ.
AV>> Здесь чуть сложнее... Мне, например, нравится реализация
AV>> /dev/random в Linux: информация от разных источников
AV>> подмешивается в пул энтропии с использованием хеш-функции (на
AV>> данный момент это SHA-256, но никто не мешает использовать и
AV>> любую другую).
SL> Hравится и нравится, лучшее враг хорошего, хотя мне встречались
SL> статьи, которые утверждали, что зловредный поставщик энтропии
SL> так и может подмешать кое-что определённое.

Не зная текущее состояние пула энтропии? Кхм... очень маловероятно.

SL>>> Hа втором месте слабости протоколов, они же все далеки от
SL>>> идеала, это ж ещё хуже, что X.509, что IPsec, что TLS,
AV>> Там изначально дурацкая иерархическая модель.
SL> Я ж не про принципы, я ж про детали, например, такие как:
SL> "X.509 Certificates NUL Character Spoofing", навязывание IV,
SL> и т.д., которые не исправляются многие и многие годы (проблемы
SL> в CBC были опубликованы аж в 2001-2004, прошло больше десятка
SL> лет и по сию пору они актуальны для TLS, актуальны ли они ещё
SL> для SSH не скажу).

SSH умеет aes256-ctr и hmac-sha2-512 (да, говно, но ничего лучше пока нет -
похоже, разработчики OpenSSL про Twofish и CFB не слышали).


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... Детский WikiLeaks: Деда Мороза не существует, жопа от сладкого не слипается

[Vitaly Zaitsev]

Здpавствуй, Serguei!

Среда 03 Декабря 2014 06:07, ты писал(а) Alexey Vissarionov:

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

https://github.com/ уже вчера запретили. Hа очереди https://bitbucket.org/ и
другие опенсорцные хранилища исходного кода ибо граждане Украины залили тот
шуточный файл suicide.txt во все, а затем отправили жалобы в росцензуру.

С уважением, Vitaly (***@easycoding.org)

[Ivan Shmakov]

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

VZ> https://github.com/ уже вчера запретили. Hа очереди
VZ> https://bitbucket.org/ и другие опенсорцные хранилища исходного
VZ> кода ибо граждане Украины залили тот шуточный файл suicide.txt во
VZ> все, а затем отправили жалобы в росцензуру.

Википедию уже запретили -- из-за <<самоубийства>> и прочего
<<пентобарбитала>> [1]. И вот теперь автор учебника для 10--11
классов <<Интересное обществознание>> решил разместить его в
одном из <<братских проектов>> -- Викиучебнике.

Примечательно наличие в этом учебнике раздела [2], подразделом
которого значится ни что иное, как <<Суицидное поведение>>.

Ждем санкций.

[1] https://ru.wikipedia.org/wiki/?curid=4466644
[2] https://ru.wikipedia.org/wiki/?curid=14861

[Vitaly Zaitsev]

Здpавствуй, Ivan!

Среда 03 Декабря 2014 20:38, ты писал(а) мне:

IS> Википедию уже запретили -- из-за <<самоубийства>> и прочего
IS> <<пентобарбитала>> [1]. И вот теперь автор учебника для
IS> 10--11 классов <<Интересное обществознание>> решил разместить его
IS> в одном из <<братских проектов>> -- Викиучебнике.

Запретили, причём очень давно (в прошлом году ещё), но пока не рискуют
блокировать ибо волна негодования поднимется слишком большая.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Alexey,

02 Dec 14 18:18, you wrote to Serguei E. Leontiev:

AV> Никак оно не обеспечивается... любой УЦ по запросу "органов" выпустит
AV> левый сертификат для любого домена. В полном соответствии с законом,
AV> ага.

*Любой* УЦ может и не прогнется под органы. Кто-то, может быть, предпочтет
закрыться, как Лавабит.

но беда всей системы доверия в WWW в том, что достаточно прогнуться только
*одному* УЦ из сотни установленных в наших браузерах. Т.е. вся система не более
заслуживает доверия, чем ее самое слабое звено.

Вот в Firefox в качестве доверенного, среди прочих, установлен сертификат
какого-то Чунгва Телеком. Кто эти люди? Почему я им должен доверять?

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

А еще есть проекты по публикации SSL сертификтов прямо в DNS (разумеется в
защищенном DNSSEC), тогда все централизованные УЦ становятся просто не нужны.

http://blog.huque.com/2012/10/dnssec-and-certificates.html

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alexey Vissarionov]

Доброго времени суток, Victor!
02 Dec 2014 22:23:22, ты -> мне:

AV>> Никак оно не обеспечивается... любой УЦ по запросу "органов"
AV>> выпустит левый сертификат для любого домена. В полном соответствии
AV>> с законом, ага.
VS> *Любой* УЦ может и не прогнется под органы. Кто-то, может быть,
VS> предпочтет закрыться, как Лавабит. но беда всей системы доверия
VS> в WWW

Почему только WWW?

VS> в том, что достаточно прогнуться только *одному* УЦ из сотни
VS> установленных в наших браузерах. Т.е. вся система не более
VS> заслуживает доверия, чем ее самое слабое звено.

Именно так. Более того, _все_ УЦ в отдельно взятой стране "сотрудничают" с
"органами" означенной страны.

VS> Вот в Firefox в качестве доверенного, среди прочих, установлен
VS> сертификат какого-то Чунгва Телеком. Кто эти люди? Почему я им
VS> должен доверять?

А зачем ты им доверяешь? Неужели только потому, что разработчики фраерфокса
зачем-то засунули их сертификат в cert8.db?

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

В случае DNSSEC идея хороша, но:
1. отсутствуют кошерные реализации оного;
2. сохраняется проблема первого подключения.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... Бывают такие зайчики, от которых волки на деревья лезут

[Serguei E. Leontiev]

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

От 2 декабря 2014 г., 21:01:00 в fido7.ru.crypt ты писал:
VS>> в том, что достаточно прогнуться только *одному* УЦ из сотни

Прогнуться? В будущем времени? Все уже и давно, например, Trustwave
выкинули:

https://bugzilla.mozilla.org/show_bug.cgi?id=724929

Так и нет! Оставили. А думаешь он один такой выпускает сертификаты для
специализированных подчинённых УЦ?

VS>> установленных в наших браузерах. Т.е. вся система не более
VS>> заслуживает доверия, чем ее самое слабое звено.
AV> Именно так. Более того, _все_ УЦ в отдельно взятой стране
AV> "сотрудничают" с "органами" означенной страны.

Я понимаю, что "означенной" - это США? Да вот, беда, глобализация, мать
её за ногу, так что "отдельно взятой США" не получается. Они делают
дырки под себя и свои органы, а ими пользуются все кому не лень. :)

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Alexey Vissarionov]

Доброго времени суток, Serguei!
02 Dec 2014 21:46:06, ты -> мне:

VS>>> в том, что достаточно прогнуться только *одному* УЦ из сотни
SL> Прогнуться? В будущем времени? Все уже и давно, например, Trustwave
SL> выкинули: https://bugzilla.mozilla.org/show_bug.cgi?id=724929
SL> Так и нет! Оставили. А думаешь он один такой выпускает сертификаты
SL> для специализированных подчинённых УЦ?

Разумеется, нет. Так что все эти "доверенные" сертификаты - профанация.

VS>>> установленных в наших браузерах. Т.е. вся система не более
VS>>> заслуживает доверия, чем ее самое слабое звено.
AV>> Именно так. Более того, _все_ УЦ в отдельно взятой стране
AV>> "сотрудничают" с "органами" означенной страны.
SL> Я понимаю, что "означенной" - это США?

Нет - речь про абсолютно любую страну. В частности, РФ - не исключение.

SL> Да вот, беда, глобализация, мать её за ногу, так что "отдельно
SL> взятой США" не получается. Они делают дырки под себя и свои
SL> органы, а ими пользуются все кому не лень. :)

Ну и пусть они там суют свои органы в свои же дырки... :-)

[Victor Sudakov]

Dear Alexey,

02 Dec 14 21:01, you wrote to me:
AV>>> Никак оно не обеспечивается... любой УЦ по запросу "органов"
AV>>> выпустит левый сертификат для любого домена. В полном
AV>>> соответствии с законом, ага.
VS>> *Любой* УЦ может и не прогнется под органы. Кто-то, может быть,
VS>> предпочтет закрыться, как Лавабит. но беда всей системы доверия
VS>> в WWW

AV> Почему только WWW?

Потому что мы сейчас HTTPS обсуждаем.

Скажем X.509 сертификат своего почтового корреспондента я теоретически могу
сверить по телефону или при личной встрече, а в случае WWW вынужден полагаться
только на честное слово УЦ.

VS>> в том, что достаточно прогнуться только *одному* УЦ из сотни
VS>> установленных в наших браузерах. Т.е. вся система не более
VS>> заслуживает доверия, чем ее самое слабое звено.

AV> Именно так. Более того, _все_ УЦ в отдельно взятой стране
AV> "сотрудничают" с "органами" означенной страны.

Все - слишком сильное слово. Достаточно, если сотрудничать будет ровно один.
Причем предпочтительный механизм сотрудничества, как я понял - это
делегирование полномочий некоторому промежуточному УЦ.

Идея certificate pinning не на пустом месте появилась, очевидно.

VS>> Вот в Firefox в качестве доверенного, среди прочих, установлен
VS>> сертификат какого-то Чунгва Телеком. Кто эти люди? Почему я им
VS>> должен доверять?

AV> А зачем ты им доверяешь? Неужели только потому, что разработчики
AV> фраерфокса зачем-то засунули их сертификат в cert8.db?

Лично я как раз не доверяю. Но много ли людей хотя бы раз вообще заглядывали в
дефолтовый список доверенных сертификатов?

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

AV> В случае DNSSEC идея хороша, но:
AV> 1. отсутствуют кошерные реализации оного;

Серверные в наличии, у меня например зона sibptus.ru подписана. Клиентские тоже
вроде есть, даже винда поддерживает.

AV> 2. сохраняется проблема первого подключения.

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

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alexey Vissarionov]

Доброго времени суток, Victor!
03 Dec 2014 09:13:46, ты -> мне:

AV>>>> Никак оно не обеспечивается... любой УЦ по запросу "органов"
AV>>>> выпустит левый сертификат для любого домена. В полном
AV>>>> соответствии с законом, ага.
VS>>> *Любой* УЦ может и не прогнется под органы. Кто-то, может быть,
VS>>> предпочтет закрыться, как Лавабит. но беда всей системы доверия
VS>>> в WWW
AV>> Почему только WWW?
VS> Потому что мы сейчас HTTPS обсуждаем. Скажем X.509 сертификат своего
VS> почтового корреспондента я теоретически могу сверить по телефону или
VS> при личной встрече,

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

VS> а в случае WWW вынужден полагаться только на честное слово УЦ.

Или на сохраненный сертификат.

VS>>> Вот в Firefox в качестве доверенного, среди прочих, установлен
VS>>> сертификат какого-то Чунгва Телеком. Кто эти люди? Почему я им
VS>>> должен доверять?
AV>> А зачем ты им доверяешь? Неужели только потому, что разработчики
AV>> фраерфокса зачем-то засунули их сертификат в cert8.db?
VS> Лично я как раз не доверяю. Но много ли людей хотя бы раз вообще
VS> заглядывали в дефолтовый список доверенных сертификатов?

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

AV>>>> В этом отношении самоподписанные сертификаты оказываются даже
AV>>>> надежнее: если сертификат сервера внезапно поменялся (без
AV>>>> предварительного уведомления всех пользователей посредством,
AV>>>> например, подписанного эмыла) - значит, что-то тут нечисто...
VS>>> А еще есть проекты по публикации SSL сертификтов прямо в DNS
VS>>> (разумеется в защищенном DNSSEC) тогда все централизованные УЦ
VS>>> становятся просто не нужны.
AV>> В случае DNSSEC идея хороша, но:
AV>> 1. отсутствуют кошерные реализации оного;
VS> Серверные в наличии, у меня например зона sibptus.ru подписана.
VS> Клиентские тоже вроде есть, даже винда поддерживает.

Реализации есть. Кошерных реализаций нет (или я про них не знаю).

AV>> 2. сохраняется проблема первого подключения.
VS> Ну это проблема фундаментальная, любая цепочка доверия должна
VS> неизбежно в кого-то упираться.

В общем случае - совсем не обязательно. Достаточно, чтобы информация из
существенного количества источников была взаимно непротиворечивой.

Пример: то, что говорят школьные учителя естественных и точных наук,
складывается в единую непротиворечивую картину, а то, что врет поп, ей
противоречит.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... Только дурак нуждается в порядке - гений господствует над хаосом

[Serguei E. Leontiev]

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

От 3 декабря 2014 г., 12:24:44 в fido7.ru.crypt ты писал:
AV> GPG - то есть, пофигу, откуда и как пришло сообщение, если оно
AV> снабжено кошерной подписью.
...
AV> Реализации есть. Кошерных реализаций нет (или я про них не
AV> знаю).
...
AV> информация из существенного количества источников была взаимно
AV> непротиворечивой.
AV> Пример: то, что говорят школьные учителя естественных и точных
AV> наук, складывается в единую непротиворечивую картину, а то, что
AV> врет поп, ей противоречит.

:) Ересь-то не разводи :) А потом пришли миллионы и миллионы китайцев с
разных концов света и рассказали, что Конфунций считай, что Бог, а Мао
Цзэдун пророк его :)

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Victor Sudakov]

Dear Alexey,

03 Dec 14 12:24, you wrote to me:

[dd]

AV> А смысл? Для почты (и прочих сообщений) уместнее использовать GPG - то
AV> есть, пофигу, откуда и как пришло сообщение, если оно снабжено
AV> кошерной подписью.

Использование PGP в переписке, к сожалению, так и не вышло за пределы
немногочисленного круга технарей.

VS>> а в случае WWW вынужден полагаться только на честное слово УЦ.

AV> Или на сохраненный сертификат.

Что-то вроде модели known_hosts, принятой в SSH. Да, пожалуй.

VS>>>> Вот в Firefox в качестве доверенного, среди прочих, установлен
VS>>>> сертификат какого-то Чунгва Телеком. Кто эти люди? Почему я им
VS>>>> должен доверять?
AV>>> А зачем ты им доверяешь? Неужели только потому, что разработчики
AV>>> фраерфокса зачем-то засунули их сертификат в cert8.db?
VS>> Лично я как раз не доверяю. Но много ли людей хотя бы раз вообще
VS>> заглядывали в дефолтовый список доверенных сертификатов?

AV> Если кто-то не заглядывает - их не жалко.

Не согласен. Далеко не все люди являются технарями, способными разобраться в
вопросе. И предлагать им изначально небезопасное решение, не предупредив -
безнравственно. Это вроде того, как продавать автомобиль с заведомо
неисправными тормозами, мотивируя тем, что если кто-то не автослесарь - его не
жалко.

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

А я вот наоборот, никогда не пребываю в подобном состоянии успокоенности и
уверенности.

AV>>>>> В этом отношении самоподписанные сертификаты оказываются даже
AV>>>>> надежнее: если сертификат сервера внезапно поменялся (без
AV>>>>> предварительного уведомления всех пользователей посредством,
AV>>>>> например, подписанного эмыла) - значит, что-то тут нечисто...
VS>>>> А еще есть проекты по публикации SSL сертификтов прямо в DNS
VS>>>> (разумеется в защищенном DNSSEC) тогда все централизованные УЦ
VS>>>> становятся просто не нужны.
AV>>> В случае DNSSEC идея хороша, но:
AV>>> 1. отсутствуют кошерные реализации оного;
VS>> Серверные в наличии, у меня например зона sibptus.ru подписана.
VS>> Клиентские тоже вроде есть, даже винда поддерживает.

AV> Реализации есть. Кошерных реализаций нет (или я про них не знаю).

Какую реализацию ты посчитал бы кошерной? Вот у меня дома в named.conf написано
"dnssec-validation auto" - это треф?

AV>>> 2. сохраняется проблема первого подключения.
VS>> Ну это проблема фундаментальная, любая цепочка доверия должна
VS>> неизбежно в кого-то упираться.

AV> В общем случае - совсем не обязательно. Достаточно, чтобы информация
AV> из существенного количества источников была взаимно непротиворечивой.

Значит она просто упирается в эти источники, только и всего. Только изначальный
источник всё равно один.

AV> Пример: то, что говорят школьные учителя естественных и точных наук,
AV> складывается в единую непротиворечивую картину, а то, что врет поп, ей
AV> противоречит.

А что, если существенное количество попов не противоречат друг другу (как оно и
бывает)? Поверишь?


Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alexey Vissarionov]

Доброго времени суток, Victor!
08 Dec 2014 09:13:06, ты -> мне:

AV>> А смысл? Для почты (и прочих сообщений) уместнее использовать GPG -
AV>> то есть, пофигу, откуда и как пришло сообщение, если оно снабжено
AV>> кошерной подписью.
VS> Использование PGP в переписке, к сожалению, так и не вышло за пределы
VS> немногочисленного круга технарей.

Вышло, но далеко пока не ушло. Но я не про PGP/GPG, а про используемую там
модель доверия.

VS>>> а в случае WWW вынужден полагаться только на честное слово УЦ.
AV>> Или на сохраненный сертификат.
VS> Что-то вроде модели known_hosts, принятой в SSH. Да, пожалуй.

Именно так.

AV>> С другой стороны, лично я не использую ни одного уеб-сервиса,
AV>> компрометация сертификата которого не будет замечена мной И
AV>> сможет нанести хоть какой-то заметный ущерб.
VS> А я вот наоборот, никогда не пребываю в подобном состоянии
VS> успокоенности и уверенности.

Причем здесь "успокоенность и уверенность"? Речь о том, что, например,
компрометация сертификата какого-нибудь говногугла мне будет пофигу, ибо
использую я его исключительно анонимно (не являясь пользователем). А вот
сертификат уеб-морды банка у меня прибит гвоздями, да и SMS-уведомления
позволяют пропалить практически что угодно.

AV>>>>>> В этом отношении самоподписанные сертификаты оказываются даже
AV>>>>>> надежнее: если сертификат сервера внезапно поменялся (без
AV>>>>>> предварительного уведомления всех пользователей посредством,
AV>>>>>> например, подписанного эмыла) - значит, что-то тут нечисто...
VS>>>>> А еще есть проекты по публикации SSL сертификтов прямо в DNS
VS>>>>> (разумеется в защищенном DNSSEC) тогда все централизованные УЦ
VS>>>>> становятся просто не нужны.
AV>>>> В случае DNSSEC идея хороша, но:
AV>>>> 1. отсутствуют кошерные реализации оного;
VS>>> Серверные в наличии, у меня например зона sibptus.ru подписана.
VS>>> Клиентские тоже вроде есть, даже винда поддерживает.
AV>> Реализации есть. Кошерных реализаций нет (или я про них не знаю).
VS> Какую реализацию ты посчитал бы кошерной? Вот у меня дома в
VS> named.conf написано "dnssec-validation auto" - это треф?

Это профанация, которая обладает всеми недостатками SSL.

AV>>>> 2. сохраняется проблема первого подключения.
VS>>> Ну это проблема фундаментальная, любая цепочка доверия должна
VS>>> неизбежно в кого-то упираться.
AV>> В общем случае - совсем не обязательно. Достаточно, чтобы информация
AV>> из существенного количества источников была взаимно непротиворечивой.
VS> Значит она просто упирается в эти источники, только и всего. Только
VS> изначальный источник всё равно один.

Источник информации вида "мой сервер находится здесь" - да, и это лично я.
А что касается источников, откуда получает информацию пользователь, тут все
предельно просто: если 100500 источников утверждают, что нужный ему сервер
находится по адресу 1.2.3.4, а провайдерские NSы подсовывают ему 10.20.30.40,
вывод немного очевиден.

AV>> Пример: то, что говорят школьные учителя естественных и точных наук,
AV>> складывается в единую непротиворечивую картину, а то, что врет поп,
AV>> ей противоречит.
VS> А что, если существенное количество попов не противоречат друг другу
VS> (как оно и бывает)? Поверишь?

Не бывает (иначе не было бы понятия ереси), поэтому не поверю.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net

[Victor Sudakov]

Dear Alexey,

08 Dec 14 11:10, you wrote to me:

VS>>>> а в случае WWW вынужден полагаться только на честное слово УЦ.
AV>>> Или на сохраненный сертификат.
VS>> Что-то вроде модели known_hosts, принятой в SSH. Да, пожалуй.

AV> Именно так.

Собственно, не обязательно же отказываться от использования УЦ для того, чтобы
ввести еще дополнительную проверку по сохраненному сертификату. Как я понимаю,
расширение к FF, называемое Certificate Patrol, именно это и делает.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Alexey Vissarionov]

Доброго времени суток, Victor!
19 Dec 2014 13:55:06, ты -> мне:

VS>>>>> а в случае WWW вынужден полагаться только на честное слово УЦ.
AV>>>> Или на сохраненный сертификат.
VS>>> Что-то вроде модели known_hosts, принятой в SSH. Да, пожалуй.
AV>> Именно так.
VS> Собственно, не обязательно же отказываться от использования УЦ для
VS> того, чтобы ввести еще дополнительную проверку по сохраненному
VS> сертификату.

Наобормот: проверяем по сертификату, а дополнительно поглядываем и на CA.
Простейший пример: я сгенерировал сертификат со сроком действия 10 лет
(понадобится - продлю) и ежегодно отправляю в CA на подпись егойный CSR.

VS> Как я понимаю, расширение к FF, называемое Certificate Patrol,
VS> именно это и делает.

Не совсем так, как хотелось бы, но ничего лучше я пока не видел.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... Разверни часы с кукушкой циферблатом к стене - и получи часы с дятлом!

[Serguei E. Leontiev]

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

От 19 декабря 2014 г., 12:34:56 в fido7.ru.crypt ты писал:
VS>> Собственно, не обязательно же отказываться от использования
VS>> УЦ для того, чтобы ввести еще дополнительную проверку по
VS>> сохраненному сертификату.
AV> Hаобормот: проверяем по сертификату, а дополнительно
AV> поглядываем и на CA. Простейший пример: я сгенерировал
AV> сертификат со сроком действия 10 лет (понадобится - продлю) и
AV> ежегодно отправляю в CA на подпись егойный CSR.

Здесь какая-то путаница. Во-первых, на получение CSR УЦ ответит выпуском
ещё одного, нового сертификата, который не пройдёт проверку на
совпадение с используемым ранее.

Во-вторых, выпуск дополнительных сертификатов на тот же самый ключ, без
протокола подтверждения владения закрытым ключом на момент повторного
выпуска CSR и/или штампа времени, ИМХО, не имеет практического смысла, а
поддержка этих протоколов не слишком распространена.

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

VS>> Как я понимаю, расширение к FF, называемое Certificate
VS>> Patrol, именно это и делает.
AV> Hе совсем так, как хотелось бы, но ничего лучше я пока не видел.

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

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Victor Sudakov]

Dear Alexey,

19 Dec 14 12:34, you wrote to me:

[dd]

VS>> Как я понимаю, расширение к FF, называемое Certificate Patrol,
VS>> именно это и делает.

AV> Не совсем так, как хотелось бы, но ничего лучше я пока не видел.

А меня она задалбывает. IMHO слишком часто кричит "Волк, волк!", есть риск
пропустить настоящего волка.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Ivan Shmakov]

VS> Как я понимаю, расширение к FF, называемое Certificate Patrol,
VS> именно это и делает.

AV> Hе совсем так, как хотелось бы, но ничего лучше я пока не видел.

VS> А меня она задалбывает. IMHO слишком часто кричит "Волк, волк!",
VS> есть риск пропустить настоящего волка.

Даже при включенной опции <<проверка только совпадения УЦ>>?

PS. В Emacs (в ветке master) недавно появился некий Network Security
Manager, -- с подобной (AIUI) функциональностью. Hо детально я
его пока не изучал.

[Victor Sudakov]

Dear Ivan,

18 Jan 15 22:25, you wrote to me:

VS>> Как я понимаю, расширение к FF, называемое Certificate Patrol,
VS>> именно это и делает.

AV>> Hе совсем так, как хотелось бы, но ничего лучше я пока не видел.

VS>> А меня она задалбывает. IMHO слишком часто кричит "Волк, волк!",
VS>> есть риск пропустить настоящего волка.

IS> Даже при включенной опции <<проверка только совпадения УЦ>>?

Именно такой опции я в нем не нашел, где там это?
Loading Image...

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Ivan Shmakov]

[...]

VS> IMHO слишком часто кричит "Волк, волк!", есть риск пропустить
VS> настоящего волка.

IS> Даже при включенной опции <<проверка только совпадения УЦ>>?

VS> Именно такой опции я в нем не нашел, где там это?
VS> http://i.imgur.com/yM8rbwT.png?1

Вторая снизу строка диалога <<View details>>; e. g., [1].

[1] Loading Image...

[Victor Sudakov]

Dear Ivan,

19 Jan 15 12:36, you wrote to me:

VS>> IMHO слишком часто кричит "Волк, волк!", есть риск пропустить
VS>> настоящего волка.

IS>> Даже при включенной опции <<проверка только совпадения УЦ>>?

VS>> Именно такой опции я в нем не нашел, где там это?
VS>> http://i.imgur.com/yM8rbwT.png?1

IS> Вторая снизу строка диалога <<View details>>; e. g., [1].

IS> [1] https://am-1.org/~ivan/doc-files/3nCu8DKL.png

Я думал ты глобальную такую опцию нашел. Для отдельного сайта включить можно,
но сайтов много.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Vitaly Zaitsev]

Здpавствуй, Victor!

Понедельник 19 Января 2015 21:43, ты писал(а) Ivan Shmakov:

VS> Я думал ты глобальную такую опцию нашел. Для отдельного сайта включить
VS> можно, но сайтов много.

В Firefox 35 функция Public Key Pinning доступна "из коробки". В базу уже
импортирован белый список Chromium + все сайты mozilla. Также добавлена
поддержка заголовка Public-Key-Pins, в котором любой вебмастер может передавать
список УЦ, которые могут выпускать сертификат его сайта.

---=== Hачало вставки Clipboard ===---

openssl x509 -in cert.pem -pubkey -noout | \
openssl rsa -pubin -outform der | \
openssl dgst -sha256 -binary | openssl enc -base64

---=== Конец вставки Clipboard ===---
---=== Hачало вставки Clipboard ===---

add_header Public-Key-Pins
'pin-sha256="5C8kvU039KouVrl52D0eZSGf4Onjo4Khs8tmyTlV3nU="; max-age=1512000';

---=== Конец вставки Clipboard ===---

Допускается указывать несколько отпечатков УЦ в виде параметра pin-sha256.
Разделитель - точка с запятой.

---=== Hачало вставки Clipboard ===---

add_header Strict-Transport-Security max-age=31536000

---=== Конец вставки Clipboard ===---

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Vitaly,

20 Jan 15 17:55, you wrote to me:

VS>> Я думал ты глобальную такую опцию нашел. Для отдельного сайта
VS>> включить можно, но сайтов много.

VZ> В Firefox 35 функция Public Key Pinning доступна "из коробки". В базу
VZ> уже импортирован белый список Chromium + все сайты mozilla. Также
VZ> добавлена поддержка заголовка Public-Key-Pins, в котором любой
VZ> вебмастер может передавать список УЦ, которые могут выпускать
VZ> сертификат его сайта.

Это круто, но как сделать pinning для произвольного сайта, который не
озаботился вставкой заголовка Public-Key-Pins? Вот хочу сделать для сайта
сбербанка и еще парочки сайтов, и только для них.

Всё-таки сабж - некоторый overkill, надоедает. Ловишь себя на том, что через
некоторое время уже жмешь Accept бездумно.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Vitaly Zaitsev]

Здpавствуй, Victor!

Вторник 20 Января 2015 22:32, ты писал(а) мне:

VS> Это круто, но как сделать pinning для произвольного сайта, который не
VS> озаботился вставкой заголовка Public-Key-Pins?

Пока нельзя, но возможно появится расширение с таким функционалом.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Vitaly,

27 Jan 15 17:37, you wrote to me:
VS>> Это круто, но как сделать pinning для произвольного сайта,
VS>> который не озаботился вставкой заголовка Public-Key-Pins?

VZ> Пока нельзя, но возможно появится расширение с таким функционалом.

Вот это было бы полезно: иметь возможность сделать пинниг только для нескольких
сайтов, параноидальное отношение к которым оправдано. Банки там, paypal
какой-нибудь. А то, что сменился сертификат у какого-нибудь api.twitter.com -
да гори он огнем.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Ivan Shmakov]

[...]

IS> Даже при включенной опции <<проверка только совпадения УЦ>>?

VS> Именно такой опции я в нем не нашел, где там это?
VS> http://i.imgur.com/yM8rbwT.png?1

IS> Вторая снизу строка диалога <<View details>>; e. g., [1].

IS> [1] https://am-1.org/~ivan/doc-files/3nCu8DKL.png

VS> Я думал ты глобальную такую опцию нашел. Для отдельного сайта
VS> включить можно, но сайтов много.

Для каждого -- один раз включить.

Спросил на [2] -- там о такой функции не знают. Есть
подозрение, что искомое реализуемо десятком-другим кодострок на
JavaScript, но вот конкретно в вопросах правки дополнений
Firefox я -- увы -- не специалист.

PS. Системой учета пожеланий и проблем разработчики, похоже, не
озаботились. Равно как и рассылкой.

[2] http://psyced.org:33333/PSYC/?room=patrol

[Vitaly Zaitsev]

Здpавствуй, Victor!

Понедельник 08 Декабря 2014 09:13, ты писал(а) Alexey Vissarionov:

VS> Использование PGP в переписке, к сожалению, так и не вышло за пределы
VS> немногочисленного круга технарей.

Google в начале года сообщали о своей реализации на JavaScript для Gmail. Если
введут, то другие веб-морды быстро скопируют и себе.

С уважением, Vitaly (***@easycoding.org)

[Alexey Vissarionov]

Доброго времени суток, Vitaly!
11 Dec 2014 19:50:02, ты -> Victor Sudakov:

VS>> Использование PGP в переписке, к сожалению, так и не вышло за
VS>> пределы немногочисленного круга технарей.
VZ> Google в начале года сообщали о своей реализации на JavaScript
VZ> для Gmail. Если введут, то другие веб-морды быстро скопируют и
VZ> себе.

PGP в исполнении Google - это даже не профанация...


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-cmlxxvii-mmxlviii

... Не обижайся, если тебя назвали дураком - обижайся, если угадали

[Serguei E. Leontiev]

Виктор привет,

Post by Victor Sudakov
*Любой* УЦ может и не прогнется под органы.

Почему в будущем времени? Конечно, DigiNotar сдали после скандала в
результате атак на Иран, но боюсь, что его на самом деле сдали в рамках
конкурентной борьбы "хозяйствующих" субъектов. :) А вот тот же Trustwave
не сдают и не выкидывают:

https://bugzilla.mozilla.org/show_bug.cgi?id=724929

А думаешь они одни такие выпускали и выпускают сертификаты для
специализированных подчинённых УЦ?

Post by Victor Sudakov
но беда всей системы доверия в WWW

Беда в том, что X.509 был задуман для иерархии ISO/IEC X.500/X.400/LDAP, а
используют его для иерархии DNS без должного приспособления. В частности,
любой УЦ может выпустить сертификаты для практически любого TLS, IPsec,
OpenVPN и т.д. узла или S/MIME пользователя.

Хотя на фоне собственно современного состояния протокола TLS/SSL,
сертификаты не выглядят самым слабым звеном.

Post by Victor Sudakov

Post by Alexey Vissarionov
В этом отношении самоподписанные сертификаты оказываются даже
надежнее: если сертификат сервера внезапно поменялся (без

А без сертификатов, шифрования и ЭЦП ещё надёжнее, всё строго, что на
витрине, то и в магазине, без обмана. :)

Post by Victor Sudakov
А еще есть проекты по публикации SSL сертификтов прямо в DNS (разумеется в
защищенном DNSSEC), тогда все централизованные УЦ становятся просто не нужны.

Это ж вряд ли, ИМХО, станет только хуже, т.к. просто появится ещё одна
точка для нарушений, дополнительно к самому УЦ с его инфраструктурой
прибавятся ещё и DNS сервера.

Вариант DNSSEC без сертификатов мог бы быть и не плох, если бы его
нормально спроектировали.

[Victor Sudakov]

Dear Serguei,

Post by Victor Sudakov
*Любой* УЦ может и не прогнется под органы.

SL> Почему в будущем времени? Конечно, DigiNotar сдали после скандала в
SL> результате атак на Иран, но боюсь, что его на самом деле сдали в
SL> рамках конкурентной борьбы "хозяйствующих" субъектов. :) А вот тот же
SL> Trustwave не сдают и не выкидывают:

SL> https://bugzilla.mozilla.org/show_bug.cgi?id=724929

Там много буков. К чему там пришли в конце концов?

SL> А думаешь они одни такие выпускали и выпускают сертификаты для
SL> специализированных подчинённых УЦ?

Post by Victor Sudakov
но беда всей системы доверия в WWW

SL> Беда в том, что X.509 был задуман для иерархии ISO/IEC
SL> X.500/X.400/LDAP, а используют его для иерархии DNS без должного
SL> приспособления. В частности, любой УЦ может выпустить сертификаты для
SL> практически любого TLS, IPsec, OpenVPN и т.д. узла или S/MIME
SL> пользователя.

Вот мне и кажется, что если привязать сертификаты сайтов к DNS - будет лучше.

SL> Хотя на фоне собственно современного состояния протокола TLS/SSL,
SL> сертификаты не выглядят самым слабым звеном.

Post by Victor Sudakov

Post by Alexey Vissarionov
В этом отношении самоподписанные сертификаты оказываются даже
надежнее: если сертификат сервера внезапно поменялся (без

SL> А без сертификатов, шифрования и ЭЦП ещё надёжнее, всё строго, что на
SL> витрине, то и в магазине, без обмана. :)

Про "самоподписанные сертификаты надежнее" была не моя реплика.
Но зерно истины в этом есть, серверному ssh-отпечатку я как-то верю.

Post by Victor Sudakov
А еще есть проекты по публикации SSL сертификтов прямо в DNS
(разумеется в защищенном DNSSEC), тогда все централизованные УЦ
становятся просто не нужны.

SL> Это ж вряд ли, ИМХО, станет только хуже, т.к. просто появится ещё одна
SL> точка для нарушений, дополнительно к самому УЦ с его инфраструктурой
SL> прибавятся ещё и DNS сервера.

Не дополнительно. УЦ с его инфраструктурой будут не нужны в этой модели.

SL> Вариант DNSSEC без сертификатов мог бы быть и не плох, если бы его
SL> нормально спроектировали.

Не понял, как это "DNSSEC без сертификатов".

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Serguei E. Leontiev]

Привет Виктор,

От 3 декабря 2014 г., 9:50:52 в fido7.ru.crypt ты писал:
??>>> *Любой* УЦ может и не прогнется под органы.
SL>> Почему в будущем времени? Конечно, DigiNotar сдали после
SL>> скандала в результате атак на Иран, но боюсь, что его на
SL>> самом деле сдали в рамках конкурентной борьбы
SL>> "хозяйствующих" субъектов. :) А вот тот же Trustwave не
SL>> сдают и не выкидывают:
SL>> https://bugzilla.mozilla.org/show_bug.cgi?id=724929
VS> Там много буков. К чему там пришли в конце концов?

ИМХО, Status: RESOLVED WONTFIX, - не удалять.

SL>> Беда в том, что X.509 был задуман для иерархии ISO/IEC
SL>> X.500/X.400/LDAP, а используют его для иерархии DNS без
SL>> должного приспособления. В частности, любой УЦ может
SL>> выпустить сертификаты для практически любого TLS, IPsec,
SL>> OpenVPN и т.д. узла или S/MIME пользователя.
VS> Вот мне и кажется, что если привязать сертификаты сайтов к DNS
VS> - будет лучше.

Это ж вряд ли:) Честно говоря, я DNSSEC не изучал, не читал, но осуждаю
эти излишние сложности. :)

Тем более, что вряд ли жесткая привязка будет пользоваться популярностью
в народе, наверняка же будут определять доверенные сертификаты УЦ, и не
по одному.

??>>>> В этом отношении самоподписанные сертификаты
??>>>> оказываются даже надежнее: если сертификат сервера
??>>>> внезапно поменялся (без
SL>> А без сертификатов, шифрования и ЭЦП ещё надёжнее, всё
SL>> строго, что на витрине, то и в магазине, без обмана. :)
VS> Про "самоподписанные сертификаты надежнее" была не моя реплика.
VS> Hо зерно истины в этом есть, серверному ssh-отпечатку я как-то
VS> верю.

Думаю зря веришь.

??>>> А еще есть проекты по публикации SSL сертификтов прямо
??>>> в DNS (разумеется в защищенном DNSSEC), тогда все
??>>> централизованные УЦ становятся просто не нужны.
SL>> Это ж вряд ли, ИМХО, станет только хуже, т.к. просто
SL>> появится ещё одна точка для нарушений, дополнительно к
SL>> самому УЦ с его инфраструктурой прибавятся ещё и DNS
SL>> сервера.
VS> Hе дополнительно. УЦ с его инфраструктурой будут не нужны в
VS> этой модели.

А сертификаты откуда возьмутся? CRL, OCSP?

SL>> Вариант DNSSEC без сертификатов мог бы быть и не плох, если
SL>> бы его нормально спроектировали.
VS> Hе понял, как это "DNSSEC без сертификатов".

Когда публикуются и используются только открытые ключи и для DNS
серверов сертификатов не выпускают.


--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Ivan Shmakov]

[...]

SL> Беда в том, что X.509 был задуман для иерархии ISO/IEC
SL> X.500/X.400/LDAP, а используют его для иерархии DNS без должного
SL> приспособления. В частности, любой УЦ может выпустить сертификаты
SL> для практически любого TLS, IPsec, OpenVPN и т. д. узла

В <<классическом>> варианте настройки, OpenVPN знает лишь один
УЦ -- тот, которым управляет администратор данной OpenVPN-сети.

SL> или S/MIME пользователя.

VS> Вот мне и кажется, что если привязать сертификаты сайтов к DNS -
VS> будет лучше.

СЕЛ> Это ж вряд ли :)

Поддерживаю. Важно не столько то, что у интересующего ресурса
URI вида https://mysavingsbank.com/, сколько то, что в CN его
сертификата имеется строка вида <<CJSC My Savings Bank>>. Чего
<<привязкой к DNS>> не обеспечить.

СЕЛ> Честно говоря, я DNSSEC не изучал, не читал, но осуждаю эти
СЕЛ> излишние сложности. :)

Это какие-это там сложности?

[...]

SL> Вариант DNSSEC без сертификатов мог бы быть и не плох, если бы его
SL> нормально спроектировали.

VS> Hе понял, как это "DNSSEC без сертификатов".

СЕЛ> Когда публикуются и используются только открытые ключи и для DNS
СЕЛ> серверов сертификатов не выпускают.

В варианте RFC 4033..4035, DNSSEC использует только открытые
ключи, -- никаких сертификатов не предусматривается. Тем более
-- для /DNS/-серверов.

Другое дело, что DANE позволяет заверить X.509-сертификат (для
использования HTTPS, ESMTPS, etc.) ключом из DNSSEC.

[Vitaly Zaitsev]

Здpавствуй, Victor!

Вторник 02 Декабря 2014 22:23, ты писал(а) Alexey Vissarionov:

VS> но беда всей системы доверия в WWW в том, что достаточно прогнуться
VS> только *одному* УЦ из сотни установленных в наших браузерах. Т.е. вся
VS> система не более заслуживает доверия, чем ее самое слабое звено.

Ты что, пользуешься предустановленными? Это же небезопасно. Следует снести
оттуда всё и сформировать свой собственный.

VS> Вот в Firefox в качестве доверенного, среди прочих, установлен
VS> сертификат какого-то Чунгва Телеком. Кто эти люди? Почему я им должен
VS> доверять?

Удали его из доверенных. Делов-то.

С уважением, Vitaly (***@easycoding.org)

[Vitaly Zaitsev]

Здpавствуй, Alexey!

Вторник 02 Декабря 2014 18:18, ты писал(а) Serguei E. Leontiev:

AV> Hикак оно не обеспечивается... любой УЦ по запросу "органов" выпустит
AV> левый сертификат для любого домена. В полном соответствии с законом,
AV> ага.

К счастью, в списке доверенных CA нет ни одного российского, а американские и
европейские пошлют местных цензурщиков подальше.

С уважением, Vitaly (***@easycoding.org)

[Victor Sudakov]

Dear Serguei,

Post by Vitaly Zaitsev
SEL> Почему? В чём проблема?
1. Провайдер должен предоставлять трубу и никак не вмешиваться в
трафик абонента.

SL> "должен" в данном контексте это юридический термин или некое
SL> "понятие"? Оно требует пояснения.

Я бы сказал, что это некоторый принцип, называемый Net neutrality
https://en.wikipedia.org/wiki/Net_neutrality

В виде закона, насколько я понимаю, в большинстве стран он не оформлен, по
крайней мере в явном виде.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

[Vitaly Zaitsev]

Здpавствуй, Serguei!

Вторник 02 Декабря 2014 16:59, ты писал(а) мне:

SEL> "должен" в данном контексте это юридический термин или некое
SEL> "понятие"? Оно требует пояснения.

ФЗ "О связи".

С уважением, Vitaly (***@easycoding.org)

[Serguei E. Leontiev]

Привет Сергей,

От 27 ноября 2014 г., 15:04:10 в fido7.ru.crypt ты писал:
SZ> данный момент взлом траффика шифрованного ключами до 2кбит по
SZ> времени занимает до 4 секунд.
SZ> правда это или таки сабж?

За 4 секунды ключи RSA до 2048 бит для SSL/TLS серверов общего
пользования пока не слышал. Есть более подробные описания этих слухов?

Hе очень понятно, о чём идёт речь, в принципе, такое возможно, как
минимум, при наличии хорошего канала от нарушителя к серверу (например
смотри <http://eprint.iacr.org/2003/052.pdf> и Boneh, D., Brumley, D.,
"Remote timing attacks are practical", USENIX Security Symposium 2003).
Т.к. OAEP в SSL/TLS не используется, возможны улучшения в этих атаках.

Были сообщения об атаках с похожими временами на смарт-карты.

Кроме того в дополнении предыдущим сообщениям следует отметить следующие
моменты:

1. Все CipherSuite всех используемых версий, и SSL 3.0, и TLS
1.0/1.1/1.2 в названия которых входит CBC
(TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA и др.)
имеют проблемы в части атак с помощью измерения времени обработки.
Правда это не 4 секунды, а минуты или даже часы;

2. Атаки типа "человек по середине" (MITM) могут быть заметно
изощрённее. Т.к. говорят, что некоторые из удостоверяющих центров (CA),
которые входят в предустановленные доверенные корневые УЦ FireFox и др.
до сих пор выдают сертификаты подчинённых УЦ. Соответственно, если не
используется аутентификация клиента по сертификату, то появляется
простая возможность полного обмана TLS клиента, как это было несколько
лет назад с каким-то взломанным УЦ (не помню название, быть может, ??
Trustwave ??). Hо это опять не 4 сек, а миллисекунды;

3. Сейчас получает распространение метод кэширования TLS сессий по RFC
4507/RFC 5077, в котором, клиент сам хранит и предоставляет защищённый
билет сессии (SessionTicket TLS Extension). Т.к. данные RFC не
определяют конкретные способы защиты информации о сессии, то разные
реализации TLS серверов реализуют его по разному, возможно, что и с
неправильным использованием AES-CBC. Сообщений о таких проблемах я ещё
не слышал, но они могут появиться в любой момент.

ИМХО, советы для параноиков:
1. Соблюдать хотя бы обычные ограничения на длины ключей
<http://www.keylength.com>;
2. Оставить только необходимые корневые сертификаты;
3. Оставить только хорошие CipherSuite (например,
TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_GOSTR341001_WITH_28147_CNT_IMIT);
4. Запретить согласование всяких "левых" расширений.

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Dmitry Miloserdov]

Post by Serguei E. Leontiev
2. Атаки типа "человек по середине" (MITM) могут быть заметно
изощрённее. Т.к. говорят, что некоторые из удостоверяющих центров (CA),
которые входят в предустановленные доверенные корневые УЦ FireFox и др.
до сих пор выдают сертификаты подчинённых УЦ. Соответственно, если не
используется аутентификация клиента по сертификату, то появляется
простая возможность полного обмана TLS клиента, как это было несколько
лет назад с каким-то взломанным УЦ

Может кто-нибудь поможет объяснить ситуацию.
Hекоторое время назад возник вопрос как с ssl работает сервис cloudflare.com
Он для соединений с клиентом выдавал свой сертификат и ни один браузер
на это не ругался.
Для примера использовал сайт https://unmitigatedrisk.com/
Я смог добиться аналогичного поведения на своем сервере в хроме но
через некоторое время браузер обновился и на мой сайт хром теперь
ругается. С https://unmitigatedrisk.com/ по-прежнему все ок.
Сейчас я не могу получить сертификат сайта:
запускаю wget -d https://unmitigatedrisk.com/
(результаты в конце чтоб не рвать текст мусором )
Смотрю адрес куда соединялся wget и пытаюсь соединиться явно
wget -d https://104.28.19.111/
В результате пролучаю что по одному и тому же адресу
отвечают с разными сертификатами.
успешно с CN=sni10012.cloudflaressl.com
неуспешно с CN=ssl2000.cloudflare.com
через openssl s_clinet -connect unmitigatedrisk.com:443
тоже получаю unmitigatedrisk.com и не вижу там что-то
что могло бы сравниться с DNS:unmitigatedrisk.com

Hа мой взгляд тут какая-то дыра.





$ wget -d https://unmitigatedrisk.com/
DEBUG output created by Wget 1.15 on linux-gnu.

URI encoding = 'ANSI_X3.4-1968'
--2014-12-02 16:28:47-- https://unmitigatedrisk.com/
Resolving unmitigatedrisk.com (unmitigatedrisk.com)... 104.28.19.111,
104.28.18.111
Caching unmitigatedrisk.com => 104.28.19.111 104.28.18.111
Connecting to unmitigatedrisk.com
(unmitigatedrisk.com)|104.28.19.111|:443... connected.
Created socket 3.
Releasing 0x0000000000df6810 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x0000000000df6ad0
certificate:
subject: /OU=Domain Control Validated/OU=PositiveSSL
Multi-Domain/CN=sni10012.cloudflaressl.com
issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
X509 certificate successfully verified and matches host unmitigatedrisk.com
[ ... ]

$ wget -d https://104.28.19.111/
DEBUG output created by Wget 1.15 on linux-gnu.

URI encoding = 'ANSI_X3.4-1968'
--2014-12-02 17:07:46-- https://104.28.19.111/
Connecting to 104.28.19.111:443... connected.
Created socket 3.
Releasing 0x0000000001c44980 (new refcount 0).
Deleting unused 0x0000000001c44980.
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x0000000001c449d0
certificate:
subject: /C=US/ST=CA/L=San Francisco/O=CloudFlare,
Inc./CN=ssl2000.cloudflare.com
issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization
Validation CA - G2
ERROR: certificate common name 'ssl2000.cloudflare.com' doesn't
match requested host name '104.28.19.111'.
To connect to 104.28.19.111 insecurely, use `--no-check-certificate'.
Closed 3/SSL 0x0000000001c449d0

[Serguei E. Leontiev]

Привет Дмитрий,

От 2 декабря 2014 г., 17:23:38 в fido7.ru.crypt ты писал:
DM> В результате пролучаю что по одному и тому же адресу
DM> отвечают с разными сертификатами.

Я думаю это нехорошо, что разные, но они, вероятно, пытаются обеспечить
некоторую работоспособность "старых" или "тупых" клиентов.

Сервер рассчитан на получение в первом сообщении "Client Hello"
расширения Server Name Indication протокола TLS. Т.к. многие browser-ы
его посылают, то у них обычно всё работает с первого раза.

DM> успешно с CN=sni10012.cloudflaressl.com
DM> неуспешно с CN=ssl2000.cloudflare.com
DM> через openssl s_clinet -connect unmitigatedrisk.com:443
DM> тоже получаю unmitigatedrisk.com и не вижу там что-то
DM> что могло бы сравниться с DNS:unmitigatedrisk.com

За wget не помню, а у s_client есть ключ `-servername' (man s_client).

DM> Hа мой взгляд тут какая-то дыра.

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

--
Успехов, Сергей Леонтьев. E-mail: ***@CryptoPro.ru

[Vitaly Zaitsev]

Здpавствуй, Dmitry!

Вторник 02 Декабря 2014 17:23, ты писал(а) Serguei E. Leontiev:

DM> Может кто-нибудь поможет объяснить ситуацию.
DM> Hекоторое время назад возник вопрос как с ssl работает сервис
DM> cloudflare.com Он для соединений с клиентом выдавал свой сертификат и
DM> ни один браузер на это не ругался.

Они выдают один сертификат сразу для кучи доменов, привязанных к их сервису.
Используется SNI, поэтому в старых браузерах вроде IE6 будут проблемы.

Сертификат подписан Comodo CA, который имеется в списке доверенных большинства
браузеров.

DM> Hа мой взгляд тут какая-то дыра.

Hет никакой дыры.

DM> Multi-Domain/CN=sni10012.cloudflaressl.com

^^^^^^^^^^^^ ключевое слово.

DM> ERROR: certificate common name 'ssl2000.cloudflare.com' doesn't
DM> match requested host name '104.28.19.111'.

Обращаешься по IP что-ли?

С уважением, Vitaly (***@easycoding.org)

[Maxim Gribanov]

Привет, Sergey!

27 ноя 14 15:04, Sergey Zabolotny -> All:

SZ> Hello *All.*

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

SZ> правда это или таки сабж?

Подмена сертификатов. Между прочим этом метод использцется и всеми DLP
системами использующими web снифер.
С наилучшими пожеланиями, Maxim.