company_banner

Как и зачем мы делаем TLS в Яндексе

    Я занимаюсь в Яндексе продуктовой безопасностью и, кажется, сейчас самое время подробнее, чем уже было на YaC, рассказать на Хабре о том, как мы внедряем TLS.

    Использование HTTPS-соединений является важной частью безопасного веб-сервиса, так как именно HTTPS обеспечивает конфиденциальность и целостность данных на этапе передачи их между клиентом и сервисом. Мы постепенно переводим все наши сервисы только на HTTPS-соединение. Многие из них уже работают исключительно по нему: Паспорт, Почта, Директ, Метрика, Такси, Яндекс.Деньги, а также все формы обратной связи, имеющие дело с персональными данными пользователей. Яндекс.Почта уже больше года даже обменивается данными с другими почтовыми сервисами по SSL/TLS, поддерживающими это.



    Все мы знаем, что HTTPS — это HTTP, завернутый в TLS. Почему TLS, а не SSL? Потому что принципиально TLS — это более новый SSL, при этом название нового протокола наиболее точно характеризует его назначение. А в свете уязвимости POODLE можно официально считать, что SSL больше использовать нельзя.

    Наряду с HTTP в TLS может быть завернут практически любой протокол прикладного уровня. Например, SMTP, IMAP, POP3, XMPP итд. Но так как именно развертывание HTTPS является наиболее массовой проблемой и из-за особенностей поведения браузеров имеет большое количество тонкостей, я расскажу именно о нем. При этом с некоторыми допущениями многие вещи будут верны и для других протоколов. Я попытаюсь рассказать о том необходимом минимуме, который будет полезен нашим коллегам.

    Рассказ я условно поделю на две части — инфраструктурную, где будет всё, что ниже HTTP, и часть про изменения на уровне приложения.

    Терминация


    Первое, с чем придется столкнуться команде, которая собирается разворачивать HTTPS, — выбор способа терминации TLS. TLS termination — процесс инкапсуляции протокола прикладного уровня в TLS. Обычно на выбор есть три варианта:

    1. Использовать один из множества сторонних сервисов — Amazon ELB, Cloudflare, Akamai и других. Основным недостатком данного метода будет необходимость защиты каналов между сторонним сервисом и вашими серверами. Скорее всего, это все равно потребует развертывания поддержки TLS в том или ином виде. Большим недостатком также будет полная зависимость от провайдера услуг в плане поддержки необходимой функциональности, скорости исправления уязвимостей Отдельной проблемой может стать необходимость раскрытия сертификатов. Несмотря на это, данный способ будет хорошим решением для стартапов или компаний, использующих PaaS.
    2. Для компаний, использующих собственное «железо» и свои дата-центры, возможной опцией будет Hardware load balancer с функциями TLS-терминации. Единственное достоинство здесь — производительность. Выбирая такое решение, вы попадаете в полную зависимость от вашего вендора, а так как зачастую внутри продуктов используются одни и те же аппаратные компоненты, то еще и от производителей чипов. Как следствие сроки добавления любых фич далеки от идеала. Потенциальные таможенные сложности со ввозом подобных продуктов оставим за пределами данного материала.
    3. Программные решения — «золотая середина». Существующие opensource решения — Nginx, Haproxy, Bud и т.п. — дают вам почти полный контроль над ситуацией, добавлением фич, оптимизациями. Минусом является производительность — она ниже, чем у аппаратных решений.

    В Яндексе, мы используем программные решения. Если вы пойдете по нашему пути, то важным шагом при разворачивании TLS для вас станет унификация компонентов.

    Унификация


    Исторически в разное время наши сервисы использовали различное ПО web-серверов, поэтому, чтобы все унифицировать, мы решили отказаться от большинства решений в пользу Nginx, а там где отказаться нельзя — «спрятать» их за Nginx. Исключением в данном случае стал поиск, который использует собственную разработку под названием — внезапно — Balancer.

    Балансер умеет делать множество вещей, которые не умеют другие, даже коммерческие решения. Однажды, думаю, ребята расскажут об этом подробнее. Имея талантливую команду разработчиков, мы можем себе позволить поддерживать один собственный web server в дополнение к Nginx.

    Что касается непосредственно криптографии, то мы используем библиотеку OpenSSL. На сегодняшний день это самая стабильная и производительная реализация TLS с адекватной лицензией. Важно использовать OpenSSL версии 1+, так как в ней оптимизирована работа с памятью, есть поддержка всех необходимых современных шифров и протоколов. Все наши дальнейшие рекомендации будут ориентированы на пользователей веб-сервера Nginx.

    Сертификаты


    Для использования HTTPS на вашем сервисе понадобится сертификат. Сертификат — это публичный ключ и некий набор данных в формате ASN.1, подписанный удостоверяющим центром (Certificate Authority). Обычно такие сертификаты подписываются промежуточными удостоверяющими центрами (Intermediate CA) и содержат имя домена вашего сервиса в Common Name, либо расширении Alt Names.

    Для проверки действительности сертификата браузер пытается проверить валидность цифровой подписи для конечного сертификата, а затем для каждого из промежуточным удостоверяющих центров. Сертификат последнего в цепочке из удостоверяющих центров должен быть подписан так называемым Корневым Удостоверяющим Центром (Root CA).

    Сертификаты корневых удостоверяющих центров хранятся в операционной системе, либо браузере пользователя (например, в Firefox). При настройке веб-сервера важно отправлять клиенту не только сертификат сервера, но и все промежуточные. Корневой сертификат при этом отправлять не нужно — он уже есть в OС.



    Большие компании могут позволить себе иметь собственные Intermediate CA. Например, до 2012 года все сертификаты Яндекса подписывались YandexExternalCA. Использование собственного Intermediate CA дает как дополнительные возможности по оптимизации и пиннингу сертификатов, так и накладывает дополнительную ответственность, так как позволяет выписать сертификат практически для любого конечного доменного имени, а в случае компрометации может привести к серьезным последствиям, вплоть до отзыва сертификата промежуточного CA.

    Поддержка собственного CA может быть слишком дорогим и сложным процессом, поэтому некоторые компании используют их в режиме MPKI — Managed PKI. Большинству потребителей же будет достаточно покупки сертификатов с использованием одного из коммерческих поставщиков.

    Все сертификаты можно условно разделить по следующим характеристикам:
    1. Алгоритм цифровой подписи и используемая хеш-функция;
    2. Тип сертификата.

    Алгоритм цифровой подписи — для подписи сертификатов используются криптографические алгоритмы с открытым ключом, чаще всего это RSA, DSA или ECDSA. Мы не будем останавливаться на алгоритмах семейства ГОСТ, так как они пока не получили массовой поддержки в клиентском ПО.

    Сертификаты с использованием RSA на сегодняший день получили наибольшее распространение и поддерживаются всеми версиями протоколов и OC.

    Недостатком данного алгоритма является размер ключа и сопоставимая производительность при генерации и проверке цифровой подписи. Так как сертификаты с размером ключа менее 2048 бит являются небезопасными, а операции с ключом большего размера потребляют большое количество ресурсов процессора.

    DSA-подобные схемы быстрее RSA при генерации подписи (при тех же размерах параметров), при этом ECDSA гораздо быстрее классической DSA, так как все операции проходят в группе точек эллиптической кривой. По нашим тестами, один сервер Xeon 5645 позволяет сделать до 3200 TLS-хендшейков в секунду на веб-сервере Nginx при использовании сертификата, подписанного RSA с размером ключа 2048 бит (ECDHE-RSA-AES128-GCM-SHA256). При этом, используя ECDSA-сертификат (ECDHE-ECDSA-AES128-GCM-SHA256), можно сделать уже 6300 хендшейков — разница в производительности почти в два раза.

    К сожалению, Windows XP < SP3 и некоторые браузеры, доля которых среди клиентов больших сайтов отлична от нуля, не поддерживают ECC-сертификатов.

    Стойкость наиболее распространенных алгоритмов ЭЦП напрямую зависит от стойкости (безопасности) используемой хэш функции. Основные используемые алгоритмы хеширования:
    1. MD5 — сегодня считается небезопасным и не используется;
    2. SHA-1 — использовался для подписывания большинства сертификатов до 2014 года, сейчас признан небезопасным;
    3. SHA-256 — алгоритм, который уже сегодня пришел на замену SHA-1;
    4. SHA-512 — на сегодняшний день используется довольно редко, поэтому мы не будем на нем останавливаться.

    SHA-1 уже сегодня официально считается небезопасным и постепенно выводится из употребления. Так Яндекс.Браузер и другие браузеры семейства Chromium в ближайшие месяцы начнут помечать сертификаты, которые подписаны с использованием SHA-1 и срок действия которых истекает после 1 января 2016 года, как небезопасные. Все новые сертификаты правильно подписывать с использованием SHA-256. К сожалению, не все браузеры и OS (WinXP < sp3) поддерживают данную хеш-функцию, и для по-настоящему больших ресурсов это может грозить потерей клиентов.

    Все серверные конечные сертификаты, используемые для TLS, можно условно разделить по способу валидации — Extended Validated и прочие (чаще всего Domain Validated).

    Технически в extended validated сертификат добавляются дополнительные поля с признаком EV и часто с адресом компании. Наличие EV сертификата подразумевает юридическую проверку существования владельца сертификата, в то время как сертификаты типа Domain Validated подтверждают лишь то, что владелец сертификата действительно контролирует доменное имя.

    Кроме того, что появляется красивая зеленая плашка, признак EV-сертификата также влияет на поведение браузеров, связанное с проверкой их статусов отозванности. Так даже браузеры семейства Chromium, которые не используют ни OCSP, ни CRL, а полагаются только на Google CRLsets, для EV проверяют статус с помощью протокола OCSP. Ниже я расскажу об особенностях работы этих протоколов подробнее.

    Теперь, когда мы разобрались с сертификатами, нужно понять, какие версии протоколов будут использоваться. Как мы все помним, протоколы версий SSLv2 и SSLv3 содержат фундаментальные уязвимости. Поэтому, их необходимо отключить. Почти все клиенты сейчас имеют поддержку TLS 1.0. Мы рекомендуем использовать TLS версий 1.1 и 1.2.

    В случае, если у вас есть значительное число клиентов использующих SSLv3, в качестве компенсационной меры можно разрешить использовать его только с алгоритмом RC4 — на переходный период мы сделали именно так. Однако если у вас не такое количество пользователей со старыми браузерами, как у нас, рекомендую совсем отключить SSLv3. Правильная конфигурация для Nginx в части протоколов будет выглядеть так:
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    Что касается выбора ciphersuites или наборов шифров и хеш-функций, которые будут использоваться для TLS-соединений, — веб-серверы должны использовать только безопасные шифры. Здесь важно соблюсти баланс между безопасностью, скоростью, производительностью и совместимостью.

    Security vs. Perfomance


    Принято считать, что использование HTTPS очень затратно как с точки зрения производительности серверной стороны, так и скорости загрузки и рендеринга ресурсов на клиентской стороне. Отчасти это действительно так — неправильно настроенный HTTPS может добавлять 2 (и больше) Round Trip Times (RTT) при хендшейке.

    Для того чтобы нивелировать задержки, возникающие при внедрении HTTPS, используются следующие методики:

    1. Content Delivery Networks (CDN). За счет размещения точки терминации ближе к клиенту можно уменьшить RTT. Таким образом, сделав задержки, возникающие при внедрении HTTPS, незаметными. Яндекс успешно использует данную методику и постоянно наращивает число точек присутствия.

      image
    2. Оптимизация проверок статуса сертификата. В момент установления защищенного соединения некоторые браузеры проверяют статус отозванности сертификата сервера. Такие проверки позволяют удостовериться, что сертификат не был отозван владельцем Необходимость отозвать сертификат сервера может возникнуть, например, после компрометации приватных ключей. Так в массовом порядке сертификаты отзывались после обнаружения уязвимости Heartbleed.

    На сегодняшний день есть два основных протокола, используемых для проверки статусов сертификатов:
    • Certificate Revocation Lists. При использовании данного способа браузер по протоколу HTTP качает с URL, указанного в сертификате, список серийных номеров отозванных сертификатов. Данный список контролируется и подписывается CA. Так как файл со списком может быть большого размера, он кешируется на заданный срок чаще всего на 1 неделю).
    • Online Certificate Status Protocol.


    Так как оба протокола работают поверх HTTP и при этом проверка статуса сертификата является блокирующей процедурой, то, где именно расположены сервера, раздающие CRL или OCSP, респондеры, может непосредственно влиять на скорость TLS-хендшейка.

    Различные браузеры по-разному проверяют статусы сертификатов. Так Firefox использует только OCSP для обычных сертификатов, но для EV проверяется и CRL. IE и Opera проверяют и CRL, и OCSP, а Яндекс.Браузер и другие браузеры семейства Chromium не используют традиционных протоколов, полагаясь на CRLsets — списки отозванных сертификатов популярных ресурсов, которые поставляются вместе с обновлениями браузера.

    Для оптимизации проверок также был придуман механизм под называнием OCSP stapling, который позволяет передать клиенту ответ OCSP responder'а в виде TLS extension вместе с сертификатом. Все современные десктопные браузеры поддерживают OCSP stapling (кроме Safari).

    Включить OCSP stapling в nginx можно следующей директивой: ssl_stapling on;. При этом обязательно указать resolver.

    Но если у вас по-настоящему большой и нагруженный ресурс, скорее всего, вам захочется быть уверенными в том, что OCSP ответы, которые вы кешируете (Nginx кеширует ответы на 1 час), корректны.
    ssl_stapling_verify on;
    ssl_trusted_certificate /path/to/your_intermediate_CA_and_root_certs;


    При использовании OCSP stapling'а массовые ресурсы могут столкнуться с такой проблемой, как неправильное время на клиентской системе. Происходит это из-за того, что по стандарту время жизни ответа responder'а ограниченно четко заданным временным интервалом, а время на клиентской машине может отставать на 5-10-20 минут. Чтобы решить эту проблему для пользователей, нам пришлось научить сервера раздавать ответы спустя примерно сутки после их генерации (примерно то же самое мы делаем при выкладке новых сертификатов).

    Таким образом у нас появляется возможность показать предупреждение о неправильном времени тем людям, у которых системное время сбито на период до суток. Для того чтобы произвольно ротировать OCSP-ответы, используется директива "ssl_stapling_file". Для тех клиентов, которые не поддерживают OCSP stapling, мы используем кеширование ответов OCSP-респондеров в нашем CDN, тем самым сокращая время ответа.

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

    Использовать такие сертификаты могут себе позволить Удостоверяющие центра. Почти всегда они используются для OCSP responder'ов, так как при наличии точек проверки статуса в сертификате может заставить Internet Explorer проверить еще и статус сертификата самого OCSP responder'а, что создаст дополнительные задержки.
    Но даже при использовании OCSP stapling'а или короткоживущих сертификатов, стандартный TLS хендшейк (4 этапа) добавит 2 RTT задержки.

    Механизм TLS False Start позволяет отправить application данные после 3 этапа, не дожидаясь ответа сервера, таким образом сохранив 1 RTT. TLS False Start поддерживается браузерами семейства Chromium и Яндекс.Браузером, IE, Safari, Firefox.



    К сожалению, в отличие от браузеров, не все веб-сервера поддерживают данный механизм. Поэтому сигналом к использованию TLS False Start обычно являются следующие требования:
    • Сервер анонсирует NPN/ALPN (не требуется для Safari и IE);
    • Сервер использует Perfect Forward Secrecy ciphersuites.


    Perfect Forward Secrecy


    До SSLv3 атакующий, получивший доступ к приватному ключу сервера, мог пассивно расшифровать все коммуникации, которые прошли через сервер. Позднее был придуман механизм Forward Secrecy(иногда используют приставку Perfect), который использует протоколы согласования ключей (обычно на основе схемы Diffie-Hellman'а и гарантирует, что сессионные ключи не могут быть восстановлены, даже если атакующий получит доступ к приватному ключу сервера.

    Типичная конфигурация nginx для сервиса работающего c пользовательскими данными, выглядит так:
    ssl_prefer_server_ciphers on;
    ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;


    В данной конфигурации мы ставим максимальный приоритет AES со 128 битным сессионным ключом, который формируется по алогоритму Elliptic Curve Diffie Hellman (ECDH). Далее идут любые другие шифры с ECDH. Вторая «E» в аббревиатуре обозначает Ephemeral, т.е. сессионный ключ, существующий в пределах одного соединения.
    Далее разрешаем использовать обычный Diffie Hellman (EDH). Здесь важно отметить, что использование Diffie Hellman с размером ключа 2048 бит, может быть довольно затратным.

    Эта часть конфига обеспечивает нам поддержку PFS. Если вы используете процессоры с поддержкой AES-NI, то AES будет для вас бесплатным, с точки зрения ресурсов. Отключаем 3DES, разрешаем AES128 в не-PFS режиме. Оставляем 3DES и EDH и 3DES в CBC режиме для совместимости с совсем старыми клиентами. Отключаем небезопасный RC4 и прочее. При этом важно использовать самые новые версии OpenSSL, тогда «AES128» развернется в том числе в AEAD шифры.

    У PFS есть единственный недостаток — performance penalties. Современные веб-сервера (в том числе Nginx) используют event-driven модель. При этом ассиметричная криптография — чаще всего блокирующая операция, так как процесс веб-сервера блокируется, а обслуживаемые им клиенты страдают. Что мы можем оптимизировать в этом месте?

    1. SPDY.



      Если вы читали про опыт внедрения SPDY в Почте, то заметили, что SPDY позволяет сократить количество соединений, а значит, и количество хендшейков. В nginx 1.5+ SPDY включается добавлением 4 букв в конфиг (сервер должен быть собран со spdy модулем --with-http_spdy_module).

      listen 443 default spdy ssl;
    2. Использовать эллиптическую криптографию. Алгоритмы ассиметричной криптографии с использованием эллиптических кривых более эффективны, чем их классические прообразы, именно поэтому при настройке ciphersuite'ов мы увеличиваем приоритет для ECDH. Как я писал ранее, кроме использования ECDH можно использовать сертификаты с цифровой подписью на эллиптический кривых (ECDSA), что увеличит производительность.

      К сожалению, Windows XP < SP3 и некоторые другие браузеры, доля которых среди клиентов больших сайтов отлична от нуля, не поддерживают ECC сертификатов. Решением может стать использование разных сертификатов для разных клиентов, что позволит экономить ресурсы за счет более новых клиентов, которых большинство. Openssl версии 1.0.2 позволяет выбрать сертификат сервера в зависимости от параметров клиента. К сожалению, пока Nginx «из коробки» не позволяет использовать несколько сертификатов для одного сервера.
    3. Использовать session reuse. Переиспользование сессий позволяет не только сэкономить ресурсы сервера (исключается работа с ассиметричной криптографией) для PFS/False Start соединений, но и уменьшить задержку TLS хендшейка до 1RTT для обычных соединений.




    В данный момент существует два механизма session reuse:
    1. SSL session cache. Данный механизм строится на том, что на каждое соединение клиенту отдается уникальный идентификатор, а на сервере по данному идентификатору сохраняется сессионный ключ. Плюсом является поддержка почти всех, в том числе старых, браузеров. Минусом — необходимость синхронизации кешей, содержащих критичные данные, между физическими серверами и дата-центрами, что может приводить к проблемам безопасности.



      В случае с Nginx session cache будет работать только при условии, что клиент попадет на тот же реал, где происходил первоначальный SSL handshake. Мы все равно рекомендуем включать SSL session cache, так как он будет полезен для конфигураций с малым количеством реалов, где вероятность попадания пользователя на один и тот же реал выше.

      В nginx конфигурация будет выглядеть примерно так, где SOME_UNIQ_CACHE_NAME это имя кеша, которое рекомендуется использовать различные идентификаторы для различных сертификатов (не обязательно в nginx 1.7.5+, 1.6.2+), 128Mb — размер кеша, 28 часов — время жизни сессии.
      ssl_session_cache shared:SOME_UNIQ_CACHE_NAME:128m;

      ssl_session_timeout 28h;


      При увеличении времени жизни сессии, нужно быть готовым к тому, что в error логах могут появиться записи вида:
      2014/03/18 13:36:08 [crit] 18730#0: ngx_slab_alloc() failed: no memory in SSL session shared cache "SSL".

      Это связано с особенностью вытеснения данных из кеша сессий в nginx — осуществляется попытка выделить память под сессию, если лимит исчерпан, убивается одна из самых старых сессий и операция повторяется вновь. То есть сессия успешно добавляется в буфер, но в лог пишется ошибка при первом вызове функции аллокатора. Такие ошибки можно игнорировать — они не влияют на функциональность (исправлено в Nginx 1.4.7).
    2. TLS session tickets. Механизм поддерживается только браузерами семейства Chromium, в том числе Яндекс.Браузером, а также Firefox. В данном случае клиенту отправляется состояние сессии, зашифрованное ключом известным серверу, а также идентификатор ключа. При этом между серверами разделяются только ключи.



      В Nginx поддержка статических ключей для session tickets добавлена в версиях 1.5.8+. Настройка tls session tickets при работе с несколькими серверами делается следующим образом:
      ssl_session_ticket_key current.key;
      ssl_session_ticket_key prev.key;
      ssl_session_ticket_key prevprev.key;


      В данном случае current.key — ключ, который используется в настоящий момент времени. Prev.key — ключ, используемый N часов до начала использования current.key. Prevprev.key — ключ, используемый N часов до начала использования prev.key. Значение N должно быть равно указанному в ssl_session_timeout. Мы рекомендуем исходить из интервала в 28 часов.

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


    В Яндексе есть специальные механизмы для генерации и безопасной доставки ключей на конечные сервера.

    Приложения


    CSP


    После того как решены инфраструктурные проблемы, вернемся к приложениям. Первое, что вам необходимо будет сделать, — избавиться от т.н. mixed content'а. Здесь всё зависит от масштаба проекта, количества и качества кода. Где-то можно обойтись sed'ом, или средствами nginx, а где-то придется искать захардкоженные http схемы в DOM дереве. Нам на помощь пришел механизм Content Security Policy, о его внедрении наши коллеги из Почты писали ранее.

    Добавив такой заголовок на тестовый стенд вы получите репорты о любом контенте, который грузится по протоколам отличным от data: и https:
    Content-Security-Policy-Report-Only: default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report

    Secure Cookies


    После того как вы избавились от mixed content'а, важно сделать так, чтобы для cookies выставлялся атрибут Secure. Он говорит браузеру, что данные cookies нельзя отправлять через незащищенное соединение. Так в Яндексе пока существует две cookies — sessionid2 и Session_id, одна из которых отправляется только через защищенное соединение, а другая пока оставлена «небезопасной» для обратной совместимости. Без «безопасной» куки нельзя попасть в Почту, Диск и другие важные сервисы.

    Set-Cookie: session=1234567890abcdef; HttpOnly; Secure;

    HSTS


    И наконец, после того как вы проверили, что ваш сервис корректно работает по протоколу HTTPS, поставили редирект с HTTP версии на HTTPS, важно сообщить браузеру, что на данный ресурс больше нельзя ходить по незащищенному протоколу HTTP.

    Для этого был придуман заголовок HTTP Strict Transport Security.
    Strict-Transport-Security: max-age=31536000; includeSubdomains;

    Параметр max-age задает период (1 год), в течение котого должен использоваться защищенный протокол. Опциональный флаг includeSubdomains говорит о том, что на все поддомены данного домена также можно ходить только через зашифрованные соединения.

    Для того чтобы пользователи браузеров семейства Chromium и Firefox всегда использовали защищенные соединения, даже при первом обращении, можно добавить ваш ресурс в HSTS preload list браузера. Кроме того, что это обеспечит безопасность, это также сэкономит один редирект при первом обращении.

    Для этого нужно добавить в заголовок флаг «preload» и указать домен здесь: hstspreload.appspot.com.
    Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

    Например, Яндекс.Паспорт добавлен в preload list браузеров.

    Заключение


    Целиком конфигурация одного сервера nginx будет выглядеть примерно следующим образом:

    http {
    
    [...]
    
    ssl_stapling on;
    resolver 77.88.8.1; # или 127.0.0.1 если используется локальный
    
    keepalive_timeout     120 120;
    
    server {
        listen              443 ssl spdy;
        server_name         yourserver.com;
        ssl_certificate     /etc/nginx/ssl/cert.pem; # сертификат сервера
        ssl_certificate_key /etc/nginx/ssl/key.pem; # ключ сервера
        ssl_dhparam         /etc/nginx/ssl/dhparam.pem; # генерируется командой openssl dhparam 2048
        ssl_prefer_server_ciphers on;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
        ssl_session_cache    shared:SSL:64m;
        ssl_session_timeout  28h;
    
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;";
        add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
    
        location / {
            ...
        }
    }


    В заключение хочется добавить, что HTTPS постепенно становится стандартом де-факто для работы с WEB, и используется не только браузерами — большинство API мобильных приложений начинают работать по протоколу HTTPS. О некоторых особенностях безопасной реализации работы с HTTPS в мобильных можно узнать из доклада Юрия tracer0tong Леонычева на субботнике в Нижнем Новгороде.
    Яндекс
    558.88
    Как мы делаем Яндекс
    Share post

    Comments 97

      +17
      Вот это хорошая, годная статья, достойная Хабра!
      О некоторых ньюансах не знал, интересно!
        +13
        Например, о нюансах правописания слова «нюансы».
          +13
          Благодаря Вам узнал ещё и о нюансах правописания, спасибо!
          Прямо рубрика «Today I Learned».

          Статья, тем не менее, всё равно замечательная!
          +3
          Когда я был маленьким, а деревья большими, за такие комменты сливали карму и говорили, что для выражения согласия/поддержки есть кнопки голосования. Сейчас же под каждой статьей вижу «Круто!», «Спасибо!», «Спасибо, не знал!» и т.д. И люди радостно апвотают. Не торт.
            +5
            Потрачу один из своих 24 комментариев в сутки на ответ Вам.

            1) >Когда я был маленьким, а деревья большими…

            Я не намного позже Вас зарегистрирован на Хабре, а всего-то на полгода.

            P.S. Если возникнут вопросы по правописанию наречия «ненамного»/«намного» в разных случаях, то открываем «Словарь трудностей русского языка» под редакцией Розенталь Д. Э., Теленкова М. А. на странице 393.

            2) >… за такие комменты сливали карму…

            Хочу заметить, что она уже меня «слита», но, если Вам так хочется, можете поставить мне минус персонально.
            Также хочу заметить, что я не могу голосовать за топики кнопками голосования, именно по причине отрицательных циферок в профиле.

            3) >Сейчас же под каждой статьей вижу «Круто!», «Спасибо!», «Спасибо, не знал!» и т.д.

            Лично я под каждой статьёй подобного не пишу. Мне статья показалась достаточно подробной технически, лёгкой для восприятия и написана она была простым и понятным языком. Хочется, чтобы на Хабре именно такие статьи и преобладали. Именно поэтому я и решил выделить эту статью среди других и «проголосовать» именно комментарием.

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

            Спасибо!
              0
              В связи с недавними изменениями¹ карма у почти всех хабравчан обнулена. Хуже того, она может только уменьшаться. Поэтому пользователи в основном лишены возможности выражения поддержки в виде голосования. Вот и результат.

              С какого-то перепоя в ТМ считают, что недавние изменения™ вынудят кого-то написать хорошие посты, а не забить нафиг на ресурс. При том они совсем забыли, что если раньше получить плюс в карму было нелегко, то сейчас вообще нереально (голосующих тоже меньше).

              ¹ habrahabr.ru/company/tm/blog/235137/
                +2
                А если посты писать?
                  0
                  Ну, если вам повезёт, и вы написали более-менее приличный пост, то вы получите пару плюсиков в карму, что и близко не компенсирует глубину падения из-за невозрастающей кармы до этого.
                    0
                    Но зато наличие публикации (хотя бы одной) позволит тем, кто когда-либо захочет вам карму повысить, сделать это — ведь без статьи это невозможно.
                      0
                      Это миф. Таких плюсов, считайте, нет. Не компенсирует глубину падения и близко.
                0
                >Когда я был маленьким, а деревья большими
                Люди не апвотали, а плюсовали, в том числе. Впрочем, вы подобным не часто злоупотребляете.
              +2
              Так, на заметку, nginx анонсирует HTTPS через NPN/ALPN вне зависимости, включен SPDY или нет. Необходимым и достаточным условием здесь является современная версия OpenSSL с соответствующей поддержкой.
                –16
                А где вы сертификаты подписываете? У потенциального противника?
                  +10
                  Так получилось, что в хранилище корневых сертификатов Windows не оказалось ни одного, принадлежащего Российской компании.
                    +1
                    Кстати, у Ру-Центра и РБК есть промежуточные CA, но корневой сертификат — Comodo, Великобритания, которая входит в FVEY.

                    ssl-tools.net/certificates/15jtf8a-ru-center-high-assurance-services-ca
                    ssl-tools.net/certificates/fmbw8o-rbc-hc-high-assurance-services-ca
                      0
                      Промежуточные CA много у кого есть :)
                        0
                        Особенно от Comodo, «всем подряд» промежуточные раздают :).
                          +1
                          Ну вы же понимаете, что если рассуждать категориями «потенциальных противников», нет разницы какой Intermediate там будет — Российский или Британский.
                    +19
                    Ага. И железо у него же закупают. И ОС. И деньги через его же системы переводят.
                      0
                      У Яндекса CA польский, Unizeto Technologies ;).
                        –3
                        У них похоже много всяких, есть еще от французкого KEYNECTIS ( www.yandex.com например)
                        Это был риторический вопрос…
                          +1
                          Не много, на сегодняшний день в production — два внешних. Keynectis используется для обратной совместимости. Выбор CA тоже обусловлен некоторыми факторами, начиная c тех, которые описаны в статье, заканчивая тем, что и Польша и Франция не входят в FVEY.
                            0
                            Да, у Яндекс.Денег тоже Keynectis. Только он сейчас в Chrome зелёный замочек не показывает из-за SHA1.
                        0
                        ---> К сожалению, Windows XP < SP3 и некоторые браузеры, доля которых среди клиентов больших сайтов отлична от нуля, не поддерживают ECC-сертификатов.

                        На Windows XP с любым сервис-паком нет поддержки ECC в случае использования IE и Chrome. В Firefox есть.

                        ---> Так Яндекс.Браузер и другие браузеры семейства Chromium в ближайшие месяцы начнут помечать сертификаты, которые подписаны с использованием SHA-1 и срок действия которых истекает после 1 января 2016 года, как небезопасные.

                        2017 всё-таки.

                        ---> Все серверные конечные сертификаты, используемые для TLS, можно условно разделить по способу валидации — Extended Validated и прочие (чаще всего Domain Validated).

                        Вот эти прочие делятся на Domain Validation (проверка на уровне владения доменом) и Organization Validation (проверка документов организации). Примечательно, что Habrahabr, Geektimes, VK и даже некоторые онлайн-банкинги и ЭПС (например, Открытие и MangoPay) используют дешёвые Domain Validation. Как так? Даже на моих личных сайтах сертификаты Organization Validation.

                        ---> Яндекс.Браузер и другие браузеры семейства Chromium не используют традиционных протоколов, полагаясь на CRLsets — списки отозванных сертификатов популярных ресурсов, которые поставляются вместе с обновлениями браузера.

                        CRLsets — это просто днище. Я на этой неделе успешно открыл сайт, сертификат которого был отозван 9 месяцев назад. Сегодня уже не получилось.
                        Баг-трекер, в самом низу мои скрины — code.google.com/p/chromium/issues/detail?id=362696
                          +1
                          2017 всё-таки.


                          там постепенная деградация, всё, что экспирится в 2016 уже может (и должно) пугать пользователя.
                            0
                            Верно, только как раз с 2017 запрещаются все сертификаты SHA1 без возможности игнорирования, как сейчас MD5.
                              0
                              Я нигде не говорил, что их использование запрещается, я говорил в первую очередь о пометке и user experience.

                              P.S. В ближайшее время CA вообще перестанут выдавать SHA1 сертификаты.
                                0
                                Как раз с 2017 года запрещается, user experience для более быстрой миграции :).

                                А выдачей SHA1 по умолчанию до сих пор занимаются GeoTrust и Thawte, причём сертификаты Extended Validation, но вместо зелёной строки показывают серый замочек с жёлтым треугольником.
                                  +1
                                  cabforum.org/wp-content/uploads/BRv1.2.3.pdf
                                  п.9.4.2. — выдавать продолжат, но со сроком действия не позже 2017 года.
                                    0
                                    Это хорошо. Жаль только Ozon и Альфа-банк, у которых EV-сертификаты SHA1 от GeoTrust и Thawte соответственно. Причём на главной странице Альфа-Клик написано: «С 27 января «Альфа-Клик» прекращает поддержку устаревших веб-браузеров и операционных систем ниже OS X 10.5 и Windows XP SP3. Для корректной работы используйте: IE 7, Chrome 26, Firefox 1.5, Opera 9, Safari 3 или более новые.»
                                    Именно с таких версий ОС и браузеров начинается поддержка SHA2.

                                    Сбербанку повезло больше, им Thawte выдал SHA2, только у них в новости о прекращении поддержки версии Chrome и Opera неправильные написаны, 1 и 5 вместо 26 и 9 соответственно.
                                      +1
                                      Купить SHA2 можно и у Thawte, зависит от того, какую хеш-функцию вы укажете в CSR.
                                        0
                                        Интересно… Таким же способом запрашивается SHA2 у StartSSL и Gandi (реселлер Comodo). У Thawte такого на сайте не нашёл. Ведь чаще всего учитывается не хэш CSR, а выбор в процессе заказа на сайте CA.
                          0
                          ---> ssl_dhparam /etc/nginx/ssl/dhparam.pem; # генерируется командой openssl dhparam 2048

                          Лучше сразу указывать файл для сохранения, не придётся создавать файл и копипастить: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

                          Если используется ключ RSA 4096, то и параметры Диффи-Хеллмана тоже должны быть 4096: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
                          Я вот 2048 ни разу не использовал, с 1024 сразу на 4096 перешёл :).
                            +1
                            Не нужно использовать RSA 4096 — ооочень затратно на сервер-сайде.
                              0
                              Для Google и Яндекса действительно критично, а так, если средние проекты на мощных серверах, почему бы и нет? Это даже даст 100 баллов Key exchange в тесте SSL Labs, а не 90, как у самого ssllabs.com :). Но скоро эти баллы оттуда уберут, будут нормальные критерии.

                              Хотя гораздо лучше просто перейти на ECC. С одной стороны, ещё велика доля XP (8%), на котором ECC поддерживает только Firefox. С другой, это вынудит перейти на современные версии Windows. Нет мыслей, к какому времени сможете выкинуть поддержку XP?
                                0
                                Мы планируем жить с двумя сертификатами, ECC для новых браузеров и RSA 2048 для старых. Когда выкинем совсем — сложный вопрос, когда поймем, что пользователи не станут от этого несчастливы.
                                  0
                                  А почему Chrome в XP не поддерживает ECC? Использует системные реализации криптоалгоритмов?
                                    +1
                                    Chrome много чего использует от системы, и конкретно в этом случае поддержки ECC нет из-за слабой поддержки со стороны ОС.

                                    code.google.com/p/chromium/issues/detail?id=431176
                                    #3 agl@chromium.org
                                    This is a ClouldFlare ECDSA site and so it don't work in Windows XP: XP is too old to process ECDSA certificates.
                                    Status: WontFix

                                    code.google.com/p/chromium/issues/detail?id=436052
                                    #4 davidben@chromium.org
                                    Firefox ships its own set of root certificates and verifier as part of NSS, rather than the operating system's, which is why it can verify ECDSA certificates. Chrome on Windows has used the operating system's one since the beginning, so Chrome on XP has never been able to verify ECDSA in 38 or any prior version. Windows didn't add ECDSA support until Vista.
                                    #29 davidben@chromium.org
                                    The original XP ECDSA problem isn't likely to get fixed anytime soon I'm afraid. We'll need to build a new certificate verifier, which we are working on for other purposes, but it will take time before or if we can use it to replace the system one on XP.
                              +10
                              Спасибо за очень интересный пост!

                              Но, ребята из Яндекса, обращаю внимание на то, что пока вы не уберете главную страницу своего портала под SSL, все, кто вводят там пароль, могут этот пароль потерять ровно также, как если бы ваш паспорт не был бы вообще защищен SSL'ем.

                              Чтобы было понятно, о чем я говорю, ниже краткая инструкция, иллюстрирующая эту атаку:

                              1. Добавить такую строку в файл hosts:
                              104.236.202.205 yandex.ru www.yandex.ru yastatic.net
                              Это имитирует подмену DNS-ответов/MiTM
                              2. Перезапустить браузер (для конкретности — Firefox)
                              3. Открыть приватное окно Firefox
                              4. Зайти на yandex.ru
                              5. Дождаться полной прогрузки страницы, чтобы появилась форма ввода пароля
                              6. Ввести свой логин и пароль в форму, нажать enter
                              7. Вместо страницы яндекса увидеть страницу с приветствием

                              Как видите, пользователь пребывает в полной уверенности, что зашел на главную страницу Яндекса и ввел пароль в правильное место, а на самом деле эта страница уже перехвачена злоумышленником и вся остальная безопасность на почте и паспорте не спасает никак.
                                +12
                                Денис, не переживайте — мы давно и активно работаем над тем, чтобы перевести как главную, так и весь портал за HTTPS, более того — часть наших пользователей уже использует HTTPS Поиск, а часть периодически видит HTTPS Морду. Как только мы будем уверены (думаю, это будет довольно скоро), что пользователи не пострадают при переходе, мы переключим ее на HTTPS-only.
                                  +1
                                  Я использую главную яндекса для логина в московском метро :-). Потому что она самая доступная для открытия в разных браузерах и еще не перешла на https-only (там редирект на странницу логина работает только для трафика по http)
                                    0
                                    Удобнее всего g.co использовать (главная страница сокращалки Google для собственных сервисов). Адреса короче я ещё не встречал.
                                      0
                                      wi-fi.ru мой выбор
                                      0
                                      И ешё, я лично не хочу делиться своим поисковым траффиком ни с кем, кроме яндекса, потому что его снифают все кому не лень, начиная от прова последней мили до магистралов, по моему стойкому убеждению.

                                      Поэтому очень жду главную страницу по HTTPS. Можно узнать, как стать той элитной частью пользователей, которая уже использует HTTPS? Спсибо :)
                                        0
                                        Поиску уже сейчас доступен по https. Замечание по провайдерам справедливо.
                                          +1
                                          Сейчас увидел, что очень удобно гонять [ https://ya.ru/ ], с него выдача идёт тоже по https, за сим откланяюсь — но главную тоже ждём по https, у приснопамятной «корпорации добра» https так вообще принудительный :)
                                            0
                                            Ура, вижу что главная доступна по HTTPS [ https://www.yandex.ru/ ], свершилось! Ещё вижу, что вы доступны по IPv6:

                                            ping www.yandex.ru
                                            Обмен пакетами с www.yandex.ru [2a02:6b8::3] с 32 байтами данных:
                                            Ответ от 2a02:6b8::3: время=51мс
                                            Ответ от 2a02:6b8::3: время=82мс
                                            Ответ от 2a02:6b8::3: время=51мс
                                            Ответ от 2a02:6b8::3: время=53мс

                                            Такой пинг из Омска, так что всё норм… Спасибо за работу, марку держите :)
                                      +1
                                      ---> ssl_trusted_certificate /path/to/your_intermediate_CA_certs;

                                      В этой директиве корневой сертификат тоже должен быть.

                                      ---> Все современные браузеры поддерживают OCSP stapling.

                                      Android, iOS и Safari на OS X не поддерживают :(. Даже новейшие версии.

                                      ---> В nginx 1.5+ SPDY включается добавлением 4 букв в конфиг.

                                      Сам модуль SPDY должен быть, а его в стандартных пакетах нет. Было бы неплохо отметить, что требуется компиляция из исходников с параметром --with-http_spdy_module
                                      nginx.org/ru/docs/http/ngx_http_spdy_module.html
                                        +1
                                        Спасибо, добавил уточнения (похоже, некоторые вещи получились не совсем прозрачными).
                                          +1
                                          Если подключить оффициальный репозиторий с wiki.nginx.org/Install то SPDY там уже включен в билд, как минимум для RHEL
                                            0
                                            У меня Debian. Это ещё, может быть, зависит от ветки релизов.
                                              0
                                              А вы используете Debian репозиторий из коробки или подключенный с wiki.nginx.org/Install?
                                                0
                                                Подключённый stable.
                                                  0
                                                  Только что попробовал на своей Ubuntu 14.10 установить с Nginx репозитория:

                                                  # /usr/sbin/nginx -V
                                                  nginx version: nginx/1.6.2
                                                  TLS SNI support enabled
                                                  configure arguments: --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_spdy_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-dav-ext-module --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.6.2/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.6.2/debian/modules/ngx_http_substitutions_filter_module

                                                  Странно, что для Debian SPDY не включен.
                                                    0
                                                    SPDY включен там, где есть соответсвующая поддержка со стороны OpenSSL для NPN/ALPN. В Debian, как правило, антиквариат.
                                                      0
                                                      OpenSSL с поддержкой NPN, объявляет протокол http/1.1
                                                      OpenSSL с поддержкой ALPN — это 1.0.2, который для Debian ещё experimental.
                                                        0
                                                        Честно говоря, не очень понял о чем ваш комментарий. В наших репозиториях nginx для wheezy собран со SPDY-модулем, а для squeeze — без, поскольку в последнем OpenSSL версии 0.9.8, где никакой поддержки NPN/ALPN еще не было.
                                                          0
                                                          Вчера проверил, nginx оказался с SPDY. Странно, до недавнего времени его вроде не было. У меня wheezy.

                                                          И да, поддержка именно ALPN добавлена лишь в OpenSSL 1.0.2: www.openssl.org/news/openssl-1.0.2-notes.html
                                                          ALPN support.
                                                            +1
                                                            Между NPN и ALPN нет разницы с практической точки зрения.
                                                              0
                                                              Только вот стандартом стал именно ALPN, а поддержку NPN наоборот удалят будут. Если на сервере не будет поддержки именно ALPN, будет использоваться обычный HTTPS.

                                                              www.imperialviolet.org/2013/03/20/alpn.html
                                                              At some point after the end of 2014, I plan on removing NPN support from Chrome and Google servers. Any old servers and clients will continue to function just fine: they'll just use HTTPS.
                                              0
                                              Не, ну так то можно вообще gentoo поставить, там USE флаги используются ;)
                                            0
                                            Интересный материал, вопрос на счет ECC: по какому принципу выбирали кривую? Были какие-то дополнительные соображения, повлиявшие на выбор конкретной кривой (производительность, лучшая криптостойкость)?
                                              +1
                                              Большинство браузеров поддерживают вот эти кривые: secp256r1, secp384r1, может быть secp521r1, но реже. Выбирать особо не из чего, на своих сайтах я использую 384, но 256 считается достаточным.

                                              У Яндекса 256.
                                                0
                                                Про кривые можно почитать тут chrispacia.wordpress.com/2013/10/30/nsa-backdoors-and-bitcoin/
                                                0
                                                Даёшь SPDY на маркете!!! Уже устал тормозить :(
                                                  0
                                                  Для начала, там нужно хотяб https дать ), что тормозов как раз таки добавит.
                                                  Но там же куча внешнего разношерстного контента, вероятно, еще осталась. А тут spdy мало поможет.
                                                    0
                                                    Маркет с недавних пор https-only.
                                                  0
                                                  Яндекс, это все очень хорошо и правильно! И spdy тоже здорово, сам юзаю у себя везде.
                                                  Но, ёпрст! Когда вы уже начнете индексировать картинки по https без глупой ситуации с оставлением доступности их по http?
                                                  После поста, было обещано, что робот проиндексирует, через некоторое время, после того, как мы внедрим костыль.
                                                  Прошло (внимание!!!) пол-года. Картинок в поиске по картинкам нету.
                                                  Zalina молчит.
                                                  Я уже даже в той компании не работаю. У меня новый большой проект, и я опять вынужден оставлять эту http дыру из-за глупостей с картинками. И мало того, картинки что на том, что на новом ресурсе — важнейший контент. А их в индексе нету.

                                                  пруф: geektimes.ru/post/228693/
                                                    0
                                                    Спасибо, сделаю всё от меня зависящее, чтобы проблема решилась как можно быстрее.
                                                    0
                                                    В nginx 1.5+ SPDY включается добавлением 4 букв в конфиг.

                                                    Ребята, аккуратней с stable веткой до 1.6x. В ней на энжиникс нужен патч для включенного spdy, чтобы после f5 на страничке вы видели, (внимание!!!), те-же пресловутые картинки, а не «дырку от бублика»: trac.nginx.org/nginx/ticket/428
                                                      0
                                                      Всё что до 1.6.2 (на сегодняшний день) вообще использоваться не должно, безотносительно SPDY. Со SPDY лучше (и вообще лучше в большинстве случаев) использовать mainline (1.7.9 на текущий момент).
                                                        0
                                                        mainline по-умолчанию без image-filter-module идет, и у меня (почему-то) никак не хотел пересобираться с ним.
                                                        Пришлось брать последний stable, накатывать патч, пересобирать.
                                                        По-другому, заставить корректно кешироваться обработанные в nginx картинки при включенном spdy никак не удалось.
                                                        0
                                                        У меня эта беда и на 1.7.9 вылазит почему-то. Не на каждый f5, а наоборот, только для совсем новых юзеров.
                                                        0
                                                        Кстати, а почему Яндекс поиск некотгрые запросы перекидывает на https? Это идет тестирование? Пнимер запроса «сказка о потерянном времени» да и многие другие сказки
                                                          0
                                                          Да, они в каком-то из топиков в комментах писали, что идет тестирование, поэтому некоторых пользователей перекидывает на поиск по https, у некоторых — главная страница по https отдается.
                                                            0
                                                            Google однажды взял, и вообще включил https принудительно, ибо нефиг! снифать провам ваш личный поисковый трафик.
                                                            0
                                                            Пользуясь случаем, хочу спросить, а что вдруг у вас почтовик, как минимум на получение почты (25 порт) перестал устанавливать соединение по TLS с использованием ECC? У Вас там postfix на Windows XP? :)

                                                            Если раньше мой постфикс слал почту в яндекс, будучи залоченым на этот cipher list:
                                                            ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

                                                            то теперь только на этот:
                                                            ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
                                                              +1
                                                              Спасибо, передал коллегам из Почты, очень похоже на баг.
                                                                +1
                                                                Простите за долгий ответ — проверьте пожалуйста исправлена ли проблема для вас?
                                                                  +1
                                                                  Лучше поздно, чем никогда. Спасибо, проблема для меня исправлена:
                                                                  postfix/smtp[14659]: Verified TLS connection established to mx.yandex.ru[2a02:6b8::89]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
                                                                  0
                                                                  -
                                                                  0
                                                                  ssl_session_timeout 28h;

                                                                  А чем это обосновано?
                                                                    0
                                                                    Дневной распорядок пользователя более-менее одинаковый, поэтому берем 24 часа с момента установления первого соединения +4 часа в качестве разброса.
                                                                    0
                                                                    Из Вики:
                                                                    On December 8, 2014 a variation of the POODLE vulnerability that impacted TLS was announced.[6]
                                                                      0
                                                                      только в продуктах некоторых вендоров hardware load balancer'ов, OpenSSL эта проблема не касается.
                                                                      0
                                                                      Ой, чой-то веб-морда вашей почты не отвечает… Уже с полчаса как, и ТП не отписывается…
                                                                        0
                                                                        Яндекс, учитесь у НСПК, как надо переходить на TLS за пару минут и без всяких напрягов.

                                                                        support.nspk.ru
                                                                        habrastorage.org/files/525/a09/486/525a09486016401aa5e125771d0b2d93.PNG

                                                                        Сразу видно, что крупнейший (в скором времени) процессинг страны всерьез думает о безопасности!
                                                                          0
                                                                          У них собственная PKI, только не являющаяся доверенной, в отличие от Яндекса.
                                                                          Ещё у них на сервере включён SSL 3 и даже SSL 2, только на практике SSL 2 использовать не получится, к счастью.
                                                                            0
                                                                            Там вообще самоподписанный сертификат.
                                                                              0
                                                                              Самоподписанный по цепочке выше, но сервер цепочку не отправляет. Возможно, в конце цепочки действительно доверенный сертификат, но тогда это ошибка в конфигурации, нужно отправлять цепочку. Если портал только для внутреннего использования, промежутки и корень уже прописаны доверенными у работников.
                                                                          0
                                                                          Забавно, столько умных людей на Хабре, но никто не задался вопрос зачем Яндексу использовать кривые, которые к тому же еще рекомендованы NIST(читай NSA), сейчас очевидно, что первым должен идти DHE-RSA-AES128-GCM-SHA256 и только с tls1.2. То есть обычный эфимерный дефи-хелман RSA с нормальным AES которые не ломается под tls1.2. Если хочется кривые, то нужно подождать Curve25519.
                                                                            0
                                                                            В случае крупного сайта разница в производительности DHE+RSA и ECDHE+RSA в почти два раза тоже может сыграть некоторую роль.
                                                                              0
                                                                              Да, но тут же разговор про безопасность, а не про нужное кол-во фронтов, чтобы шифрованный трафик отдать.
                                                                              0
                                                                              Firefox не поддерживает аутентифицированное шифрование совместно с традиционным DHE, только Chrome и IE, а у них в плане HTTPS есть проблемы серьёзнее, так что от отказа от ECC особого эффекта не вижу, мне эта идея кажется сомнительной.
                                                                                0
                                                                                Вот что показывает для текущего Firefox ssl labs, насколько я понял пока нет DHE AES 128/256 GCM для tls1.2, но это не так страшно.
                                                                                TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Forward Secrecy 128
                                                                                TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy2 128
                                                                                TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) Forward Secrecy 256
                                                                              0
                                                                              С OCSP stapling в nginx есть ещё одна подстава: директива ssl_stapling on реально включит stapling только если он включен для default_server'а. В противном случае nginx будет молчать как партизан. На это стоит обратить внимание, если используются виртуальные хосты и SNI.

                                                                              Мало в каких руководствах это упоминается. В частности, в документации nginx'а это тоже не было упомянуто. Неплохое руководство: blog.tyk.nu/blog/ocsp-stapling-in-nginx/.

                                                                              Про то, что в случае nginx надо все тесты (после перечитывания конфигурации/перезапуска) надо делать два раза (на первом запросе он сам пойдет в OCSP responder), что в ssl_certificate или ssl_trusted_certificates должны присутствовать intermediate CA, — не писал только ленивый.
                                                                                0
                                                                                Блин, за default_server спасибо. Всё заработало.
                                                                                Причем у меня стоит nginx 1.11 и использую конфигурацию с RSA и ECDSA сертификатами. OCSP отдавал ответ на RSA сертификат, но молчал с ECDSA. Добавил default_server, два раза тыкнул и готово.

                                                                              Only users with full accounts can post comments. Log in, please.