Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 123
Ростелеком (онлайм) тоже одно время игрался с фильтрацией трафика из черного списка подменяя сертификат
Смотря какие настройки. Посмотрите полученный браузером сертификат — кем он подписан? Для верности зайдите на тот же сайт с мобильника и сравните по fingerprint'у.
Но я бы так далеко не копал. На вашем компьютере запросто может быть ПО для контроля за продуктивностью, анализирующее все ваши действия.
Но я бы так далеко не копал. На вашем компьютере запросто может быть ПО для контроля за продуктивностью, анализирующее все ваши действия.
В Windows или iOS — да, но не в GNU/Linux, так?
С чего вы взяли? Линукс перестал быть ОС?
Впрочем, если вы самостоятельно ставили ОС и не давали рута корпоративным админам, то вероятность наличия шпионства минимальна. То же относится к винде и любой другой ОС.
Впрочем, если вы самостоятельно ставили ОС и не давали рута корпоративным админам, то вероятность наличия шпионства минимальна. То же относится к винде и любой другой ОС.
Вот это я и имел ввиду. Конечно же сам, и если в таком случае с Linux и другим open-source ПО все ясно (так или иначе), то с пред-компилированными Windows или iOS, или любым другим проприетарным ПО — нет. Вот почему Richard Stalman называет Windows — malware (в своей основе/по своей природе). Мне с трудом верится, что государственные структуры могут пользоваться Windows или другими не open-source OS.
Конечно же сам, и если в таком случае с Linux и другим open-source ПО все ясно
В каком месте там что-то ясно? Вы, наверное, имеете в виду глупость про открытые исходники и следующую из этого суперзащищенность, отсутствие или хотя бы минимальное количество експлоитов, бекдоров и любого рода дыр?
кхе-кхе-хартблид-хке-кхе
Что-то кашель замучил :)
Нет, просто Linux на десктопах слабо распространен и писать под него трояны невыгодно.
А с каких пор мы говорим о троянах? Вроде речь вообще шла о специализированном ПО для контроля за рабочим местом.
Оно должно как-то попасть на компьютер, не так ли? В случае Windows способов масса, они довольно простые, что усугубляется низким средним уровнем навыков компьютерной безопасности у пользователей. Linux или Mac OS X скомпрометировать гораздо сложнее, особенно если речь идет не об атаке на конкретного человека, группу или организацию, а о массовой компрометации. Просто по причине непопулярности. Разумеется, если нацелились конкретно на вас — никакой Linux и вообще ничто вас не спасет: сильно надо будет — взломают.
Linux или Mac OS X скомпрометировать гораздо сложнее, особенно если речь идет не об атаке на конкретного человека, группу или организацию, а о массовой компрометации.
По-моему, где-то раз в месяц на хабре публикуют експлоиты, позволяющие возвыситься до рута. И это на хабре, не особо специализированном ресурсе.
А вообще, смотрите на вебсервера. Заражения там — норма жизни, процент зараженных вызывает тревогу. Причем чаще всего заражают именно опенсорс. Вроде там в процентном соотношении дела обстоят куда хуже, чем у того же IIS.
Да тут причина в другмо — в случае с IIS обычно проще использовать уязвимости собственно винды, а не уязвимости жопоруких сайтописателей. Ну и, самые жопорукие сайтописатели используют пыхпых, который конечно тяготеет к линуксу. На asp.net обычно всё-таки жопорукости меньше. Кстати, заражённые вебсерверы обычно заражены «не совсем», а всё-таки только юзерспейс (а эксплоиты рутовые нечасты, обычно они роняют систему в панику, а не дают рута), что совершенно не верно в типовом случае заражённой винды.
Я не говорю, что эксплойтов не существует. Я говорю, что массовые заражения десктопов (а полезные нагрузки у десктопного и серверного зловреда принципиально разные) — экономически невыгодны ботоводам, и, следовательно, риск заражения гораздо меньше.
Замечательно. Но опять же, почему тема перешла на обсуждение зловредов?
Потому, что конкретно мой компьютер никому не нужен, а вот если таких компьютеров будет штук тысяча, и на каждом провести Man-In-The-Browser — это совсем другой разговор. Локальные эксплойты на десктопе не несут угрозы пользователям. Угрозу несут именно зловреды.
А почему я за много лет не видел ни одного зловреда?
На винду они, кстати, почти всегда проникают методом двойного клика и подтверждения в UAC со стороны пользователя. Кстати, какие-то линуксовые репы когда-то тоже заражали.
Да и вообще… www.linux.org.ru/forum/development/392747
На винду они, кстати, почти всегда проникают методом двойного клика и подтверждения в UAC со стороны пользователя. Кстати, какие-то линуксовые репы когда-то тоже заражали.
Да и вообще… www.linux.org.ru/forum/development/392747
А почему я за много лет не видел ни одного зловреда?Плохо искали.
На винду они, кстати, почти всегда проникают методом двойного клика и подтверждения в UAC со стороны пользователя.Не все, особенно на XP (которую многие отдельные одаренные личности вовсю используют).
Да и вообще… www.linux.org.ru/forum/development/392747Баян. Чтобы запустить такое под рутом — надо быть идиотом.
UAC они уже давно не просят, нафига им полный доступ? Файлики потырят, зашифруют и деньги попросят, им для этого не надо никаких полномочий кроме пользовательских.
А вообще надо mandatory access control внедрять в массы.
А вообще надо mandatory access control внедрять в массы.
Тут как раз все просто:
1. Компания заботиться о своей корп безопасности, вы рядовой сотрудник => у вас будет или windows или Linux со спец софтом, без него в корпоративную сеть не пустят
2. Компания заботиться о своей корп безопасности, вы доверенный сотрудник => у вас может быть Linux без спец софта, за вашей лояльностью будут следить другими средствами, не связанными с мониторингом сетевой активности (тупо камера наблюдения за спиной).
3. Компания не заботится о своей безопасности: широкий спектр степени сетевого бардака.
Собственно устойчивость той или иной ОС к троянам/бекдорам/активным мониторам рабочего места тут вообще не причем.
1. Компания заботиться о своей корп безопасности, вы рядовой сотрудник => у вас будет или windows или Linux со спец софтом, без него в корпоративную сеть не пустят
2. Компания заботиться о своей корп безопасности, вы доверенный сотрудник => у вас может быть Linux без спец софта, за вашей лояльностью будут следить другими средствами, не связанными с мониторингом сетевой активности (тупо камера наблюдения за спиной).
3. Компания не заботится о своей безопасности: широкий спектр степени сетевого бардака.
Собственно устойчивость той или иной ОС к троянам/бекдорам/активным мониторам рабочего места тут вообще не причем.
Такая жалость, что Linux на десктопах слабо распространен. Когда я перешел на Fedora Linux больше года назад, спустя 3 месяца, я не мог поверить что так все правильно, логично и понятно устроено и работает/взаимодействует. Поправде говоря, сегодня мне не хватает одной единственной программы — Photoshop. Все остальное — на две головы выше. Очень рекомендую Fedora GNU/Linux — лучшая OS по-моему мнению.
Да, HeartBleed — это позор. Мне досих пор кажется, что это сделанно намеренно. А ясно с open-source то, что вы и тысячи друих разработчиков можете посмотреть програмный код — это и ясно. А защищенным может быть как open-source ПО так и проприетарное. Просто в случае проприетарного софта вероятность вмешательства третих лиц (например АНБ) для установки malware гораздо выше, чем в open-source. В случае с open-source — community просто не допустит такого.
В случае с open-source — community просто не допустит такого.
Ну вы же сами упомянули эпичный баг. А OpenSSL — исключительно широко используемая, в том числе крупнейшими компаниями в коммерческом ПО, библиотека. Ну и много ли там насмотрели независимые исследователи? Нет, в итоге, конечно, спустя два года, нашли… А может, и не нашли, просто кто-то сдал им этот баг.
А ясно с open-source то, что вы и тысячи друих разработчиков можете посмотреть програмный код — это и ясно.
Между «могу просматривать» и «буду просматривать» зияет колоссальная пропасть. Обычно у людей найдутся более интересные занятия, чем построчно анализировать десятки тысяч строк кода (можно смотреть даже на куда более менее элегантную, чем heartbleed, дыру, и не видеть ее). Особенно если код — опенсорс, но в основном развивается не сообществом, а конкретными лицами, а такое сплошь и рядом. Вон Truecrypt опенсорс, но до сих пор никто не понимает, есть в нем закладки или нет. Даже специализированных аудиторов нанимали.
Просто в случае проприетарного софта вероятность вмешательства третих лиц (например АНБ) для установки malware гораздо выше, чем в open-source.
Heartbleed был вроде коммитом от третьего лица. А вы можете сделать коммит в ядро Windows?
Опенсорс вообще жив благодаря непрерывному участию третьих лиц в собственном развитии.
Вы в целом конечно же правы, но если выбирать, то я бы все равно выбрал бы open-source, куда все мы можем сделать коммит.
А вы можете сделать коммит в ядро Windows?
А сколько эпичных багов в винду было сделано родными разработчиками?
Heartbleed был вроде коммитом от третьего лица.
Интересно, как в закрытый RSA Security внедрили «люк» в код ГПСЧ, чтоб он стал более предсказуемым? И если опенсорц рано или поздно выявил это (тем более, что на openssl свет клином не сошёлся — куча решений используют другие библиотеки — надо перечислить?), случай RSA проявился только благодаря утечке данных спецслужб — считай, просто случайно повезло.
Ну на Dual_EC_DRBG свет тоже клином не сошелся. ГПСЧ вообще очень сложная и больная тема современной криптографии. Там задействован матан, доступный единицам, и очень сложно доказать для него достаточность генерируемой им энтропии. Dual_EC_DRBG ведь тоже все тесты прошел… Заподозрили его в основном из-за того, что предложен он был NSA, и все равно до сих пор нет однозначных доказательств его компрометации.
и очень сложно доказать для него достаточность генерируемой им энтропии
строго говоря, именно доказать невозможно никак, и вот как раз это доказано
Строго говоря, я говорил про «достаточность», а не про действительную энтропийность как у квантового ГСЧ :) Dual_EC_DRBG ведь сам по себе был неплохим (разве что тормозной). Проблема в том, что кто-то теоретически мог обладать информацией для достаточно точного предсказания следующих цифр на основании предыдущих цифр.
Вообще «если у вас нет паранойи, то это не значит что за вами не следят.»
Есть уверенность что кроме Heartbleed нет других закладок?
Сложность и количество кода библиотек и всей ОС в целом практически исключает полноценный аудит. Проверить отсутствие известных косяков можно… Но неизвестных — практически нереально.
Есть уверенность что кроме Heartbleed нет других закладок?
Сложность и количество кода библиотек и всей ОС в целом практически исключает полноценный аудит. Проверить отсутствие известных косяков можно… Но неизвестных — практически нереально.
OpenSource/не OpenSource, а если багу найдут, то и в GNU/Linux могут руткит подсунуть так, что и не заметите.
А с учетом развития аппаратных атак (та же недавняя BadUSB или более старые версии с PCI-контроллерами), ОС вообще не фактор.
Да и в случае персонального ПК, если это не BYOD-система, корпоративный прокси уже будет не Trusted, и сценарий #1 не прокатит, так что не вижу повода обсуждать тут эту тему.
А с учетом развития аппаратных атак (та же недавняя BadUSB или более старые версии с PCI-контроллерами), ОС вообще не фактор.
Да и в случае персонального ПК, если это не BYOD-система, корпоративный прокси уже будет не Trusted, и сценарий #1 не прокатит, так что не вижу повода обсуждать тут эту тему.
При работе с важными данными (например тот-же онлайн банк), нужно иметь полезную привычку заглядывать в информацию о сертификате для https-сессии, перед тем как вводить пароли.
Постепенный ввод принципов BYOD это становится все менее актуальным.
Фингерпринты всё равно не запомните, а назвать свой CA можно как угодно.
какие-нибудь уникальные красивые 4 цифры фингерпринта вполне достаточно для «ручной проверки» их и запомнить не влом.
Проще заходить в ИБ с телефона.
А если мобильный провайдет тоже занимается такой фигнёй? Или еще хуже… договор с работодателем чтобы заворачивать весь мобильный трафик сотрудников(номера телефонов со временем очень быстро палятся и привязываются к сотрудникам) на ихний проксик… думаешь, такое в принципе невозможно?
HTTPS не прозрачен, просто вместо онлайн-магазина вы можете общаться с прокси работодателя. А от него идет сессия до магазина. Что прокси делает с вашими данными — одному прокси известно. Могут банально утекать из-за кривой настройки :)
Но, в принципе, получается, что приватными вещами лучше заниматься с приватного устройства.
Но, в принципе, получается, что приватными вещами лучше заниматься с приватного устройства.
Конечно, поскольку админы домена могут с вашим компьютером сделать всё, что угодно, вплоть до подмены WinInet-библиотеки для IE, установки кастомного модифицированного Chrome, который будет верить всем, установки локальных снифферов\троянов и т.д. На то и админы.
Обычно подменяют сертификаты и если уж рядовые обыватели устанавливают вирусы на Android, то на такую «мелочь» они точно не обратят внимание.
Вообще-то идея CloudFlare немного в другом. Традиционно, для организации SSL соединения требуется, чтобы на сервере присутствовал приватный ключ сертификата. И этот ключ используется только во время установления сессии и генерации временных ключей шифрования, которые в дальнейщем используются. Так вот ребята из CloudFlare предложили не хранить приавтные ключи на своих серверах, а передавать начальный зашифрованный handshake на специальный сервер заказчика для дешифровки/шифровки. Таким образом приватный ключ никогда не покидает сервер заказчика и позволяет масштабировать SSL фронтенды в облаке без передачи приватного ключа в облако.
Ну да, идея была в том, чтобы разгрузить каналы клиентов.
Но ведь облако (CDN) уже принадлежит CloudFlare, а не клиенту?
Но ведь облако (CDN) уже принадлежит CloudFlare, а не клиенту?
Да, разумеется. Естественно, остается вопрос доверия собственно серверам CloudFlare.
Но прелесть Keyless SSL в том, что на frontend HTTPS серверах _нет_ приватных ключей.
Что сильно уменьшает риск из утечки.
Но прелесть Keyless SSL в том, что на frontend HTTPS серверах _нет_ приватных ключей.
Что сильно уменьшает риск из утечки.
Это да — в этом вся суть!
Теперь вопрос: как быстро кто-то сумеет это проломить и имперсонивать CDN-сервер CloudFlare для back-end сервера, хранящего ключ. :) В конце концов, целью атаки являются данные. Если их можно получить без ключей — какая разница?
Теперь вопрос: как быстро кто-то сумеет это проломить и имперсонивать CDN-сервер CloudFlare для back-end сервера, хранящего ключ. :) В конце концов, целью атаки являются данные. Если их можно получить без ключей — какая разница?
А вот в этом и заключается работа и ответственность CloudFlare, чтобы их не подломили и не имперсонировали. :)
Оно-то да, но мне, как «потенциальному потерпевшему» от этого не легче :)
Возвращаясь к сценарию онлайн-банкинга: если HTTPS действительно 100% надежен между двумя конечными точками, то если меня хакнут и уведут деньги с аккаунта, путей атаки может быть только два:
1. Хакнули мой компьютер — сам виноват (только не надо поднимать тему с дефектами закрытого ПО и т.д. — там всё прикрыто, и в итоге всё равно пользователь сам виноват).
2. Хакнули банк. Тут вероятность вернуть деньги за счет банка близка к 100% (если только банк не пошел ко дну в результате массового взлома :) ).
Таким образом, все факторы или под моим контролем, или не несут серьезного ущерба — мне, как пользователю онлайн-банкинга особо страшиться нечего (именно поэтому, даже когда начались массовые хаки кредитных карт в США, уж сколько лет назад, они не перешли на чипы: банкам дорого, а пользователям все компенсируется).
А вот теперь, давайте включим в HTTPS-цепочку еще двух посредников, и спросим у банка, компенсируют ли они потери, если сессию уведут из-за криворукости админа на работе или косяка в CloudFlare (или какого-нибудь хитрого отвода трафика от их CDN через очередной BGP-poisoning)? Как вы считаете, какова вероятность вернуть деньги в подобном случае, и что на это ответят на работе и в CloudFlare? :)
Возвращаясь к сценарию онлайн-банкинга: если HTTPS действительно 100% надежен между двумя конечными точками, то если меня хакнут и уведут деньги с аккаунта, путей атаки может быть только два:
1. Хакнули мой компьютер — сам виноват (только не надо поднимать тему с дефектами закрытого ПО и т.д. — там всё прикрыто, и в итоге всё равно пользователь сам виноват).
2. Хакнули банк. Тут вероятность вернуть деньги за счет банка близка к 100% (если только банк не пошел ко дну в результате массового взлома :) ).
Таким образом, все факторы или под моим контролем, или не несут серьезного ущерба — мне, как пользователю онлайн-банкинга особо страшиться нечего (именно поэтому, даже когда начались массовые хаки кредитных карт в США, уж сколько лет назад, они не перешли на чипы: банкам дорого, а пользователям все компенсируется).
А вот теперь, давайте включим в HTTPS-цепочку еще двух посредников, и спросим у банка, компенсируют ли они потери, если сессию уведут из-за криворукости админа на работе или косяка в CloudFlare (или какого-нибудь хитрого отвода трафика от их CDN через очередной BGP-poisoning)? Как вы считаете, какова вероятность вернуть деньги в подобном случае, и что на это ответят на работе и в CloudFlare? :)
По моему глубокому убеждению, все приватные ключи должны хранится в HSM, даже для веб-серверов. И все криптографические операции выполнять через API PKCS11. Тогда даже при полном контроле сервера со стороны злоумышленника ключи не будут скомпрометированы, максимум можно будет расшифровать текущие сессии. Но после восстановления контроля над серверами не придется перевыпускать сертификаты + много других преимуществ.
Основная сложность такого решения — скорость работы HSM. Но при грамотном проектировании и разработке проблема решается.
Как только появятся HSM, которые выдерживают от 10 тыс. подписей в секунду, то можно спокойно ставить их в CDN, при этом закрытый ключ сервису будет недоступен, а вот HTTPS будет устанавливаться именно на фронтендах.
Основная сложность такого решения — скорость работы HSM. Но при грамотном проектировании и разработке проблема решается.
Как только появятся HSM, которые выдерживают от 10 тыс. подписей в секунду, то можно спокойно ставить их в CDN, при этом закрытый ключ сервису будет недоступен, а вот HTTPS будет устанавливаться именно на фронтендах.
Да, это решит проблему утечки ключей. Но если данные удастся получить без ключей (см. собственно комментарий, на который вы отвечали), то какая разница? Ну недоступен ключ, и не очень-то и хотелось.
Разница в том, что когда установление HTTPS сессии происходит на фронтенде, а его поломали, то это зона ответственности фронтенда, в данном случае — CloudFlare. И тогда уже действует SLA, компенсации, и т.д., зависит от договора. В описанной выше конфигурации в случае взлома надо проводить исследование и выяснять на каком плече прошла атака.
Второе, так как закрытый ключ не скомпрометирован, то даже если злоумышленник писал все шифрованные сессии на протяжении долгого периода в надежде расшифровать после успешной атаки на сервер (и компрометации ключа), то у него это не получится.
Второе, так как закрытый ключ не скомпрометирован, то даже если злоумышленник писал все шифрованные сессии на протяжении долгого периода в надежде расшифровать после успешной атаки на сервер (и компрометации ключа), то у него это не получится.
Нельзя доверять всем «доверенным» ЦС. Доверять можно только тем ЦС, чьи сертификаты ты установил в систему сам.
Помотрите, сколько доверенных сертификатов стоит по умолчанию в Windows, iOS, Android. :)
На Android до 4.х нельзя было даже с ними ничего сделать — все сертификаты были R/O.
На Android до 4.х нельзя было даже с ними ничего сделать — все сертификаты были R/O.
Verisign доверяете? А Comodo?
я понимаю, к чему вы клоните
Нет, не доверяю. Не больше, чем самоподписанным. Точно меньше, чем самодельным. Я никак не могу быть уверен, действительно ли в моём браузере, скачанном по HTTP, настоящий сертификат комодо и он действительно проверяется, или дистрибутив был по дороге модифицирован. Подпись пакета есть, но сама она тоже получена по HTTP.
Конечно я предпочёл бы, чтобы сертификаты мне принёс специальный сотрудник на флешке, и мы с ним подписали бы определённые бумаги, но к сожалению у меня нет выбора. Единственное, что немного успокаивает — внедриться хотя и можно, но невероятно трудоёмко.
Нет, не доверяю. Не больше, чем самоподписанным. Точно меньше, чем самодельным. Я никак не могу быть уверен, действительно ли в моём браузере, скачанном по HTTP, настоящий сертификат комодо и он действительно проверяется, или дистрибутив был по дороге модифицирован. Подпись пакета есть, но сама она тоже получена по HTTP.
Конечно я предпочёл бы, чтобы сертификаты мне принёс специальный сотрудник на флешке, и мы с ним подписали бы определённые бумаги, но к сожалению у меня нет выбора. Единственное, что немного успокаивает — внедриться хотя и можно, но невероятно трудоёмко.
Если никогда ранее не общавшиеся Alice и Bob хотя конфиденциально перекинуться парой слов, не затрачивая на это непропорциональные усилия, то, в общем-то, у них два варианта.
1) Их сводит вместе авторитетное лицо, которому они оба доверяют. См. текущий PKI.
2) Толпа народу голосует по поводу того, являются ли они теми, за кого себя выдают. См. Bitcoin и тому подобное.
Оба подхода имеют свои проблемы… А то, что вы предлагаете, это третий вариант (изолированный, заранее защищенный канал связи с независимой аутентификацией сторон), который приводит к колоссальным неудобствам, так как курьер вам потребуется для каждого посещаемого вами сайта, и даже это не гарантирует, что кто-то не скоммуниздит у владельца сайта приватные ключи.
1) Их сводит вместе авторитетное лицо, которому они оба доверяют. См. текущий PKI.
2) Толпа народу голосует по поводу того, являются ли они теми, за кого себя выдают. См. Bitcoin и тому подобное.
Оба подхода имеют свои проблемы… А то, что вы предлагаете, это третий вариант (изолированный, заранее защищенный канал связи с независимой аутентификацией сторон), который приводит к колоссальным неудобствам, так как курьер вам потребуется для каждого посещаемого вами сайта, и даже это не гарантирует, что кто-то не скоммуниздит у владельца сайта приватные ключи.
Нет, вы не поняли. Курьер мне нужен, чтобы он доставил мне ключи СЦ. Если они будут доставлены и переданы мне надлежащим образом, я смогу им доверять, примерно как своим собственным СЦ.
Ключам СЦ, полученным из интернета по HTTP, я не доверяю. А они сейчас все на поверку именно такие.
Имея РЕАЛЬНО доверенные СЦ, я смогу проверять уже сайты, которым сертификаты выдали эти СЦ.
Ключам СЦ, полученным из интернета по HTTP, я не доверяю. А они сейчас все на поверку именно такие.
Имея РЕАЛЬНО доверенные СЦ, я смогу проверять уже сайты, которым сертификаты выдали эти СЦ.
Вы можете доверять ключу но не SC. Т. к. никакой гарантии, что злоумышленник не обладает доступом к секретному ключу нет.
Разумеется. Поэтому я своим СЦ доверяю больше. Тем не менее, сейчас у меня нет даже уверенности, что имеющиеся у меня сертификаты СЦ — подлинные. Будет хотя бы эта. СЦ декларируют, что надёжно хранят свои ключи, а под «подписать определённые бумаги» я имел ввиду именно какую-то форму договора с СЦ, что в случае компроментации ключа они несут ответственность.
А чего они хотели, воздух продавать и не нести ответственность в случае лажи?
А чего они хотели, воздух продавать и не нести ответственность в случае лажи?
Именно так проверяют HTTPS трафик DLP. Так что это не совсем уязвимость. Вполне себе документированные особенности :)
Кого из крупных ЦС там ловили на выдаче сертификата на домен "*", т.е. на все домены?
Не найду сходу, но было что-то подобное. Пояснения, если правильно вспоминаю, были в стиле «оно нужно было для внутриконторской системы фильтрации контента, мол, это по заказу крупной компании сделано для установке на их локальный прокси.
Я к тому, что сколько еще не пойманных „доверенных“ товарищей что-то подобное делало? И это, заметьте, практика вполне легальная (по заверению той, проштрафившейся, компании-ЦС), мол, для in-house использования, и только серьезным клиентам. Я лично гроша не поставлю на то, что запрос от „органов“ они не выполнят из-за несерьезности „заказчика“.
Не найду сходу, но было что-то подобное. Пояснения, если правильно вспоминаю, были в стиле «оно нужно было для внутриконторской системы фильтрации контента, мол, это по заказу крупной компании сделано для установке на их локальный прокси.
Я к тому, что сколько еще не пойманных „доверенных“ товарищей что-то подобное делало? И это, заметьте, практика вполне легальная (по заверению той, проштрафившейся, компании-ЦС), мол, для in-house использования, и только серьезным клиентам. Я лично гроша не поставлю на то, что запрос от „органов“ они не выполнят из-за несерьезности „заказчика“.
Поискал, нашел один из таких случаев — когда поймали за руку Trustwave. Они не выдавали сертификат на "*", это я ошибся, они выдали вторичный корневой сертификат, которым можно подписать сертификат для любого домена. Объяснения компании свелись к тому, что он был нужен для системы проксирования и перехвата трафика:
The system was created using dedicated hardware device designed for SSL proxy and acceleration, with a FIPS-140-2 Level 3 compliant Hardware Security Module (HSM) (http://en.wikipedia.org/wiki/Hardware_security_module) for subordinate root storage and for the purpose of private key generation of the re-signed SSL certificates. This means that once the trusted subordinate root was placed into the device it could not be extracted.
(отсюда — blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html )
(Mozilla тогда рассматривала вопрос об исключении корневого сертификата Trustwave из своего списка корневых. Источник: www.opennet.ru/opennews/art.shtml?num=33034 )
The system was created using dedicated hardware device designed for SSL proxy and acceleration, with a FIPS-140-2 Level 3 compliant Hardware Security Module (HSM) (http://en.wikipedia.org/wiki/Hardware_security_module) for subordinate root storage and for the purpose of private key generation of the re-signed SSL certificates. This means that once the trusted subordinate root was placed into the device it could not be extracted.
(отсюда — blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html )
(Mozilla тогда рассматривала вопрос об исключении корневого сертификата Trustwave из своего списка корневых. Источник: www.opennet.ru/opennews/art.shtml?num=33034 )
Может быть я чего-то не понимаю, но у того же Гугла тоже есть свой подчинённый CA, который может подписывать любые сертификаты. А в хранилище сертификатов Firefox оказался сертификат (!) РуЦентра, так что ФСБ давно может читать наш трафик.
К сожалению, да, и это то, что мне всегда в схемах доверия https не нравилось: можно верить https-защите не более, чем веришь корневым сертификатам, а также своей машине или ПО на ней, хранящей эти корневые сертификаты. Если вирус впишет мне сертификат каких-то негодяев, то они смогут MITM реализовать при полной моей уверенности в безопасности.
Уместно привести слова Шнайдера, что, мол, я плачу картой через интернет не потому, что верю, что https меня убережет на 100% или что https как-то гарантирует, что меня не обманет сам магазин, а потому, что в случае косяка магазина за это ответит Visa, которая вернет деньги, а потом разберется с магазином.
Уместно привести слова Шнайдера, что, мол, я плачу картой через интернет не потому, что верю, что https меня убережет на 100% или что https как-то гарантирует, что меня не обманет сам магазин, а потому, что в случае косяка магазина за это ответит Visa, которая вернет деньги, а потом разберется с магазином.
А если напечатать fingerprint сертификата прямо на банковской карте и проверять вручную, это спасет от TMITM?
MS TMG из коробки занимается перехватом SSL (называется ssl inspection), и он по умолчанию включен. Целенаправленно пока не учил его выпускать сертификаты с ГОСТ-ключами.
А объясните плиз тем, кто в танке, как прокси может врезаться в мой трафик, если при HTTPS браузер шлет HTTP CONNECT на 443, а прокси только поднимает TCP туннель? Много раз смотрел tcpdump'ом и не видел других сценариев работы. Как оно еще работать может?
А ты и не увидишь. Проксик внешне для приложения прикидывается шлангом, будто он работает прозрачно… все мутки происходят на другом уровне — уже внутри установленного канала SSL, а проксик является одной из первых точек входа в этот канал…
То есть по факту давно можно влезать в любое SSL соединение?
Не в любое. Только если у клиента есть сертификат того кто производит инспекцию. Т.е. корпоративная среда где пользователь не волен в выборе рабочего софта под это определение подходит.
Ну как давно… примерно с момента разработки SSL соединений)
Браузер шлет CONNECT на mybank.com/443
Пакет перехватывается TMITM прокси
Прокси отвечает «я твой банк»
Браузер строит сессию до прокси
Прокси строит сессию до банка
Но походу вместо одной сессии «браузер-банк» имеем ДВЕ сессии «браузер-прокси» и «прокси-банк». Что прокси делает с трафиком — известно лишь прокси.
Аналогично, может оказаться, что сессия вообще выглядит как «браузер<->прокси<->CloudFlare CDN<->Back-End банка» — т.е. в наличии уже ТРИ сессии и два некотролируемых посредника.
А юзверь всё думает, что он сидит напрямую в банке и всё очень приватно.
Пакет перехватывается TMITM прокси
Прокси отвечает «я твой банк»
Браузер строит сессию до прокси
Прокси строит сессию до банка
Но походу вместо одной сессии «браузер-банк» имеем ДВЕ сессии «браузер-прокси» и «прокси-банк». Что прокси делает с трафиком — известно лишь прокси.
Аналогично, может оказаться, что сессия вообще выглядит как «браузер<->прокси<->CloudFlare CDN<->Back-End банка» — т.е. в наличии уже ТРИ сессии и два некотролируемых посредника.
А юзверь всё думает, что он сидит напрямую в банке и всё очень приватно.
Только по идее браузер юзера должен завопить на сертификат
в том-то и дело, что не вопит, т.к. прокси подсовывает динамически выписанный доверенный сертификат
он доверенный только в случае ручной установки на клиента
Только один нюанс — в случае с CloudFlare соединение «прокси->CloudFlare» контролируется банком.
Это соединение не может контролироваться банком, т.к. банк не в состоянии контролировать ни прокси моего работодателя/оператора (пользуемся лочеными телефонами с операторскими прошивками?), ни CloudFlare, ни Интернет между ними. Банк просто «подписывается» за сервер CloudFlare, разрешая тому выступать в роли HTTPS-фронтенда банка.
Дальше вопрос выходит из технической плоскости в организационную: банк может заключить с CF некий контракт с SLA и компенсациями, но контролем я бы это не называл. Если что-то навернется или утечет по вине CF — банк этого предотвратить не сможет.
Дальше вопрос выходит из технической плоскости в организационную: банк может заключить с CF некий контракт с SLA и компенсациями, но контролем я бы это не называл. Если что-то навернется или утечет по вине CF — банк этого предотвратить не сможет.
Каждое входящее соединение в CloudFlare передается в банк для подписи. Банк уже решает, что с ним делать. В какой-то степени это уже контроль.
Т.е. банк своей подписью подверждает свою ответственность за контент.
Т.е. банк своей подписью подверждает свою ответственность за контент.
Банк не может отказаться подписать подключение.
Предположим, на сервере CloudFlare завёлся троян, который принимает подключение от пользователя, подписывает его на сервере банка. Банк не знает, какая информация передаётся между клиентом и CF, хотя клиент видит, что соединение авторизовано банком.
Предположим, на сервере CloudFlare завёлся троян, который принимает подключение от пользователя, подписывает его на сервере банка. Банк не знает, какая информация передаётся между клиентом и CF, хотя клиент видит, что соединение авторизовано банком.
Дайте мне тот банк, что не глядя подписывает все бумаги! :)
А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк. Печать банка стоит? Стоит.
Банк несет ответственность.
А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер. Навскидку могу предложить статический реверс-прокси в read-only докере и VPN по бронированому кабелю до банка. Даже если удастся получить доступ к файловой системе контейнера, злоумышленнику это ничего не даст. Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.
А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк. Печать банка стоит? Стоит.
Банк несет ответственность.
А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер. Навскидку могу предложить статический реверс-прокси в read-only докере и VPN по бронированому кабелю до банка. Даже если удастся получить доступ к файловой системе контейнера, злоумышленнику это ничего не даст. Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.
А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк.
Тогда вам глубоко фиолетова темя обсуждения — увеличивается ли кол-во уязвимых точек.
Печать банка стоит? Стоит. Банк несет ответственность.
Юридически сертификат на SSL-соединении ничего не значит. Банк может компенсировать всё, чтобы не терять репутацию, но при желании может от вас отмахнуться. С чем вы пойдёте в суд? Со словами, что выходили на сайт с подписанным соединением? А банк скажет — я это соединение не видел со своей стороны. Потребуется расследование и если найдут виновника, он вам возместит ущерб, если сможет.
Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.
Если бы вы были админом, который управляет всеми этими контейнерами, тогда что — тоже тупик? А если его рабочее место взломают и будут полгода наблюдать, как он работает, где какие пароли, куда пишутся логи? Причём взломают не из сети, а аппаратными закладками на клавиатуру/дисплей.
Юридически сертификат на SSL-соединении ничего не значит. Банк может компенсировать всё, чтобы не терять репутацию, но при желании может от вас отмахнуться. С чем вы пойдёте в суд? Со словами, что выходили на сайт с подписанным соединением? А банк скажет — я это соединение не видел со своей стороны. Потребуется расследование и если найдут виновника, он вам возместит ущерб, если сможет.
Т.е. вы считаете, что банк соединение подписал, но ответственности не несет? Это как? Я не специалист в юрисдикции, но здравый смысл подсказывает, что тут что-то не так.
А вообще, естественно, 100% надежных систем не бывает. Вопрос только в количестве усилий необходимых для преодоления защиты.
Я не специалист в юрисдикции, но здравый смысл подсказывает, что тут что-то не так.
Для юристов все эти SSL-и — непонятные гиковские игры. Есть федеральный закон 63 об ЭЦП, который определяет порядок работы с подписями. Всё должно быть сертифицировано (у вас система и браузер наверняка не сертифицированы по всем требованиям, поэтому заявления, что вы произвели проверку подписи, не внушают доверия).
И самое главное — статья 12 пункт 2.1:
При создании электронной подписи средства электронной подписи должны показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает
Это значит, что никакая штамповка подписей на автомате не признаётся юридически. Должно быть лицо, проверяющее каждый документ перед подписью, и несущее ответственность за содержимое.
Да и, по хорошему, ответственность несёт не только банк, но и вся цепочка сертификации. А если ответственность размыта (да ещё и между гос. организациями), но и ни с кого взыскать ничего нельзя, пока не будет доказана вина конкретной стороны.
Печать банка стоит? Стоит.
Я бы посмотрел, как вы эту «печать» будете в суде предъявлять, и что вам ответят на это.
Особенно с учетом того, что ломать вас будут явно не во время вашего соединения с банком. Самый простой вариант — вашу сессию перехватили и мониторят, вы работу закончили, нажали «Logout», вам страничку Logout'а показали (но с прокси) — и понеслось… В следующий раз вы логинитесь через неделю и наблюдаете картину: на сбер счетах нули, на текущих минмальные остатки (чтобы жертва не получила алерт стразу после хака, а чуть позже) и три ипотеки :)
Что будете предъявлять? Подписанные и проштампованные распечатки скриншотов дампов всего трафика с прошлой недели?
А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер.
Конечно, но вы забываете, что «общедоступный HTTPS сервер» никуда не делся, и его всё еще необходимо защищать — просто теперь от стоит на площадке CloudFlare, а не банка. Так что теперь вместо одного элемента нужно защищать как минимум два. И как минимум над одним из них банк не имеет контроля и значит, скорее всего, «ответственности не несет».
Хорошо, а посмотрим на это с другой стороны.
Вот я пришёл в банк и положил 300.000 руб. Это зафиксировано на видеокамерах, есть свидетели, и у меня есть квитанция на руках.
Потом меня хакнули, деньги сняли. Как банк докажет, что денег на моём счету больше нет.
Вот я пришёл в банк и положил 300.000 руб. Это зафиксировано на видеокамерах, есть свидетели, и у меня есть квитанция на руках.
Потом меня хакнули, деньги сняли. Как банк докажет, что денег на моём счету больше нет.
Всё будет не так: как вы докажете банку, что это вас хакнули по их вине/недосмотру, а не вы сами перевели куда-то деньги и теперь пытаетесь развести банк на бабло?
У меня есть квитанция на внос денег на счёт, но нет квитанции на вывод.
Чем банк докажет, что операция вывода вообще была проведена через браузер?
Чем банк докажет, что операция вывода вообще была проведена через браузер?
Своим логом, в котором написано, что пользователь Х, авторизованный согласно процедурам, и потому идентифицированный и аутентифицированный как клиент Вася Пупкин, через онлайн-банкинг попросил банк перевести Y денег на счет Z.
Проблема как раз будет на вашей стороне — доказать банку, что имел место, скажем, увод сессии, и это у них уязвимость, а не у вас преступный умысел.
Проблема как раз будет на вашей стороне — доказать банку, что имел место, скажем, увод сессии, и это у них уязвимость, а не у вас преступный умысел.
Для определенности будем считать, что в нашем гипотетическом случае всё действует по законо «как оно должно быть», иначе смысл во всей этой возни с сертификатами теряется.
Существует возможность перехвата активной SSL сессии? В чем тогда вообще смысл шифрования трафика? Ладно. Допустим.
Да, я гипотетический параноик и пишу весь трафик за последний год и потащу в суд дамп с отпечатком ключа банка и поддельной страницы Logout.
Т.е. банк открытым текстом говорит — «да, мы подписали вашу сессию с вот этим сервером, но мы не знаем, что там на сервере и знать не хотим»? И кто после этого останется в клиентах этого банка? Даже если юридически придраться невозможно.
А вообще, изначальный смысл моего комментария заключался в том, что я хотел акцентировать, что в предложенная CF схема лучше традиционной схемы фермы HTTPS-фронтендов, где каждый фронтенд имеет свою копию приватного ключа и сам пописывает все сессии. И тут, в случае взлома одного из фронтендов, получается полная свобода — есть приватный ключ и можно развлекаться. А здесь надо еще дополнительно обмануть и центральный подписывающий сервер.
Особенно с учетом того, что ломать вас будут явно не во время вашего соединения с банком. Самый простой вариант — вашу сессию перехватили и мониторят, вы работу закончили, нажали «Logout», вам страничку Logout'а показали (но с прокси) — и понеслось…
Существует возможность перехвата активной SSL сессии? В чем тогда вообще смысл шифрования трафика? Ладно. Допустим.
Что будете предъявлять? Подписанные и проштампованные распечатки скриншотов дампов всего трафика с прошлой недели?
Да, я гипотетический параноик и пишу весь трафик за последний год и потащу в суд дамп с отпечатком ключа банка и поддельной страницы Logout.
Так что теперь вместо одного элемента нужно защищать как минимум два. И как минимум над одним из них банк не имеет контроля и значит, скорее всего, «ответственности не несет».
Т.е. банк открытым текстом говорит — «да, мы подписали вашу сессию с вот этим сервером, но мы не знаем, что там на сервере и знать не хотим»? И кто после этого останется в клиентах этого банка? Даже если юридически придраться невозможно.
А вообще, изначальный смысл моего комментария заключался в том, что я хотел акцентировать, что в предложенная CF схема лучше традиционной схемы фермы HTTPS-фронтендов, где каждый фронтенд имеет свою копию приватного ключа и сам пописывает все сессии. И тут, в случае взлома одного из фронтендов, получается полная свобода — есть приватный ключ и можно развлекаться. А здесь надо еще дополнительно обмануть и центральный подписывающий сервер.
Существует возможность перехвата активной SSL сессии
Вообще-то, статья о том, что можно в сессию вставить два TMITM-proxy да так, что рядовой юзер и не заметит…
Конечно, с точки зрения обеспечения безопасности ключей, схема хороша. Обманывать сервер не придется, если получится взломать прокси. Ведь сервер доверяет прокси. И юзер доверяет прокси. И не надо никаких сессий перехватывать — сессия заказчивается на прокси.
А вот с точки зрения возможных проблем с компенсацией ущерба — неоднозначно. Но вам, гипотетически, волноваться не о чем, пока всё работает «как оно должно быть». Надеюсь, ваше «как оно должно быть» совпадает с мнением банка :)
Вообще-то, статья о том, что можно в сессию вставить два TMITM-proxy да так, что рядовой юзер и не заметит…
Именно, и тут я полностью согласен. Вопрос только считать CF как TMITM или как end-point. СF декларирует свою услугу как end-point.
А уж доверять им или нет — каждый сам себе буратино.
Клиентов никто не спросит, доверяют ли они CF.
Просто однажды фронт-энд банка переедет в облако.
Адрес страницы не изменится, дизайн страницы тоже.
Просто однажды фронт-энд банка переедет в облако.
Адрес страницы не изменится, дизайн страницы тоже.
Вопрос доверяют ли они банку, который переводит свои фронтенды в CF
Или банк и этот процесс не контролирует?
Или банк и этот процесс не контролирует?
Вы когда-нибудь получали письмо от банка «Уважаемый клиент, наш HTTPS-фронтенд переехал в облако CloudFlare. Если вы не знаете, что такое HTTPS, фронт-енд или Cloudflare — на сайте банка вы можете скачать небольшой учебник по проектированию, поддержке и обеспечению безопасности распределенных высоконагруженных систем клиент-банк с учетом последних веяний мод в законодательстве. Спасибо за внимание, с любовью...»
Скорее будет так: при следующем логике в клиент-банк попросят принять новые правила пользования, которые никто не читает (вы читаете?). А потом будет поздно :)
Скорее будет так: при следующем логике в клиент-банк попросят принять новые правила пользования, которые никто не читает (вы читаете?). А потом будет поздно :)
Т.е. банк подтверждает, что несмотря на то, что сессии подписаны его сертификатом, он не гарантирует достоверность данных переданных в этой сессии?
А зачем тогда вообще вся эта морока с сертификатами, если они _по определению_ не гарантируют достоверность и владелец ключа не отвечает за содержимое подписанных им сессий?
А зачем тогда вообще вся эта морока с сертификатами, если они _по определению_ не гарантируют достоверность и владелец ключа не отвечает за содержимое подписанных им сессий?
Сертификат нужен, чтобы скрипт-кидди не включился в разрыв LAN-кабеля на чердаке и не увёл деньги.
Если у тебя триллионы миллиардов на счету, не подключай онлай-банкинг, управляй счётом более безопасно.
Затем же обфусцируют код программ, шифруют. Хотя всё равно сломают. Просто стоимость взлома сильно увеличивается.
Если у тебя триллионы миллиардов на счету, не подключай онлай-банкинг, управляй счётом более безопасно.
Затем же обфусцируют код программ, шифруют. Хотя всё равно сломают. Просто стоимость взлома сильно увеличивается.
А зачем тогда вообще вся эта морока с сертификатами
Я понимаю ваше искреннее недоумение и недовольство порядком вещей, но мир сложился именно так. Если вам не нравится — начинайте мир менять, только не надо жаловаться мне — от этого мир не изменится :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Так ли приватен HTTPS?