Последнее время повсеместно, всех и вся, добровольно и с песней, под предлогом защиты данных пользователя переводят на шифрованные каналы. Применительно к 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 радует публику праведным негодованием клерка, обнаружившего вышеописанную фичу.