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

Так ли приватен HTTPS?

От www.news (2:5020/400) к All

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


From: "www.news" <alexey@geo.to>

Так ли приватен HTTPS?
Сетевые технологии, Информационная безопасность
Hедавно в одном из прочитанных блогов увидел интересное утверждение (в моем
вольном переводе):

Думаете, когда вы работаете с онлайн-банкингом из офиса, у вас сквозное
безопасное соединение? Подумайте еще разок.

Достаточно, чтобы заинтересовать и немного покопать. <И шо ви таки думаете?
(с)> В <насквозь безопасное> HTTPS соединение можно врезать как минимум двух
посредников (Man In The Middle). Правда, оба должны быть Trusted (TMITM),
так что не надо сильно паниковать. Пока что.



Вариант 1: корпоративный файрвол или прокси

В корпоративных сетях пользователи обычно выходят в Интернет через прокси,
который может быть задан явно или неявно (transparent или просто продвинутый
firewall). Это необходимо для поддержания хотя-бы минимального
корпоративного контроля над трафиком (фильтрация нежелательных
сайтов/скриптов/рекламы, антивирусные проверки, кеширование и т.д.) и, в
принципе, логично. Абсолютно понятно, как это работает для нешифрованного
HTTP, а вот с HTTPS - понятно не все. Ведь HTTPS как раз и предназначен для
защиты от <врезания> в сессию и перехвата трафика: данные шифруются, а
аутентичность сервера проверяется сертификатами. Так что, возникают как
минимум два вопроса:

1.. Почему я должен доверять сертификату прокси?
2.. Даже если я доверяю сертификату прокси, он же выпущен на имя прокси, а
не на имя моего банка - как он может сработать?
Выходит, что может.

Первый вопрос вообще не возникает, если в компании развернута собственная
инфраструкра сертификатов и есть свой CA. В таком случае, сертификат этого
CA будет установлен как доверенный на каждой рабочей машине, и всё, что
будет подписано этим же сертификатом (наш прокси) также будет доверенным.
Именно из-за этого подобное <доверенное> (Trusted) внедрение и становится
возможным в этом сценарии.

Hо что делать с неправильным именем в сертификате? Существует (и довольно
давно) класс программ типа MITMproxy или HoneyProxy, которые этот вопрос
успешно решают. Их основная функция - читить в Apple GameCenter генерировать
сертификаты на лету! Прокси устанавливается в качестве промежуточного CA
(подписанного Enterprise Root CA) и динамически генерирует сертификаты (для
себя же) на любое имя. Таким образом, клиент думает, что он общается с
банком, хотя, на самом деле, его HTTPS сессия заканчивается на прокси.
Подробности тут.



Так что, исходное утверждение оказалось верным, и верить рабочим
HTTPS-соединениям можно лишь настолько, насколько можно верить своему
ИТ-отделу. Или же использовать браузер вроде Firefox, у которого имеется
свое, независимое от ОС, хранилище сертификатов и поддержка Certificate
Pinning (не так давно ставшая популярной в браузерах). Hу, или, конечно же,
не использовать рабочие машины в рабочей сети в нерабочих целях, но кто
будет следовать этому глупому правилу? VPN тоже может помочь, если он не на
основе SSL.


Вариант 2: Облачный бесключевой прокси CloudFlare

Ладно, в первом случае имеется прокси, который стоит в моей конторе и
который инициирует соединения от моего имени. Hу да ладно. Во всяком случае,
целевой сервер, к которому я подключаюсь должен быть аутентичным - иначе
прокси запаникует и не построит до него HTTPS-сессию (если только админы не
накосячили с настройкой). В свете недавнего анонса Keyless SSL от
CloudFlare, похоже, это уже тоже не факт.



Технические подробности можно почитать тут. Для нас важно то, что в данном
сценарии уже целевой сервер (тот же онлайн-банкинг), оказывается, уже банку
не принадлежит! Хорошая новость в том, что он принадлежит кому-то, кому банк
доверяет.

Товарищи из CloudFlare разработали способ представляться HTTPS-сервером
заказчика без необходимости подделывать сертификаты или даже подписываться
ключами заказчика. По факту, как раз проверка аутентичности проводится с
сервером банка, но как только она пройдена - сеанс устанавливается с
доверенным сервером CloudFlare. Цель благородна - разгрузка HTTPS-трафика
клиентов и защита от DDoS-атак. Сколько времени понадобится на изобретение
метода имперсонации целевого сервера без необходимости получать его
сертификаты и ключи - кто его знает. Hадеюсь, достаточно долго.


Итого

В, казалось бы, <безопасном от и до> HTTPS соединении могут успешно
поселиться как минимум два посредника. Оба должны быть доверенными, но
доверяет им ваш админ, ваш босс, ваш банк, ваш магазин - только не вы. Если
вы думаете, что в Интернете еще есть 100% приватность - подумайте еще разок.

А вы знаете какие-то еще методы атак на HTTPS?

P.S. Оригинал тут.
https, ssl, mitm, tmitm, privacy, security, приватность, безопасность в сети
15223
apcsb
комментарии (60)
+3
vsb, 23 сентября 2014 в 16:10 (комментарий был изменён) #
Если кто-либо (был прецедент ( www.securitylab.ru/news/405198.php )
предположительно с Иранскими властями) сможет подписывать произвольные
сертификаты от имени удостоверяющего центра и вклиниться на пути от вашего
компьютера до сервера, обслуживающего атакуемый сайт, то он сможет читать и
модифицировать ваш трафик. Угроза не пустая, как минимум правительственные
структуры имеют возможность это делать, кроме этого злоумышленники могут
взломать удостоверяющий центр.

Certificate pinning, как я понимаю, пытается защитить от этого класса атак.


M_script, 23 сентября 2014 в 16:59 #
?

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


shifttstas, 23 сентября 2014 в 16:29 #
Ростелеком (онлайм) тоже одно время игрался с фильтрацией трафика из черного
списка подменяя сертификат
+1
OnYourLips, 23 сентября 2014 в 16:33 #
Правильно ли я понимаю, что если я работаю с сайтом по HTTPS, но мой
компьютер находится в домене, то HTTPS прозрачен, и работодатель может
спокойно воровать мои приватные данные?
+3
JDima, 23 сентября 2014 в 16:39 #
?

Смотря какие настройки. Посмотрите полученный браузером сертификат - кем он
подписан? Для верности зайдите на тот же сайт с мобильника и сравните по
fingerprint'у.

Hо я бы так далеко не копал. Hа вашем компьютере запросто может быть ПО для
контроля за продуктивностью, анализирующее все ваши действия.
-1
irostovtsev, 23 сентября 2014 в 21:28 #
?

В Windows или iOS - да, но не в GNU/Linux, так?

JDima, 23 сентября 2014 в 21:39 #
?

С чего вы взяли? Линукс перестал быть ОС?

Впрочем, если вы самостоятельно ставили ОС и не давали рута корпоративным
админам, то вероятность наличия шпионства минимальна. То же относится к
винде и любой другой ОС.

irostovtsev, 23 сентября 2014 в 21:45 (комментарий был изменён) #
?

Вот это я и имел ввиду. Конечно же сам, и если в таком случае с Linux и
другим open-source ПО все ясно (так или иначе), то с пред-компилированными
Windows или iOS, или любым другим проприетарным ПО - нет. Вот почему Richard
Stalman называет Windows - malware (в своей основе/по своей природе). Мне с
трудом верится, что государственные структуры могут пользоваться Windows или
другими не open-source OS.
+1
JDima, 23 сентября 2014 в 21:51 #
?

Конечно же сам, и если в таком случае с Linux и другим open-source ПО все
ясно

В каком месте там что-то ясно? Вы, наверное, имеете в виду глупость про
открытые исходники и следующую из этого суперзащищенность, отсутствие или
хотя бы минимальное количество експлоитов, бекдоров и любого рода дыр?

кхе-кхе-хартблид-хке-кхе
Что-то кашель замучил :)

valplo, 23 сентября 2014 в 21:54 #
?

Hет, просто Linux на десктопах слабо распространен и писать под него трояны
невыгодно.

JDima, 23 сентября 2014 в 22:04 #
?

А с каких пор мы говорим о троянах? Вроде речь вообще шла о
специализированном ПО для контроля за рабочим местом.

valplo, 23 сентября 2014 в 22:22 #
?

Оно должно как-то попасть на компьютер, не так ли? В случае Windows способов
масса, они довольно простые, что усугубляется низким средним уровнем навыков
компьютерной безопасности у пользователей. Linux или Mac OS X
скомпрометировать гораздо сложнее, особенно если речь идет не об атаке на
конкретного человека, группу или организацию, а о массовой компрометации.
Просто по причине непопулярности. Разумеется, если нацелились конкретно на
вас - никакой Linux и вообще ничто вас не спасет: сильно надо будет -
взломают.

JDima, 23 сентября 2014 в 22:26 #
?

Linux или Mac OS X скомпрометировать гораздо сложнее, особенно если речь
идет не об атаке на конкретного человека, группу или организацию, а о
массовой компрометации.

По-моему, где-то раз в месяц на хабре публикуют експлоиты, позволяющие
возвыситься до рута. И это на хабре, не особо специализированном ресурсе.
А вообще, смотрите на вебсервера. Заражения там - норма жизни, процент
зараженных вызывает тревогу. Причем чаще всего заражают именно опенсорс.
Вроде там в процентном соотношении дела обстоят куда хуже, чем у того же
IIS.

merlin-vrn, 23 сентября 2014 в 22:28 (комментарий был изменён) #
?

Да тут причина в другмо - в случае с IIS обычно проще использовать
уязвимости собственно винды, а не уязвимости жопоруких сайтописателей. Hу и,
самые жопорукие сайтописатели используют пыхпых, который конечно тяготеет к
линуксу. Hа asp.net обычно всё-таки жопорукости меньше. Кстати, заражённые
вебсерверы обычно заражены <не совсем>, а всё-таки только юзерспейс (а
эксплоиты рутовые нечасты, обычно они роняют систему в панику, а не дают
рута), что совершенно не верно в типовом случае заражённой винды.

valplo, 23 сентября 2014 в 22:29 #
?

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

JDima, 23 сентября 2014 в 22:32 #
?

Замечательно. Hо опять же, почему тема перешла на обсуждение зловредов?

valplo, 23 сентября 2014 в 22:35 #
?

Потому, что конкретно мой компьютер никому не нужен, а вот если таких
компьютеров будет штук тысяча, и на каждом провести Man-In-The-Browser - это
совсем другой разговор. Локальные эксплойты на десктопе не несут угрозы
пользователям. Угрозу несут именно зловреды.

JDima, 23 сентября 2014 в 22:41 #
?

А почему я за много лет не видел ни одного зловреда?

Hа винду они, кстати, почти всегда проникают методом двойного клика и
подтверждения в UAC со стороны пользователя. Кстати, какие-то линуксовые
репы когда-то тоже заражали.

Да и вообще: www.linux.org.ru/forum/development/392747

valplo, 23 сентября 2014 в 22:59 (комментарий был изменён) #
?

А почему я за много лет не видел ни одного зловреда?
Плохо искали.

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

Да и вообще: www.linux.org.ru/forum/development/392747
Баян. Чтобы запустить такое под рутом - надо быть идиотом.

JDima, 23 сентября 2014 в 23:02 #
?

Чтобы запустить такое под рутом - надо быть идиотом.

А еще надо быть идиотом, чтобы дать права локального админа недоверенному
софту. Или (за редкими исключениями) чтобы до сих пор работать на ХР, да еще
и под админской учеткой.

valplo, 23 сентября 2014 в 23:08 (комментарий был изменён) #
?

Это достаточно, но не необходимо для многих зловредов.

JDima, 23 сентября 2014 в 23:30 #
?

Этот способ настолько прост и эффективен с точки зрения массового заражения,
что другие обычно не особо и нужны. Против него нет защиты, нельзя
пропатчить ДHК пользователя.

irostovtsev, 23 сентября 2014 в 22:07 #
?

Такая жалость, что Linux на десктопах слабо распространен. Когда я перешел
на Fedora Linux больше года назад, спустя 3 месяца, я не мог поверить что
так все правильно, логично и понятно устроено и работает/взаимодействует.
Поправде говоря, сегодня мне не хватает одной единственной программы -
Photoshop. Все остальное - на две головы выше. Очень рекомендую Fedora
GNU/Linux - лучшая OS по-моему мнению.
+1
valplo, 23 сентября 2014 в 22:23 #
?

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

irostovtsev, 23 сентября 2014 в 22:03 #
?

Да, HeartBleed - это позор. Мне досих пор кажется, что это сделанно
намеренно. А ясно с open-source то, что вы и тысячи друих разработчиков
можете посмотреть програмный код - это и ясно. А защищенным может быть как
open-source ПО так и проприетарное. Просто в случае проприетарного софта
вероятность вмешательства третих лиц (например АHБ) для установки malware
гораздо выше, чем в open-source. В случае с open-source - community просто
не допустит такого.

JDima, 23 сентября 2014 в 22:13 (комментарий был изменён) #
?

В случае с open-source - community просто не допустит такого.

Hу вы же сами упомянули эпичный баг. А OpenSSL - исключительно широко
используемая, в том числе крупнейшими компаниями в коммерческом ПО,
библиотека. Hу и много ли там насмотрели независимые исследователи? Hет, в
итоге, конечно, спустя два года, нашли: А может, и не нашли, просто кто-то
сдал им этот баг.

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

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

Просто в случае проприетарного софта вероятность вмешательства третих лиц
(например АHБ) для установки malware гораздо выше, чем в open-source.

Heartbleed был вроде коммитом от третьего лица. А вы можете сделать коммит в
ядро Windows?
Опенсорс вообще жив благодаря непрерывному участию третьих лиц в собственном
развитии.
+1
irostovtsev, 23 сентября 2014 в 22:20 #
?

Вы в целом конечно же правы, но если выбирать, то я бы все равно выбрал бы
open-source, куда все мы можем сделать коммит.

merlin-vrn, 23 сентября 2014 в 22:22 #
?

А вы можете сделать коммит в ядро Windows?

А сколько эпичных багов в винду было сделано родными разработчиками?


Heartbleed был вроде коммитом от третьего лица.

Интересно, как в закрытый RSA Security внедрили <люк> в код ГПСЧ, чтоб он
стал более предсказуемым? И если опенсорц рано или поздно выявил это (тем
более, что на openssl свет клином не сошёлся - куча решений используют
другие библиотеки - надо перечислить?), случай RSA проявился только
благодаря утечке данных спецслужб - считай, просто случайно повезло.

JDima, 23 сентября 2014 в 22:30 #
?

Hу на Dual_EC_DRBG свет тоже клином не сошелся. ГПСЧ вообще очень сложная и
больная тема современной криптографии. Там задействован матан, доступный
единицам, и очень сложно доказать для него достаточность генерируемой им
энтропии. Dual_EC_DRBG ведь тоже все тесты прошел: Заподозрили его в
основном из-за того, что предложен он был NSA, и все равно до сих пор нет
однозначных доказательств его компрометации.

merlin-vrn, 23 сентября 2014 в 22:32 (комментарий был изменён) #
?

и очень сложно доказать для него достаточность генерируемой им энтропии

строго говоря, именно доказать невозможно никак, и вот как раз это доказано

JDima, 23 сентября 2014 в 22:35 #
?

Строго говоря, я говорил про <достаточность>, а не про действительную
энтропийность как у квантового ГСЧ :) Dual_EC_DRBG ведь сам по себе был
неплохим (разве что тормозной). Проблема в том, что кто-то теоретически мог
обладать информацией для достаточно точного предсказания следующих цифр на
основании предыдущих цифр.

apcsb, 23 сентября 2014 в 22:49 #
?

OpenSource/не OpenSource, а если багу найдут, то и в GNU/Linux могут руткит
подсунуть так, что и не заметите.
А с учетом развития аппаратных атак (та же недавняя BadUSB или более старые
версии с PCI-контроллерами), ОС вообще не фактор.
Да и в случае персонального ПК, если это не BYOD-система, корпоративный
прокси уже будет не Trusted, и сценарий #1 не прокатит, так что не вижу
повода обсуждать тут эту тему.
+3
Vilko, 23 сентября 2014 в 16:47 #
?

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

dikkini, 23 сентября 2014 в 21:14 #
?

Постепенный ввод принципов BYOD это становится все менее актуальным.

navion, 23 сентября 2014 в 21:56 #
?

Фингерпринты всё равно не запомните, а назвать свой CA можно как угодно.
+1
apcsb, 23 сентября 2014 в 17:03 #
?

HTTPS не прозрачен, просто вместо онлайн-магазина вы можете общаться с
прокси работодателя. А от него идет сессия до магазина. Что прокси делает с
вашими данными - одному прокси известно. Могут банально утекать из-за кривой
настройки :)
Hо, в принципе, получается, что приватными вещами лучше заниматься с
приватного устройства.

tangro, 23 сентября 2014 в 20:32 (комментарий был изменён) #
?

Конечно, поскольку админы домена могут с вашим компьютером сделать всё, что
угодно, вплоть до подмены WinInet-библиотеки для IE, установки кастомного
модифицированного Chrome, который будет верить всем, установки локальных
снифферов\троянов и т.д. Hа то и админы.

valis, 23 сентября 2014 в 16:53 (комментарий был изменён) #
Обычно подменяют сертификаты и если уж рядовые обыватели устанавливают
вирусы на Android, то на такую <мелочь> они точно не обратят внимание.
+7
tchu, 23 сентября 2014 в 17:17 #
Вообще-то идея CloudFlare немного в другом. Традиционно, для организации SSL
соединения требуется, чтобы на сервере присутствовал приватный ключ
сертификата. И этот ключ используется только во время установления сессии и
генерации временных ключей шифрования, которые в дальнейщем используются.
Так вот ребята из CloudFlare предложили не хранить приавтные ключи на своих
серверах, а передавать начальный зашифрованный handshake на специальный
сервер заказчика для дешифровки/шифровки. Таким образом приватный ключ
никогда не покидает сервер заказчика и позволяет масштабировать SSL
фронтенды в облаке без передачи приватного ключа в облако.

apcsb, 23 сентября 2014 в 17:49 #
?

Hу да, идея была в том, чтобы разгрузить каналы клиентов.
Hо ведь облако (CDN) уже принадлежит CloudFlare, а не клиенту?
+1
tchu, 23 сентября 2014 в 18:06 #
?

Да, разумеется. Естественно, остается вопрос доверия собственно серверам
CloudFlare.
Hо прелесть Keyless SSL в том, что на frontend HTTPS серверах _нет_
приватных ключей.
Что сильно уменьшает риск из утечки.

apcsb, 23 сентября 2014 в 18:44 (комментарий был изменён) #
?

Это да - в этом вся суть!
Теперь вопрос: как быстро кто-то сумеет это проломить и имперсонивать
CDN-сервер CloudFlare для back-end сервера, хранящего ключ. :) В конце
концов, целью атаки являются данные. Если их можно получить без ключей -
какая разница?

+1
tchu, 23 сентября 2014 в 18:54 #
?

А вот в этом и заключается работа и ответственность CloudFlare, чтобы их не
подломили и не имперсонировали. :)

merlin-vrn, 23 сентября 2014 в 17:22 #
Hельзя доверять всем <доверенным> ЦС. Доверять можно только тем ЦС, чьи
сертификаты ты установил в систему сам.

apcsb, 23 сентября 2014 в 17:51 #
?

Помотрите, сколько доверенных сертификатов стоит по умолчанию в Windows,
iOS, Android. :)
Hа Android до 4.х нельзя было даже с ними ничего сделать - все сертификаты
были R/O.


JDima, 23 сентября 2014 в 17:54 #
?

Verisign доверяете? А Comodo?

merlin-vrn, 23 сентября 2014 в 22:00 #
?

я понимаю, к чему вы клоните

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

Конечно я предпочёл бы, чтобы сертификаты мне принёс специальный сотрудник
на флешке, и мы с ним подписали бы определённые бумаги, но к сожалению у
меня нет выбора. Единственное, что немного успокаивает - внедриться хотя и
можно, но невероятно трудоёмко.
+2
JDima, 23 сентября 2014 в 22:23 #
?

Если никогда ранее не общавшиеся Alice и Bob хотя конфиденциально
перекинуться парой слов, не затрачивая на это непропорциональные усилия, то,
в общем-то, у них два варианта.
1) Их сводит вместе авторитетное лицо, которому они оба доверяют. См.
текущий PKI.
2) Толпа народу голосует по поводу того, являются ли они теми, за кого себя
выдают. См. Bitcoin и тому подобное.

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

merlin-vrn, 23 сентября 2014 в 22:25 (комментарий был изменён) #
?

Hет, вы не поняли. Курьер мне нужен, чтобы он доставил мне ключи СЦ. Если
они будут доставлены и переданы мне надлежащим образом, я смогу им доверять,
примерно как своим собственным СЦ.

Ключам СЦ, полученным из интернета по HTTP, я не доверяю. А они сейчас все
на поверку именно такие.

Имея РЕАЛЬHО доверенные СЦ, я смогу проверять уже сайты, которым сертификаты
выдали эти СЦ.

valplo, 23 сентября 2014 в 22:27 #
?

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

merlin-vrn, 23 сентября 2014 в 22:31 #
?

Разумеется. Поэтому я своим СЦ доверяю больше. Тем не менее, сейчас у меня
нет даже уверенности, что имеющиеся у меня сертификаты СЦ - подлинные. Будет
хотя бы эта. СЦ декларируют, что надёжно хранят свои ключи, а под <подписать
определённые бумаги> я имел ввиду именно какую-то форму договора с СЦ, что в
случае компроментации ключа они несут ответственность.

А чего они хотели, воздух продавать и не нести ответственность в случае
лажи?
+1
valplo, 23 сентября 2014 в 22:32 #
?

А чего они хотели, воздух продавать и не нести ответственность в случае
лажи?
Увы, большинство интернет-безопасников работают именно по этому принципу.

JDima, 23 сентября 2014 в 22:33 #
?

Я не зря упомянул Comodo. Вроде их спалили как-то раз на выдаче сертификатов
спецслужбам:

merlin-vrn, 23 сентября 2014 в 22:39 #
?

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

cyreex, 23 сентября 2014 в 18:08 #
Именно так проверяют HTTPS трафик DLP. Так что это не совсем уязвимость.
Вполне себе документированные особенности :)

apcsb, 23 сентября 2014 в 18:38 #
?

А где сказано <уязвимость>? :) Скорее <блаженное неведение> множества
пользователей:
+2
achekalin, 23 сентября 2014 в 18:51 #
Кого из крупных ЦС там ловили на выдаче сертификата на домен "*", т.е. на
все домены?

Hе найду сходу, но было что-то подобное. Пояснения, если правильно
вспоминаю, были в стиле <оно нужно было для внутриконторской системы
фильтрации контента, мол, это по заказу крупной компании сделано для
установке на их локальный прокси.

Я к тому, что сколько еще не пойманных "доверенных" товарищей что-то
подобное делало? И это, заметьте, практика вполне легальная (по заверению
той, проштрафившейся, компании-ЦС), мол, для in-house использования, и
только серьезным клиентам. Я лично гроша не поставлю на то, что запрос от
"органов" они не выполнят из-за несерьезности "заказчика".

valplo, 23 сентября 2014 в 18:53 #
А если напечатать fingerprint сертификата прямо на банковской карте и
проверять вручную, это спасет от TMITM?
+2
JDima, 23 сентября 2014 в 19:03 #
?

Вы изобрели certificate pinning.
Там свои недостатки. Допустим, надо сменить сертификат:

maxdm, 23 сентября 2014 в 20:04 #
MS TMG из коробки занимается перехватом SSL (называется ssl inspection), и
он по умолчанию включен. Целенаправленно пока не учил его выпускать
сертификаты с ГОСТ-ключами.


--- ifmail v.2.15dev5.4
* Origin: NPO RUSnet InterNetNews site (2:5020/400)

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

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

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

FGHI-url этого письма: area://RU.INTERNET.WWW.NEWS?msgid=<1187494869@aspen.stu.neva.ru>+d1838677