РАШИД АЧИЛОВ, главный специалист по защите информации в компании, занимающейся автоматизацией горнодобывающей промышленности, shelton@sheltonsoft.ru
Широкое использование SSL привело к тому, что все чаще появляются атаки, которые направлены непосредственно против него, основанные на ошибках либо недочетах реализации. Рассмотрим, каким образом можно усилить уже существующую защиту
В ноябре 2011 года была опубликована первая серьезная работающая атака против SSL – BEAST [1]. Она не зависела от того, насколько тщательно были сделаны настройки, она использовала ошибки реализации. Как говорят в таких случаях, by design. Атака позволяла при определенных условиях расшифровать зашифрованную информацию – в [1] описана расшифровка secret cookie для учетной записи на сервере PayPal. Эта атака окончательно добила и без того уже считавшийся небезопасным протокол SSL 2.0.
В октябре 2014-го, почти ровно через три года, была опубликована вторая, не менее серьезная, атака – POODLE [2]. Она точно так же не зависела от настроек и основывалась на ошибках протокола. И точно так же позволяла при определенных условиях расшифровать информацию. Не быстро, конечно, – по одному байту данных на 256 запросов. Эта атака окончательно дискредитировала протокол SSL 3.0.
Наконец в начале этого года была обнаружена еще одна уязвимость – LogJam [3]. Сама по себе эта атака ничего не расшифровывает, но позволяет понизить стойкость шифрования при установлении сессии до 512-битной группы DH, что существенно упрощает задачу злоумышленника по расшифровке секретного ключа сессии, в особенности если используется стандартная группа DH. Предвычислить нужную структуру можно только для известной группы, поэтому для атакующего важно, чтобы TLS-серверы использовали типовые параметры. Заставив пользователя задействовать нестойкую группу DH и имея ее предвычисленные значения, можно расшифровывать трафик буквально на лету, разумеется, обладая достаточными мощностями.
Что можно всему этому противопоставить?
- Отключить устаревшие протоколы SSL 2.0 и SSL 3.0 (к сожалению, есть еще серверы, которые используют только SSL 3.0).
- Предпочитать использование TLS 1.2, ну, либо TLS 1.1, отказавшись по возможности и от TLS 1.0.
- Сгенерировать уникальную группу DH для каждого сервера, если программное обеспечение позволяет это сделать. Сгенерированная группа DH должна быть длиной не менее 2048 бит – такая начальная группа долго будет еще не «по зубам» расшифровщикам.
- Настроить программы таким образом, чтобы выбор шифра оставался за сервером, а не за клиентом.
- Тщательно подобрать разрешенные шифронаборы, исключив все старые, слабые и небезопасные, в том числе все шифронаборы, использующие потоковый шифр RC4 [4].
Далее будет рассказано о методах формирования строки шифронаборов (ciphersuite), описывающей разрешенные в данной системе шифронаборы, а также о практических приемах настройки программ Sendmail, nginx, Apache и Dovecot таким образом, чтобы защититься от всех вышеперечисленных атак (и, возможно, от других, не упомянутых выше, – а они были).
Статью целиком читайте в журнале «Системный администратор», №11 за 2015 г. на страницах 36-40.
PDF-версию данного номера можно приобрести в нашем магазине.
SSL в режиме повышенной безопасности
