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

 

 

МИФ №1: Использование HTTPS — гарантия безопасности сайта

 

Вроде бы все просто: все данные передаются между сервером и браузером в зашифрованном виде и украсть их «по пути» невозможно. На практике же запросто могут возникать нюансы…

 

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

 

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

 

Вторым моментом, на который стоит обратить внимание, является тот факт, что шифрования трафика защищает только от перехвата данных: вирусы, фишинг и опасный для пользователей код остаются таковыми даже в зашифрованном виде. Если сайт генерирует вредоносные ответы через HTTPS они попадут в браузеры пользователей-жертв еще более безопасно для себя :) В такой ситуации маршрутизаторы с защитой от вторжения (IDS/IPS) и прочие системы безопасности, основанные на «глубоком анализе пакетов», становятся бессильными, если не настроить дешифрование и повторное шифрование.

 

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

 

МИФ №2: SSL сегодня не является значительной статьей расходов серверных вычислительных ресурсов

 

Если бы это было так, то F5, Juniper, Cisco и прочие не ставили бы такие ценники на свои решения. Да, вычислительные мощности среднестатистического сервера растут не по дням, а по часам, но эти же самые вычислительные ресурсы используются и для взлома сертификатов. Не смотря на то, что на взлом  1024-битного ключа по-прежнему требуются многие годы и неплохие финансовые вложения, NIST рекомендует переходить на более криптостойким решениям (от 2048 бит), так как теоретически подбор 1024-битного ключа сейчас вполне возможен.

 

Для разгрузки центрального процессора веб-серверов существует два основных пути:

 

  • SSL-акселерация на уровне маршрутизатора (чаще всего от вышеупомянутых вендоров)
  • Использование HSM с встроенным криптографическим процессором

 

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

 

МИФ №3: Расходы на управление сертификатами не растут с увеличением количества веб-серверов

 

Вполне очевидно, что чем больше веб-серверов используется, тем больше SSL-сертификатов должно быть установлено. Еще дополнительные SSL-сертификаты возникают и когда используется несколько виртуальных хостов на одном сервере. До до сих пор часто встречаются люди, которые не знают, что веб-сервер не может определить каким ключом расшифровывать запрос, если на одном IP-адресе расположены несколько доменов, использующих SSL.

 

Чтобы позволить спокойно масштабировать HTTP-уровень веб-приложения, необходимо рано прерывать HTTPS-соединение для определения сервера, где запрос будет собственно обработан. Такую архитектуру намного легче поддерживать, так как нет необходимости конфигурировать абсолютно каждый HTTP-сервер с отдельными IP-адресами для каждого шифруемого поддомена.

 

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

 

Заключение

 

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

www.insight-it.ru/programmirovanie/kriptografiya/3-mifa-ob-effektivnosti-ssl/

Вверх