Последнее время повсеместно, всех и вся, добровольно и с песней, под предлогом защиты данных пользователя переводят на шифрованные каналы. Применительно к web это означает переход с протокола http на протокол https.
С технической точки зрения это означает в первую очередь радикальное просаживание производительности сервера.
Тем интереснее посмотреть на эффективность (и условия применимости) навязываемого решения.
Должно быть общеизвестно, что главный «вирус» на рабочей станции под управлением самой распространённой ОС — это т.н. «антивирусное» ПО.
Здесь же отмечу, что в корпоративной среде, в качестве альтернативы ослу (который Infernet Exploder) обычно предпочитают Google Chrome. И ниже будет показано почему.
Стартовая точка:
Рабочая станция, под управлением самой распространённой ОС, «защищённая» антивирусом Касперского. Пользователь предпочитает браузер FireFox.
Лирическое отступление из личного опыта к вопросу о компоновке пакета: достаточно давно наблюдалась замечательная ситуация, когда FireFox на линуксе при обращении по протоколу https просто рисует страницу, его же сборка на самой распространённой ОС на той же ссылке рисует ошибку «неизвестный центр авторизации».
Нежданчик:
FireFox начинает рисовать ошибку «неизвестный центр сертификации» на всех обращениях по протоколу https. Причём ни в осле, ни в хроме таких безобразий не наблюдается.
Объяснение ситуации простое и очевидное: главный зловред запущен в режиме проверки http[s]-трафика (что где-то может быть оправданно, а где-то является наивностью за гранью идиотизма). По факту это означает, что в роли «клиента» для ресурса выступает «антивирус», который потом шифрует данные для настоящего клиента (браузера). Но, т.к. ключа сертификата сервера у него, естественно, нет, то вместо оригинального сертификата антивирус вынужден использовать поддельный сертификат сервера, заверенный таким же локально-самодельным сертификатом центра авторизации.
Особенно фееричный результат наблюдается на сайтах, проставляющих заголовок HSTS (что для клиента практически означает невозможность ручного добавления исключения безопасности).
С ослом финт проходит незамеченным, ну разве что кто-то может удивиться тормозам, потому что главный зловред умеет добавлять сертификаты (вышеупомянутый самодельный ЦА) в локальное хранилище (в качестве доверенного корневого ЦА). Виндовая сборка Google Chrome (и по косвенным признакам — все прочие браузеры на базе webkit'а) использует стандартное системное хранилище сертификатов и в рамках исследуемой задачи не отличается от осла.
В этом самом месте свидетели секты пророчества вирусов для Linux должны порадовать публику рассказом о том, что у FireFox недостаточная популярность для того, чтобы разработчики зловредов снизошли до реализации работы с его хранилищем сертификатов.
Особенно прекрасно совмещение знания описанной ситуации, широко распространённой практики жёсткой завязки клиент-банка на IE и несомненно «добровольно» принимаемыми условиями лицензионного «соглашения» на антивирусное ПО. В части материальной ответственности разработчика ПО.
Поддержка Mozilla закономерно и справедливо рекомендует выключение функции проверки https-трафика. Что не всегда возможно. Не говоря о рисках эксплуатации фичи вирусописателями.
На форуме разработчика зловреда естественно рекомендуют установить сертификат ЦА. Не слишком балуя аудиторию указанием имени файла и способа его промышления. Если кто-то вдруг не в курсе: это прозрачный намёк на практику сокрытия системных каталогов самой распространённой ОС от пользователя и интуитивно-понятность способа включения их отображения.
Популярный и полагаемый некоторыми камрадами авторитетным источником ресурс geektimes.ru радует публику праведным негодованием клерка, обнаружившего вышеописанную фичу.
Комментарии
Нельзя. Вам сказали нельзя. Значит нельзя.
А на альфе из этих ваших сертификатов ещё и кактусы делают.
Что за глупости? Практически все серверные процессоры уже много лет имеют аппартное ускорение шифрования. Никакого "радикального" просаживания нет.
Вы удивительно конкретны («практически все», «много лет» и «шифрование» без указания алгоритмов).
Пожалуйста :) Аппаратное ускорение AES (а именно AES - основной страндарт шифрование сейчас) имеют:
Intel Westmere based processors, specifically:
То есть последние минимум 7-8 поколений, в зависимости от производителя.
Увидев этот список все должны признать, что шифрование не добавляет работы серверу?
Добавляет конечно, но около 2% по разным оценкам. И считается, что преимуществ HTTPS дает больше, чем недостатков :)
Профессиональные оценки такие профессиональные.
И, главное, результат «разных оценок» от длины ключа не зависит.
"Разные оценки" рассказывай прохожим на улице. Я в состоянии измерить длительность работы программы с точностью до сотен тактов проца. Т.н. "шифрование" прибавляет 30% минимум. Более того, его (шифрования) без(овсякая)смысленность очевидна любому желающему увидеть.
И про проседание производительности с точки зрения скорости загрузки сайтов.
Если верить https://www.keycdn.com/blog/https-performance-overhead/, влияние HTTPS на скорость зарузки минимальное, более того, в некоторых случаях HTTPS увеличивает скорость загрузки сайта.
Ключевое слово сам выделить сможете? ☺
Товарищам, *заявляющим* пренебрежимость влияния шифрования на производительность сервера я бы рекомендовал использовать ключик минимум в 8k.
Приведите примеры применения ключей в 8К в вебе?
Приведите *аргументированную* рекомендацию экспертов в части длины ключа.
Пожалуйста :)
Ключи больше 4096 бит в вебе редко используются, обычно 2048.
Отсюда:
Should you use 4096 bit keys? Let's consider our results:
То есть: 4096 ключи не обеспечивают разумного усиления шифрования, по сравнению с 2048, значительное увеличени нагрузки на процессор, небольшое увеличение времени соединения.
Вывод: 4096-битные и более ключи использовать не целесообразно. Повторюсь, шифрование увеличивает нагрузку на процессор, но незначительно. Ключи длиннее 4096 бит не используются.
Насчет длины ключей все еще проще. Асимметричные ключи используются только в начале сессии для генерации и защищённой передачи клиенту и серверу сессионного ключа. Затем в течении сессии шифрование идет симметричное этим сессионным ключом. И этому симметричному шифрованию по барабану какой там длины были ключи в сертификатах. Проще говоря, если вы зашли на некий сайт по https и шаритесь по нему полчаса, то единственное место где имеет значение длина ключа - обращение к первой страничке. Легко понять, что увеличение нагрузки измеряется даже не десятыми долями процента, а практически несущественно.
Позвольте уточнить: данный принцип работает во *всех* сценариях протокола (включая ветку, в которой у клиента есть *свой* ключ)?
у клиента есть "свой" приватный ключ и у сервера есть "свой" приватный ключ. Это ключи для асимметричного шифрования. Далее как я и написал: с помощью этих ключей (возможен вариант когда ключ есть только у сервера) оба участника обмениваются 3-м ключом (сессионным, симметричным). Далее, в рамках сессии шифрование-дешифрование происходит этим 3-м ключом.
Справедливости ради: в наиболее употребимых ситуациях (например, чтобы далеко не ходить, АШ) у клиента *нет* своего приватного ключа.
ЗЫ: Пример описан в статье. Только попрошу не палить *там* правильный ответ.
Так я ж говорю: в принципе достаточно серверного сертификата. В этом случае клиент генерирует у себя случайный сессионный ключ, потом шифрует его публичным ключом сервера (который тот всем предоставляет) и в таком виде отсылает через интернет серверу. Сервер своим приватным ключом расшифровывает и получает сессионный ключ. Все, сессионный ключ знают 2 участника переписки и начинают им шифровать.
Извините, но Вы явно оперируете не полной моделью, но некоторым популярным упрощением.
Вопросы:
1. Если «достаточно» серверного сертификата, то зачем в нём (для примера, чтобы далеко не ходить, беру сертификат сервера АШ) прописано применение в качестве клиента?
2. Что (и почему) будет, если тот же сертификат поменять на *чисто* серверный (с критическим характером ограничения)?
1. нет никакой связи между тем что я рассказал (а именно механизмом шифрования связи между клиентом и сервером) и тем, какие сферы применения разрешены конкретному сертификату. Владельцы сервера АШ могут на него залить сертификат, на котором кроме серверной могут быть любые роли. Иногда это делается со смыслом, когда например сервер АШ ходит куда-то еще в качестве клиента. Тогда сертификат должен уметь играть роль и клиента и сервера. Или 2 разных сертификата сделать, это уже детали реализации и свобода админа.
2. с точки зрения клиентов ничего не изменится. Если же выполняются еще какие-то операции (см.п1) то эти операции не смогут выполняться.
В п.2 ошибка.
Итого теорему об оперировании *упрощенной* частной моделью можно считать доказанной.
ну если реализация протоколов SSL и его наследников в лице TLS считать "упрощенной" частной моделью, то что мы вообще обсуждаем ?:)
Рекомендую разделять Ваши *представления* о реализации TLS и собственно реализацию.
Увлечение криптозоологией несомненно похвально.
Но небрежение полным циклом и сугубо — указаний на… особенности реализации [как минимум в одном из популярных] сервера заслуживает порицания.
Тема достаточно важная, поэтому не лень и повторить вопрос:
Если в сертификате сервера прописано *критическое* ограничение на использование в качестве «сервера» и отсутствует разрешение на использование в качестве клиента, то с какой ошибкой рискует встретиться пользователь?
Что значит " в сертификате критическое ограничение" ? В сертификате просто перечислены роли, для которых можно использовать этот конкретный сертификат.
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage: critical
TLS Web Server Authentication
Замечательно. Сертификат можно использовать для web-сервера. Достаточно для того, чтобы клиент (со своим сертификатом или без него) мог установить защищенное соединение с сервером. Если в настройках Web-Сервера включить требование клиентского сертификата, то без клиентского перестанет пускать.
А теперь разворачиваю результат моего эксперимента (в конфиге сервера требование клиентского сертификата *не* прописано):
1. Клиент со своим сертификатом — всё замечательно работает;
2. Клиент без своего сертификата — получите ошибку (не совпадающую с ошибкой для ситуации, когда сервер строго контролирует наличие клиентского сертификата).
Ну и к наглядности: покажите пожалуйста сервер (url), на котором работает описанная Вами схема.
https://www.utkonos.ru/ например
Издан thawte, Inc., серийный номер 68:84:9d:c7:00:5f:b8:aa:88:a8:08:5f:91:42:2b:e5, действителен с Jul 7 00:00:00 2016 GMT по Aug 6 23:59:59 2017 GMT?
Думаю, продолжу (по Вашему совету) диалог с голосами в своей голове.
Надеюсь это не отменит мой ответ по существу на вопрос по существу, с которого началась дискуссия ?:)
Это, как я понимаю, утверждение необязательности обременения «ответа по существу» требованием соответствия широкоупотребимым (общий случай тестировать лень) практикам?
Вы всё же попробуйте замутить свой тестовый УЦ, издать *правильный* неизбыточный сертификат и посмотреть на результат.
Просто люди ещё не в курсе, что вместо апача можно nginx впилить и будет щасье.
Stafcop сделан Касперским? Я что то пропустил?
Или я недостаточно ясно выразился: из первой ссылки на поддержку Мозиллы следует, что причиной ошибки является локальная проверка https-трафика. Конкретная реализация (антивирус касперского, другой антивирус или специальный сканер) не важна.
1. Не вижу проблем. Хорошие парни придумали, как можно относительно безопасно общаться с шифрованием. Другие хорошие парни решили добавить в интимный процесс общения свои полезные программы, и раз уж их полезные программы УЖЕ имеют админские права на компе клиента, то пользуясь этим добавили сертификаты в хранилище ОС.
Про ФФ со своим хранилищем забыли/забили. Антивирусник перехватывает каждое https соединение с предположением, что у инициирующей его программы есть его сертификат. ФФ просто не в курсе.
2. После генерации и обмена сеансовыми ключами используется симметричная криптография Rijndael-128 (AES), которая очень быстра, а за счёт аппаратной поддержки крайне быстра. Тормоза добавляемые антивирусом вряд ли можно списать на двойные накладные расходы при https, скорее его антивирусный движок тупит.
альтернативы ослу (который Infernet Exploder) ??????
Он самый! ☺
Прочитайте статью по ссылке.
Абсурдопедия (в отличие от википедими) никогда не врёт!
Поддержка Mozilla закономерно и справедливо рекомендует выключение функции проверки https-трафика. Что не всегда возможно. - теперь возможно. Всегда. Ну, почти всегда.
Как мне кажется, Фаерфокс вполне правильно ругается на незнакомый сертификат. Проблема не в шифровании, а в попытках всяких "антивирусов" прослушивать HTTPS трафик, по сути производя атаку посредника
да там вообще всё штатно работает.
Штатно поставлен софт, штатно установлена локальная прокся, сертификат штатно вставлен в штатное хранилище, штатно используется одними браузерами и штатно игнорируется другими. Даже реакция пользователя не удивляет :)
Особенно «не удивляет» попытка представить частно-проприетарную реализацию в роли универсального стандарта.
На самом деле проблема не (с)только в этом, сколько в том, что прочие браузеры (использующие системное хранилище сертификатов самой распространённой ОС) не предоставляют пользователю даже намёка на успешно проведённую атаку.
О какой атаке идёт речь?
Пользователь или админ конторы дал программе (антивируснику) полные права на всю систему: полный доступ к диску, сетевым операциям, памяти любого процесса и ядра системы. Эта программа добавила свой сертификат в хранилище ОС, а разработчки браузера виноваты.
Хватит бредней.
1. Идёте по ссылке в начале ветки.
2. Читаете.
3. Пробуете понять прочитанное.
4. Находите отличия описанной ситуации от сценария атаки и делитесь с читателями.
Также приветствуется рассказ о стандартной и интуитивно-понятной методике сверки базы сертификатов с эталоном.
Вообще-то и не должны. Если администратор сказал, что этому сертификату доверять, значит он доверенный. Также, как если администратор установил какую-то программу (браузер, антивирус. вирус, ...), то ОС не обязана при каждой загрузке указывать, что установлена дополнительная программа.
А если это был не администратор, а злоумышленник с правами администратора — то все играют в увлекательную лотерею «угадай неспомпрометированную резервную копию».
Разработчики СПО уже четверть века тому назад поняли во что превращается система, в которой администратор творит что полагает нужным.
И даже на прикладом уровне, для рядовых пользователей принцип был популярно сформулирован десять лет тому назад.
СПО в существующем виде не панацея. Компилятор, который при компиляции своих исходников или исходников ядра вставляет закладку был продемонстрирован ещё в 80-х. То есть если берёшь СПО, но в виде бинарника, то гарантий никаких. Надо, как минимум, пересобрать компилятор доверенным компилятором, а затем пересобрать всю систему.
И, строго говоря, прав у пользователя Администратор на Windows меньше, чем у пользователя root на Linux/FreeBSD (если не считать SELinux и подобное, но 25 лет назад их не было).
…и *никаких* (!) блобов. Разве что в форме ненаучной фантастики (*гарантии* (!) *полной* (!!!) материальной ответственности автора).
Безопасность не определяется правами пользователя «Администратор».
Модель RBAC тоже вроде как сильно продвинутая. До тех пор, пока её не придавит практикой.
ЗЫ: С качеством интеграции SELinux тоже наблюдаются некоторые… сурпрызы.
Например (в EL7):
ssh_keysign --> off, но Hostbased-авторизация замечательно работает.
Или:
ssh_sysadm_login --> off, но подключение root'ом по ssh тоже не представляет проблем.
Расскажи, как совсем без блобов ставишь Linux на новый компьютер. Всё равно приходится или брать блобы или надеяться, что компьютер, на котором проводится сборка является безопасным (а гарантии никто не даст).
Что появилось раньше: курица или яйцо?
И откуда появился *первый* компиллятор языка C? ☺
На самом деле этот вопрос, точнее технология поиска ответа на него, и является предметом статьи.
Страницы