Comments 35
После подробностей про AES ожидал увидеть мнения по скорости RSA 2048/4096; EC и общей готовности к переходу на него.
PS: маленькая просьба к таким: делать в тексте кликабельные ссылки со слайда-картинки, чтобы не искать слайды в презентации.
Не упомянуты tickets и кэширование сессий.
Одного упоминания мало.
- Тикеты нужно вовремя и правильно обновлять, сохраняя несколько предыдущих ключей для старых соединений.
- А вот от сохранения сессий возможно уже пора избавляться, особенно в кластерной среде.
Это специально для копипастеров, т.к. для использования тикетов нужно выполнять пункт №1 из моего комментария и безопасно шарить по всем серверам в кластере. Загляните на официальный wiki. Если кто-то в состоянии утащить ключи тикетов, то тут проблема другого порядка.
С точки зрения производительности и наличия готовых решений иметь общий кеш сессий в кластере ещё проблемнее и опаснее.
Вдобавок, есть возможность латентно переполнять кеш как часть атаки.
Привязывать наверно по IP предлагаете, т.е. на каждом сервере будет конфликт по session ID.
Если я ничего не упустил, то nginx генерирует предсказуемые SID'ы. Это неизбежный конфликт при смене IP или переключении сервера во время обслуживания..
Вероятно, именно поэтому настройки nginx по умолчанию:
ssl_session_cache none;
ssl_session_tickets on;По крайней мере, в своё время я отказался от кеша сессий, из-за жёсткого сбоя клиентских API запросов при динамической балансировке нагрузки. Во-вторых, кривые API клиенты достаточно быстро переполняли кеш.
http://blog.haproxy.com/2011/07/04/maintain-affinity-based-on-ssl-session-id/
По сути та же проблема переполнения таблицы. Фронтовых HAProxy должно быть минимум два для высокой доступности с дополнительной сложностью синхронизации таблиц через peers. Любое такое решение имеет свои пределы масштабирования + более подвержена ошибкам конфигурации.
А по поводу SID'ов всё же немного погорячился. Хоть сама генерация вроде бы и предсказуема, но где-то должны быть переменные значения на входе. Сейчас не удаётся воспроизвести коллизию из-за которой отваливались клиенты. ChangeLog говорит об исправленных CVE с сессиями и несколько лет назад код модуля был совсем другой.
Тикеты дают тот же результат. Разница в том, что:
С tickets — сессия хранится только на клиенте и по сути используется один активный ключ шифрования для всех клиентов. Подобрал его — раскрыл все сессии.
С session ID — сессия хранится и на клиенте, и на сервере, более безопасны, но хуже масштабируются. Есть очевидные атаки в виде мелких пакостей с переполнением кеша и полного хендшейка для всех клиентов.
По мне, для большинства публичных сайтов тикеты более чем подходят. Для банков и подобных кейсов, конечно, более безопасными будут Session ID.
Статья — хорошая, как обзор, и для образования.
OpenSSL (если включать сюда его форки) и сейчас является самой популярной библиотекой TLS/SSL.
А по поводу TLS вообще не понял вашей мысли. В 2014-ом все уже давно использовали TLS 1.0, кто и куда хотел перейти? По поводу того, что TLS оказался хуже — не знаю, почему вы так решили, SSL 3.0 был ещё более дырявым. Подобные ошибки в тексте сильно портят впечатление от статьи.
Вот честно, статей по поводу TLS сейчас вагон и маленькая тележка, начиная от теоретического ликбеза и заканчивая конкретными инструкциями. Для кого писалась конкретно эта статья?
Чудо-статья и хорошее упоминание про закрытые ключи для Роскомнадзора. Как они законы принимают?
Весь Тор построен на TLS. Данные между узлами передаются многократно зашифрованными.
А слово «корневые» относится к PKI (Public Key Infrastructure) — инфраструктуре [распространения] публичных ключей. В которую, собственно, и входят корневые и промежуточные центры сертификации, а также средства доверенной доставки корневых сертификатов на конечные устройства. Тут возможны, в принципе, меш- и блокчейн-подобные варианты. В первом случае сертификату должны доверять ваши «друзья» или «соседи», во-втором — больше половины «полноценных» узлов сети. Первый случай быстрее и дешевле, но что делать, если вы в тылу врага, с друзьями связи нет, а соседи за вами следят?
мы говорим про распределённую структуру со множеством балансировщиков… а третий получите бесплатно у Let’s Encrypt.
Автоматизировать получение сертификата Let’s Encrypt в большой распределённой системе довольно нетривиально. А без автоматизации с максимальным сроком действия 90 дней как-то не очень.
Подскажите какую комманду встраивать? Штатные тулзы Let’s Encrypt поддерживают единственный способ верификации — положить файлик к вам на сервер и запросить его извне. Пока Вы будете его синхронизировать по всем серверам у них timeout случится. Для верификации через txt-запись есть только неофициальный скриптик, который поддерживает исключительно bind.
Хэш в файлике имеет срок жизни. Вы можете запросить проверку не сразу после его генерации. За 10 минут-то успеете файл синхронизировать?
Масштабируя TLS