Comments 97
UFO just landed and posted this here
Например, о нюансах правописания слова «нюансы».
Когда я был маленьким, а деревья большими, за такие комменты сливали карму и говорили, что для выражения согласия/поддержки есть кнопки голосования. Сейчас же под каждой статьей вижу «Круто!», «Спасибо!», «Спасибо, не знал!» и т.д. И люди радостно апвотают. Не торт.
Так, на заметку, nginx анонсирует HTTPS через NPN/ALPN вне зависимости, включен SPDY или нет. Необходимым и достаточным условием здесь является современная версия OpenSSL с соответствующей поддержкой.
А где вы сертификаты подписываете? У потенциального противника?
Так получилось, что в хранилище корневых сертификатов Windows не оказалось ни одного, принадлежащего Российской компании.
Кстати, у Ру-Центра и РБК есть промежуточные 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
ssl-tools.net/certificates/15jtf8a-ru-center-high-assurance-services-ca
ssl-tools.net/certificates/fmbw8o-rbc-hc-high-assurance-services-ca
Ага. И железо у него же закупают. И ОС. И деньги через его же системы переводят.
У Яндекса CA польский, Unizeto Technologies ;).
У них похоже много всяких, есть еще от французкого KEYNECTIS ( www.yandex.com например)
Это был риторический вопрос…
Это был риторический вопрос…
Не много, на сегодняшний день в production — два внешних. Keynectis используется для обратной совместимости. Выбор CA тоже обусловлен некоторыми факторами, начиная c тех, которые описаны в статье, заканчивая тем, что и Польша и Франция не входят в FVEY.
Да, у Яндекс.Денег тоже Keynectis. Только он сейчас в Chrome зелёный замочек не показывает из-за SHA1.
---> К сожалению, 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
На 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
2017 всё-таки.
там постепенная деградация, всё, что экспирится в 2016 уже может (и должно) пугать пользователя.
Верно, только как раз с 2017 запрещаются все сертификаты SHA1 без возможности игнорирования, как сейчас MD5.
Я нигде не говорил, что их использование запрещается, я говорил в первую очередь о пометке и user experience.
P.S. В ближайшее время CA вообще перестанут выдавать SHA1 сертификаты.
P.S. В ближайшее время CA вообще перестанут выдавать SHA1 сертификаты.
Как раз с 2017 года запрещается, user experience для более быстрой миграции :).
А выдачей SHA1 по умолчанию до сих пор занимаются GeoTrust и Thawte, причём сертификаты Extended Validation, но вместо зелёной строки показывают серый замочек с жёлтым треугольником.
А выдачей SHA1 по умолчанию до сих пор занимаются GeoTrust и Thawte, причём сертификаты Extended Validation, но вместо зелёной строки показывают серый замочек с жёлтым треугольником.
cabforum.org/wp-content/uploads/BRv1.2.3.pdf
п.9.4.2. — выдавать продолжат, но со сроком действия не позже 2017 года.
п.9.4.2. — выдавать продолжат, но со сроком действия не позже 2017 года.
Это хорошо. Жаль только 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 соответственно.
Именно с таких версий ОС и браузеров начинается поддержка SHA2.
Сбербанку повезло больше, им Thawte выдал SHA2, только у них в новости о прекращении поддержки версии Chrome и Opera неправильные написаны, 1 и 5 вместо 26 и 9 соответственно.
---> 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 перешёл :).
Лучше сразу указывать файл для сохранения, не придётся создавать файл и копипастить: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
Если используется ключ RSA 4096, то и параметры Диффи-Хеллмана тоже должны быть 4096: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
Я вот 2048 ни разу не использовал, с 1024 сразу на 4096 перешёл :).
Не нужно использовать RSA 4096 — ооочень затратно на сервер-сайде.
Для Google и Яндекса действительно критично, а так, если средние проекты на мощных серверах, почему бы и нет? Это даже даст 100 баллов Key exchange в тесте SSL Labs, а не 90, как у самого ssllabs.com :). Но скоро эти баллы оттуда уберут, будут нормальные критерии.
Хотя гораздо лучше просто перейти на ECC. С одной стороны, ещё велика доля XP (8%), на котором ECC поддерживает только Firefox. С другой, это вынудит перейти на современные версии Windows. Нет мыслей, к какому времени сможете выкинуть поддержку XP?
Хотя гораздо лучше просто перейти на ECC. С одной стороны, ещё велика доля XP (8%), на котором ECC поддерживает только Firefox. С другой, это вынудит перейти на современные версии Windows. Нет мыслей, к какому времени сможете выкинуть поддержку XP?
Мы планируем жить с двумя сертификатами, ECC для новых браузеров и RSA 2048 для старых. Когда выкинем совсем — сложный вопрос, когда поймем, что пользователи не станут от этого несчастливы.
А почему Chrome в XP не поддерживает ECC? Использует системные реализации криптоалгоритмов?
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.
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.
Спасибо за очень интересный пост!
Но, ребята из Яндекса, обращаю внимание на то, что пока вы не уберете главную страницу своего портала под 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. Вместо страницы яндекса увидеть страницу с приветствием
Как видите, пользователь пребывает в полной уверенности, что зашел на главную страницу Яндекса и ввел пароль в правильное место, а на самом деле эта страница уже перехвачена злоумышленником и вся остальная безопасность на почте и паспорте не спасает никак.
Но, ребята из Яндекса, обращаю внимание на то, что пока вы не уберете главную страницу своего портала под 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. Вместо страницы яндекса увидеть страницу с приветствием
Как видите, пользователь пребывает в полной уверенности, что зашел на главную страницу Яндекса и ввел пароль в правильное место, а на самом деле эта страница уже перехвачена злоумышленником и вся остальная безопасность на почте и паспорте не спасает никак.
Денис, не переживайте — мы давно и активно работаем над тем, чтобы перевести как главную, так и весь портал за HTTPS, более того — часть наших пользователей уже использует HTTPS Поиск, а часть периодически видит HTTPS Морду. Как только мы будем уверены (думаю, это будет довольно скоро), что пользователи не пострадают при переходе, мы переключим ее на HTTPS-only.
Я использую главную яндекса для логина в московском метро :-). Потому что она самая доступная для открытия в разных браузерах и еще не перешла на https-only (там редирект на странницу логина работает только для трафика по http)
Удобнее всего g.co использовать (главная страница сокращалки Google для собственных сервисов). Адреса короче я ещё не встречал.
wi-fi.ru мой выбор
И ешё, я лично не хочу делиться своим поисковым траффиком ни с кем, кроме яндекса, потому что его снифают все кому не лень, начиная от прова последней мили до магистралов, по моему стойкому убеждению.
Поэтому очень жду главную страницу по HTTPS. Можно узнать, как стать той элитной частью пользователей, которая уже использует HTTPS? Спсибо :)
Поэтому очень жду главную страницу по HTTPS. Можно узнать, как стать той элитной частью пользователей, которая уже использует HTTPS? Спсибо :)
Поиску уже сейчас доступен по https. Замечание по провайдерам справедливо.
Сейчас увидел, что очень удобно гонять [ https://ya.ru/ ], с него выдача идёт тоже по https, за сим откланяюсь — но главную тоже ждём по https, у приснопамятной «корпорации добра» https так вообще принудительный :)
Ура, вижу что главная доступна по 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мс
Такой пинг из Омска, так что всё норм… Спасибо за работу, марку держите :)
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мс
Такой пинг из Омска, так что всё норм… Спасибо за работу, марку держите :)
---> 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
В этой директиве корневой сертификат тоже должен быть.
---> Все современные браузеры поддерживают 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
Спасибо, добавил уточнения (похоже, некоторые вещи получились не совсем прозрачными).
Если подключить оффициальный репозиторий с wiki.nginx.org/Install то SPDY там уже включен в билд, как минимум для RHEL
У меня Debian. Это ещё, может быть, зависит от ветки релизов.
А вы используете Debian репозиторий из коробки или подключенный с wiki.nginx.org/Install?
Подключённый stable.
Только что попробовал на своей 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 не включен.
# /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 не включен.
SPDY включен там, где есть соответсвующая поддержка со стороны OpenSSL для NPN/ALPN. В Debian, как правило, антиквариат.
OpenSSL с поддержкой NPN, объявляет протокол http/1.1
OpenSSL с поддержкой ALPN — это 1.0.2, который для Debian ещё experimental.
OpenSSL с поддержкой ALPN — это 1.0.2, который для Debian ещё experimental.
Честно говоря, не очень понял о чем ваш комментарий. В наших репозиториях nginx для wheezy собран со SPDY-модулем, а для squeeze — без, поскольку в последнем OpenSSL версии 0.9.8, где никакой поддержки NPN/ALPN еще не было.
Вчера проверил, nginx оказался с SPDY. Странно, до недавнего времени его вроде не было. У меня wheezy.
И да, поддержка именно ALPN добавлена лишь в OpenSSL 1.0.2: www.openssl.org/news/openssl-1.0.2-notes.html
И да, поддержка именно ALPN добавлена лишь в OpenSSL 1.0.2: www.openssl.org/news/openssl-1.0.2-notes.html
ALPN support.
Между NPN и ALPN нет разницы с практической точки зрения.
Только вот стандартом стал именно ALPN, а поддержку NPN наоборот удалят будут. Если на сервере не будет поддержки именно ALPN, будет использоваться обычный HTTPS.
www.imperialviolet.org/2013/03/20/alpn.html
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.
Не, ну так то можно вообще gentoo поставить, там USE флаги используются ;)
Интересный материал, вопрос на счет ECC: по какому принципу выбирали кривую? Были какие-то дополнительные соображения, повлиявшие на выбор конкретной кривой (производительность, лучшая криптостойкость)?
Большинство браузеров поддерживают вот эти кривые: secp256r1, secp384r1, может быть secp521r1, но реже. Выбирать особо не из чего, на своих сайтах я использую 384, но 256 считается достаточным.
У Яндекса 256.
У Яндекса 256.
Про кривые можно почитать тут chrispacia.wordpress.com/2013/10/30/nsa-backdoors-and-bitcoin/
Даёшь SPDY на маркете!!! Уже устал тормозить :(
Яндекс, это все очень хорошо и правильно! И spdy тоже здорово, сам юзаю у себя везде.
Но, ёпрст! Когда вы уже начнете индексировать картинки по https без глупой ситуации с оставлением доступности их по http?
После поста, было обещано, что робот проиндексирует, через некоторое время, после того, как мы внедрим костыль.
Прошло (внимание!!!) пол-года. Картинок в поиске по картинкам нету.
Zalina молчит.
Я уже даже в той компании не работаю. У меня новый большой проект, и я опять вынужден оставлять эту http дыру из-за глупостей с картинками. И мало того, картинки что на том, что на новом ресурсе — важнейший контент. А их в индексе нету.
пруф: geektimes.ru/post/228693/
Но, ёпрст! Когда вы уже начнете индексировать картинки по https без глупой ситуации с оставлением доступности их по http?
После поста, было обещано, что робот проиндексирует, через некоторое время, после того, как мы внедрим костыль.
Прошло (внимание!!!) пол-года. Картинок в поиске по картинкам нету.
Zalina молчит.
Я уже даже в той компании не работаю. У меня новый большой проект, и я опять вынужден оставлять эту http дыру из-за глупостей с картинками. И мало того, картинки что на том, что на новом ресурсе — важнейший контент. А их в индексе нету.
пруф: geektimes.ru/post/228693/
В nginx 1.5+ SPDY включается добавлением 4 букв в конфиг.
Ребята, аккуратней с stable веткой до 1.6x. В ней на энжиникс нужен патч для включенного spdy, чтобы после f5 на страничке вы видели, (внимание!!!), те-же пресловутые картинки, а не «дырку от бублика»: trac.nginx.org/nginx/ticket/428
Всё что до 1.6.2 (на сегодняшний день) вообще использоваться не должно, безотносительно SPDY. Со SPDY лучше (и вообще лучше в большинстве случаев) использовать mainline (1.7.9 на текущий момент).
У меня эта беда и на 1.7.9 вылазит почему-то. Не на каждый f5, а наоборот, только для совсем новых юзеров.
Кстати, а почему Яндекс поиск некотгрые запросы перекидывает на https? Это идет тестирование? Пнимер запроса «сказка о потерянном времени» да и многие другие сказки
Пользуясь случаем, хочу спросить, а что вдруг у вас почтовик, как минимум на получение почты (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
Если раньше мой постфикс слал почту в яндекс, будучи залоченым на этот 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
ssl_session_timeout 28h;
А чем это обосновано?
А чем это обосновано?
Из Вики:
On December 8, 2014 a variation of the POODLE vulnerability that impacted TLS was announced.[6]
Ой, чой-то веб-морда вашей почты не отвечает… Уже с полчаса как, и ТП не отписывается…
Яндекс, учитесь у НСПК, как надо переходить на TLS за пару минут и без всяких напрягов.
support.nspk.ru
habrastorage.org/files/525/a09/486/525a09486016401aa5e125771d0b2d93.PNG
Сразу видно, что крупнейший (в скором времени) процессинг страны всерьез думает о безопасности!
support.nspk.ru
habrastorage.org/files/525/a09/486/525a09486016401aa5e125771d0b2d93.PNG
Сразу видно, что крупнейший (в скором времени) процессинг страны всерьез думает о безопасности!
У них собственная PKI, только не являющаяся доверенной, в отличие от Яндекса.
Ещё у них на сервере включён SSL 3 и даже SSL 2, только на практике SSL 2 использовать не получится, к счастью.
Ещё у них на сервере включён SSL 3 и даже SSL 2, только на практике SSL 2 использовать не получится, к счастью.
Там вообще самоподписанный сертификат.
Самоподписанный по цепочке выше, но сервер цепочку не отправляет. Возможно, в конце цепочки действительно доверенный сертификат, но тогда это ошибка в конфигурации, нужно отправлять цепочку. Если портал только для внутреннего использования, промежутки и корень уже прописаны доверенными у работников.
Забавно, столько умных людей на Хабре, но никто не задался вопрос зачем Яндексу использовать кривые, которые к тому же еще рекомендованы NIST(читай NSA), сейчас очевидно, что первым должен идти DHE-RSA-AES128-GCM-SHA256 и только с tls1.2. То есть обычный эфимерный дефи-хелман RSA с нормальным AES которые не ломается под tls1.2. Если хочется кривые, то нужно подождать Curve25519.
В случае крупного сайта разница в производительности DHE+RSA и ECDHE+RSA в почти два раза тоже может сыграть некоторую роль.
Firefox не поддерживает аутентифицированное шифрование совместно с традиционным DHE, только Chrome и IE, а у них в плане HTTPS есть проблемы серьёзнее, так что от отказа от ECC особого эффекта не вижу, мне эта идея кажется сомнительной.
Вот что показывает для текущего 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
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
С OCSP stapling в nginx есть ещё одна подстава: директива
Мало в каких руководствах это упоминается. В частности, в документации nginx'а это тоже не было упомянуто. Неплохое руководство: blog.tyk.nu/blog/ocsp-stapling-in-nginx/.
Про то, что в случае nginx надо все тесты (после перечитывания конфигурации/перезапуска) надо делать два раза (на первом запросе он сам пойдет в OCSP responder), что в ssl_certificate или ssl_trusted_certificates должны присутствовать intermediate CA, — не писал только ленивый.
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, — не писал только ленивый.
Sign up to leave a comment.
Как и зачем мы делаем TLS в Яндексе