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-версию данного номера можно приобрести в нашем магазине.

1. Первая атака на протокол SSL – http://habrahabr.ru/company/xakep/blog/132344.
2. Атака POODLE использует откат версии протокола до SSLv3 – https://threatpost.ru/novyj-poodle-ekspluatiruet-problemu-otkata-protokola-do-ssl-3-0/4195.
3. LogJam – новая уязвимость в TLS – http://habrahabr.ru/company/eset/blog/258461.
4. Атака против RC4 тринадцатилетней давности – https://threatpost.ru/na-black-hat-asia-prodemonstrirovana-novaya-ataka-protiv-ssl-tls/7186.
5. Документация на mod_ssl – http://httpd.apache.org/docs/current/mod/mod_ssl.html.
6. OpenSSL Cookbook – https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html.
7. Выбор CiperSuite для TLS. Опыт Яндекса – http://habrahabr.ru/company/yandex/blog/258673.
8. Тестирование сайта на наличие SSL-уязвимостей – https://www.ssllabs.com/ssltest.
9. Бесплатная программа для изменения списков шифронаборов в Windows – https://www.nartac.com/Products/IISCrypto.
10. HTTPS Strict Transport Security – http://habrahabr.ru/post/216751.
11. HTTP Public Key Pinning – https://bjornjohansen.no/public-key-pinning.