Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 85
SSL уже настраивал, SPDY — очень интересно
Прирост в скорости или снижение нагрузки на сервер есть?
Прирост в скорости или снижение нагрузки на сервер есть?
К сожалению не было возможности протестировать, но судя по документации — да.
Я обьединил разные прочитанные материалы просто в конфиг, довёл до ума по тестам и просто поделился. Статей на эту тему последнее время было много, но единого конфига я не увидел, поэтому решился опубликовать свои наработки.
А как насчет OCSP stapling?
Что в этой строке add_header Strict-Transport-Security «max-age=31536000; includeSubDomains; preload» означает preload? Вы собираетесь свой сайт в браузерный preload list включать?
ну я же написал, когда мы описываем includeSubDomains мы оговариваем, что мы ставим рестрикт на принятие поддоменов без трастед. а прелоад запрещает ходить на домены, которые сертификаты не защищают. Там болдом выделено предупреждение в статье.
Ок, отвечу сам себе.
«Recommended: If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari), then use:
…
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.»
Отсюда.
«Recommended: If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari), then use:
…
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.»
Отсюда.
preload — это ваше разрешение на добавление вашего сайта в предзагруженный HSTS-список Google Chrome. Если у вас это прописано, любой может зайти на hstspreload.appspot.com и запросить у Google добавление вашего сайта в браузер, чтобы даже самое первое посещение было сразу по HTTPS. Да, и это всем будет видно из исходников.
Хм, ваша статья мягко говоря не первая на эту тему. И далеко не полная. Лучше всего на тему настройки SSL помогает вики мозиллы.
Это шутка? На автора-то обрати внимание.
Есть поверие, что поисковики не очень хорошо относятся к контенту, когда находят его 1 в 1 на другом сайте. И на авторство они не смотрят.
Хабрахабр — не место для копипастеров. Размещение полностью скопированного контента с других сайтов запрещено — даже при использовании гиперссылки на источник. Мы за авторские материалы.
Хабрахабр — не ЖЖ и не центр мирового кросспостинга. Не нужно копировать публикации из других блогов и сайтов, указывая, что ранее они были опубликованы в другом месте.
Это мой блог. Статью изначально писал там, после редактирования опубликовал тут.
Копипаста — это воровство. Я в своём блоге редактирую материал, как только я считаю, что материал готов к публикации, я переношу это сюда — не вижу ничего криминального.
Это вот так важно в контексте данного поста? Да, в приведённом конфиге явно указано имя хоста, но я не имел цели как-то его пиарить — там пиарить-то нечего, этому бложику месяц и я его использую для редактирования черновиков. Мне кажется вы из мухи слона сделали.
смешно читать претензии о перепостинге авторского контента от человека который так ни в один пост и не смог =)
О ужас, и что же произойдет с хабром?
Если он будет размещать свои посты только в своем блоге — их никто не прочитает.
Если он будет размещать свои посты только на хабре — о его блоге никто не узнает.
Отстаньте от человека, поборник морали.
Если он будет размещать свои посты только в своем блоге — их никто не прочитает.
Если он будет размещать свои посты только на хабре — о его блоге никто не узнает.
Отстаньте от человека, поборник морали.
Согласен с кейсом, а как быть, если я просто технический специалист, я периодически записываю свои работы на своём сайте ( блоге ), а потом, если вижу, что материал достоин публикации просто отдаю его тут? Я не хочу подстраиваться под коньюктуру Хабра, я знаю, что результаты моей работы многим понадобятся тут. Где логика? Вы предлагаете мне тратить своё время, чтобы читать правила и накачивать себе карму? Это того не стоит, карма качается в реале на работе.
А разве это правило вообще работает? Его же сплошь и рядом все нарушают. И никому, кроме как, владельцам площадки, это вреда не несёт. Соответственно если бы админы выразили своё недовольство, это было бы логично, т.к. это их деньги, но выражать недовольство обычным пользователям, мне кажется, не совсем резонно.
Постить сначала на Хабр, а когда его проиндексируют — к себе в блог и писать внизу пометку, что написано для Хабра.
Именно поэтому пусть автор поменяет дату поста в блоге на +1 час или +1 день, и будет миру мир!
Вы наверное не понимаете, что если раньше люди целенаправленно писали на ИТ ресурсы, то теперь люди делятся материалом.
Я согласен с тем, что чтобы иметь возможность поделится материалом, надо соблюдать правила ресурса, где материал размещают. Именно поэтому нужна «игра с датами».
Так же я замечу, что многие держат блог не для извлечения прибыли с рекламы или счетчиков, а потому, что хочется однажды оказаться полезным человеку, который нагуглит свою проблему уже решенной у кого-то.
Вы наверное не понимаете, что если раньше люди целенаправленно писали на ИТ ресурсы, то теперь люди делятся материалом.
Я согласен с тем, что чтобы иметь возможность поделится материалом, надо соблюдать правила ресурса, где материал размещают. Именно поэтому нужна «игра с датами».
Так же я замечу, что многие держат блог не для извлечения прибыли с рекламы или счетчиков, а потому, что хочется однажды оказаться полезным человеку, который нагуглит свою проблему уже решенной у кого-то.
Я согласен поддержать с вами диалог, при наличии у вас собственного материала.
поравил время в блоге)
А я считаю, что аудитории данного ресурса мои работы полезны.
Вы неверно трактуете правила:
Если первоисточник хабр, то такие формулировки не работают.
Что является первоисточником? Ресурс, на которое материал появился раньше. Все просто.
Размещение полностью скопированного контента с других сайтов запрещено — даже при использовании гиперссылки на источник. Мы за авторские материалы.
Не нужно копировать публикации из других блогов и сайтов, указывая, что ранее они были опубликованы в другом месте.
Если первоисточник хабр, то такие формулировки не работают.
Что является первоисточником? Ресурс, на которое материал появился раньше. Все просто.
Не хочу с вами спорить, но мои глаза ясно видят, что данная статья на хабре была опубликована вчера (11 марта), а пост в блоге судя по Atom'у
2015-03-12T14:34:05+03:00— а это сегодня. Я только что проверил.
А что вы хотите доказать? Технически он мог быть в 2 часа ночи, спустя часы после публикации на хабре, и ничего против не сказать.
Вы сейчас трактуете правила, как вы их видите. Я трактую как я их вижу.
Официальный ответ — за администрацией проекта, и я уверен, что эти люди поставят точки над i, стоит ли публиковать на хабре поста, а затем через несколько часов и на персональных сайтах или нет. Изъявляете ли вы желание связаться с ней?
Можете не отвечать на вопрос, я увижу, пропадет ли эта замечательная статья у 531 подписчика или нет.
Вы сейчас трактуете правила, как вы их видите. Я трактую как я их вижу.
Официальный ответ — за администрацией проекта, и я уверен, что эти люди поставят точки над i, стоит ли публиковать на хабре поста, а затем через несколько часов и на персональных сайтах или нет. Изъявляете ли вы желание связаться с ней?
Можете не отвечать на вопрос, я увижу, пропадет ли эта замечательная статья у 531 подписчика или нет.
В конечном счёте, ИМХО, из-за вашего соблюдения этого правила, все проиграли. Включая владельцев этого ресурса.
Кстати. Поправьте линки на Gravatar чтобы аватары тоже грузились по https — для полноты гармонии и зеленого замочка в адресной строке
Спасибо.
Довел до A+, включив Forward Secrecy и SPDY.
Довел до A+, включив Forward Secrecy и SPDY.
На заметку: SPDY для A+ не требуется, но станет на одно замечание меньше у сервиса проверки GlobalSign (что-то вроде русской версии SSL Labs, но не обновлялась с апреля 2014).
Я бы ещё добавил про HPKP: developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
На скорость особо не влияет, но защита лучше.
На скорость особо не влияет, но защита лучше.
С PKP придётся даже девятым IE пожертвовать, не говоря про всякие Оперы 12.х и прочий антиквариат.
Жертвовать не надо. Это ведь просто заголовок, который читают только те, кто умеет.
Если браузер не поддерживает, то он просто проигнорирует этот заголовок, но сам сайт будет работать. Без жертв.
Если браузер не поддерживает, то он просто проигнорирует этот заголовок, но сам сайт будет работать. Без жертв.
Ну да, с HSTS то же самое. Возможно, такие опасения из-за того, что заголовок без "X-" в начале. Только согласно RFC6648, так делать уже и не следует.
КМК, корректнее редирект с 80 порта делать вот так:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
rewrite ^ https://$server_name$request_uri? permanent;
}
Ну и, собственно, на всякий случай листинг кусочка конфига, который спокойно проходит на А+:
Внедряется за пару минут буквально, больше времени на выписку сертификатов и их заливку уходит. Ничего нигде не падает, из софт-специфик вещей приходилось только немного подкрутить конфиг Mediawiki, чтобы она не выдавала mixed-content, а тому же Вордпрессу, phpBB и куче всего прочего — вообще до фонаря, абсолютно так же работает, как и напрямки.
тык
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
rewrite ^ https://$server_name$request_uri? permanent;
}
server {
listen 80;
server_name example2.com www.example2.com;
rewrite ^(.*) $scheme://example.com$request_uri permanent;
}
server {
# port on which we're listening for incoming connections
listen 443 ssl spdy;
# 40x error pages
error_page 404 /404.html;
error_page 403 /403.html;
error_page 500 /500.html;
error_page 502 /502.html;
# defining a zone for domain to answer to
server_name example.com www.example.com;
ssl on;
ssl_certificate /etc/nginx/conf.d/example.com.unified.crt;
ssl_certificate_key /etc/nginx/conf.d/example.com.unified.key;
ssl_session_cache shared:SSL:5m;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+ECDSA+AESGCM:AES128+EECDH:AES128+EDH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!ADH';
ssl_prefer_server_ciphers on;
ssl_stapling on;
resolver 8.8.8.8 8.8.4.4 208.67.222.222 valid=300s;
resolver_timeout 10s;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Strict-Transport-Security max-age=31536000;
Внедряется за пару минут буквально, больше времени на выписку сертификатов и их заливку уходит. Ничего нигде не падает, из софт-специфик вещей приходилось только немного подкрутить конфиг Mediawiki, чтобы она не выдавала mixed-content, а тому же Вордпрессу, phpBB и куче всего прочего — вообще до фонаря, абсолютно так же работает, как и напрямки.
И зачем тут rewrite после return?
Конфиг не идеальный. 24 часа на таймаут сессии — чрезвычайно много. 10 минут достаточно. За 24 часа браузер точно очистит уже информацию о сессии.
PFS будет работать и без указания dhparam, только будут использоваться 1024-битные ключи. Да и 4096 dhparam значительно замедляет сервер по сравнению с 2048.
Cipherlist, вроде, нормальный, но можно было бы просто HIGH использовать и поотключать ненужное и небезопасное.
PFS будет работать и без указания dhparam, только будут использоваться 1024-битные ключи. Да и 4096 dhparam значительно замедляет сервер по сравнению с 2048.
Cipherlist, вроде, нормальный, но можно было бы просто HIGH использовать и поотключать ненужное и небезопасное.
1024-битные параметры Диффи-Хеллмана уже считаются слабыми, скоро с ними получить A+ будет нельзя, минимум 2048.
4096 или 2048 — это уже в зависимости от ключа.
4096 или 2048 — это уже в зависимости от ключа.
Да я не спорю. Просто заметил, что PFS будет работать и без dhparam, а в статье говорится другое.
Это с какой стороны посмотреть. Со слабыми параметрами обеспечивать PFS, именно P, сомнительно. Кстати, в баге о присваивании A+ таким сайтам предложил вообще не считать DHE 1024 как обеспечивающий FS: github.com/ssllabs/ssllabs-scan/issues/80
Кстати, в баге о присваивании A+ таким сайтам предложил вообще не считать DHE 1024 как обеспечивающий FS: github.com/ssllabs/ssllabs-scan/issues/80Там только предложение снять плашку ROBUST.
Ну да, ROBUST — это когда сайт поддерживает не только Диффи-Хеллман на эллиптических кривых, но и традиционный, а если у традиционного слабые параметры, должно быть только «с современными браузерами», как у google.com, который традиционный DHE не умеет.
Только наоборот.
В плане? :)
www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96
Вот сервер, не умеющий обычный DHE, только ECDHE. Старые клиенты (Android 2, Java 6 и OpenSSL 0.9.8) согласовывают RSA, потому что не умеют ECDHE, от этого и результат «With modern browsers».
www.ssllabs.com/ssltest/analyze.html?d=crypto.cat
Этот умеет DHE 4096 и получает «With most browsers ROBUST».
www.ssllabs.com/ssltest/analyze.html?d=www.fastmail.com&s=66.111.4.148
У этого DHE 1024 с рейтингом A+ и ROBUST, что свидетельствует о поддержке DHE, но с слабыми параметрами такого сообщения быть не должно.
www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96
Вот сервер, не умеющий обычный DHE, только ECDHE. Старые клиенты (Android 2, Java 6 и OpenSSL 0.9.8) согласовывают RSA, потому что не умеют ECDHE, от этого и результат «With modern browsers».
www.ssllabs.com/ssltest/analyze.html?d=crypto.cat
Этот умеет DHE 4096 и получает «With most browsers ROBUST».
www.ssllabs.com/ssltest/analyze.html?d=www.fastmail.com&s=66.111.4.148
У этого DHE 1024 с рейтингом A+ и ROBUST, что свидетельствует о поддержке DHE, но с слабыми параметрами такого сообщения быть не должно.
А, вот как оно работает. Я думал, что ROBUST дают тогда, когда есть поддержка ECDHE, а не дают, когда только DHE.
Только наоборот :). Если точнее, то:
«With modern browsers» дают в случае согласовывания какого-либо Диффи-Хеллмана как минимум со всеми браузерами, помеченными зелёной буквой R справа от их названия.
Если хотя бы один браузер с зелёным R согласовывает RSA, будет жёлтое «With some browsers». Кстати, это типичный случай для серверов, которые не умеют ECDHE, но умеют DHE. С Internet Explorer ситуация наоборот, Microsoft имеет тенденцию не поддерживать DHE, но поддерживать ECDHE. Исключение — современные версии, поддерживающие DHE совместно с аутентифицированным шифрованием.
Пример наглядно: www.ssllabs.com/ssltest/analyze.html?d=mozilla.org Для таких случаев я предлагал показывать конкретное предупреждение, что сервер не обеспечивает PFS именно с Internet Explorer, но особо не заинтересовались.
«With most browsers ROBUST» дают в случае использования DHE и/или ECDHE для всех успешных рукопожатий, кроме IE на XP.
«With modern browsers» дают в случае согласовывания какого-либо Диффи-Хеллмана как минимум со всеми браузерами, помеченными зелёной буквой R справа от их названия.
Если хотя бы один браузер с зелёным R согласовывает RSA, будет жёлтое «With some browsers». Кстати, это типичный случай для серверов, которые не умеют ECDHE, но умеют DHE. С Internet Explorer ситуация наоборот, Microsoft имеет тенденцию не поддерживать DHE, но поддерживать ECDHE. Исключение — современные версии, поддерживающие DHE совместно с аутентифицированным шифрованием.
Пример наглядно: www.ssllabs.com/ssltest/analyze.html?d=mozilla.org Для таких случаев я предлагал показывать конкретное предупреждение, что сервер не обеспечивает PFS именно с Internet Explorer, но особо не заинтересовались.
«With most browsers ROBUST» дают в случае использования DHE и/или ECDHE для всех успешных рукопожатий, кроме IE на XP.
Обычно пользуюсь этой инструкцией:
wiki.mozilla.org/Security/Server_Side_TLS
и этой генерилкой конфига:
mozilla.github.io/server-side-tls/ssl-config-generator/
wiki.mozilla.org/Security/Server_Side_TLS
и этой генерилкой конфига:
mozilla.github.io/server-side-tls/ssl-config-generator/
Строго говоря, последний хедер и ssl_stapling для A+ необязательны.
Для A+ пока достаточно иметь нормальный cipherlist и поддержку HSTS, Forward Secrecy, TLS_FALLBACK_SCSV (сборка с openssl > 1.0.1i).
Для A+ пока достаточно иметь нормальный cipherlist и поддержку HSTS, Forward Secrecy, TLS_FALLBACK_SCSV (сборка с openssl > 1.0.1i).
ssl onуже устарел
Вместо этой директивы рекомендуется использовать параметр ssl директивы listen.
nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl
Да, Java 6/45 не проходит тест
На всякий случай, чтобы у вас было понимание происходящего: SSL Labs не умеет (на данный момент) проверять доверие к сайту для каждого симулированного клиента, проверяется физическая возможность подключения без учёта доверия. Java 6 не проходит тест из-за невозможности обработки параметров Диффи-Хеллмана больше 1024 бит.
Java 6 прошла бы тест Handshake simulation при отсутствии ssl_dhparam в конфиге (даже несмотря на недоверие к StartCom), но все наборы шифров с использование традиционного Диффи-Хеллмана были бы помечены слабыми. A+ на данный момент такие сайты всё ещё получают, но это баг в рейтинге, который уже исправляется.
Java 6 прошла бы тест Handshake simulation при отсутствии ssl_dhparam в конфиге (даже несмотря на недоверие к StartCom), но все наборы шифров с использование традиционного Диффи-Хеллмана были бы помечены слабыми. A+ на данный момент такие сайты всё ещё получают, но это баг в рейтинге, который уже исправляется.
Ещё java 6 и всякая win xp не пройдут, если есть SNI.
Есть ещё такой момент: возможность посещения сайта такими клиентами зависит от сертификата и конфигурации дефолтного HTTPS-хоста. Даже если SNI-хост поддерживает только самые современные протоколы и шифры, старые клиенты без поддержки SNI могут посещать ваш сайт в случае наличия общих алгоритмов с дефолтным хостом. В таком случае сначала клиенты получают ошибку несовпадения адреса сервера (чужой сертификат), в случае игнорирования сайт открывается, но сединение аутентифицировано и зашифровано сертификатом и настройками дефолтного хоста, а не вашего. Видите проблему безопасности?
Такая проблема возможна и с современными браузерами, особенно Internet Explorer, где поддерживаемые протоколы SSL/TLS переключаются проще всего. Речь идёт о поддержке браузером SSL 2. Это вынуждает браузер отправлять сообщение ClientHello в соответствующем формате, который не поддерживает расширения, включая SNI. Таким образом, в случае включённого SSL 2 посетитель так же получит ошибку несовпадения адреса и шифрование соединения чужим ключом. Так может продолжаться до бесконечности. Вместо чужого сертификата сервер должен сразу обрывать соединение в случае получения ClientHello в формате SSL 2, что вынудит пользователя поправить настройки браузера.
Подведём итог:
— Сервер не должен обслуживать клиентов без поддержки SNI, то есть у таких старых клиентов не должно быть общих алгоритмов с дефолтным хостом. Самый эффективный метод — дефолтный сертификат ECDSA вместо RSA. Если клиент не поддерживает SNI, он также не поддерживает ECDSA, и в результате получит ошибку рукопожатия вместо чужого сертификата. С марта 2015 это утверждение справедливо для всех симулируемых в SSL Labs клиентов.
— Сервер не должен быть совместим с рукопожатиями SSL 2. Посмотреть можно в самом конце отчёта SSL Labs: SSL 2 handshake compatibility. Методы решения этой проблемы ещё до конца не вывел, но вопрос прорабатывается :).
P.S. Уж столько комментариев оставил, что можно было и свою статью запилить.
Такая проблема возможна и с современными браузерами, особенно Internet Explorer, где поддерживаемые протоколы SSL/TLS переключаются проще всего. Речь идёт о поддержке браузером SSL 2. Это вынуждает браузер отправлять сообщение ClientHello в соответствующем формате, который не поддерживает расширения, включая SNI. Таким образом, в случае включённого SSL 2 посетитель так же получит ошибку несовпадения адреса и шифрование соединения чужим ключом. Так может продолжаться до бесконечности. Вместо чужого сертификата сервер должен сразу обрывать соединение в случае получения ClientHello в формате SSL 2, что вынудит пользователя поправить настройки браузера.
Подведём итог:
— Сервер не должен обслуживать клиентов без поддержки SNI, то есть у таких старых клиентов не должно быть общих алгоритмов с дефолтным хостом. Самый эффективный метод — дефолтный сертификат ECDSA вместо RSA. Если клиент не поддерживает SNI, он также не поддерживает ECDSA, и в результате получит ошибку рукопожатия вместо чужого сертификата. С марта 2015 это утверждение справедливо для всех симулируемых в SSL Labs клиентов.
— Сервер не должен быть совместим с рукопожатиями SSL 2. Посмотреть можно в самом конце отчёта SSL Labs: SSL 2 handshake compatibility. Методы решения этой проблемы ещё до конца не вывел, но вопрос прорабатывается :).
P.S. Уж столько комментариев оставил, что можно было и свою статью запилить.
Добавлю, что при «ssl_stapling», nginx сам лезет в интернет за OCSP ответом.
В схемах, где выхода в интернет нет (некоторые типы балансировки и т.д.), это не заработает.
Там можно попробовать «ssl_stapling_file».
В схемах, где выхода в интернет нет (некоторые типы балансировки и т.д.), это не заработает.
Там можно попробовать «ssl_stapling_file».
Gist, всё давно известно, только никому не приходило в голову по этому поводу писать статьи на хабр. Посмотрите, вдруг что интересное можно перенести в статью.
Полезная заметка.
Ещё более полезные комментарии.
Особенно тот, который ведёт на gist.github.com/plentz/6737338 «Best nginx configuration for improved security(and performance)»
Ещё более полезные комментарии.
Особенно тот, который ведёт на gist.github.com/plentz/6737338 «Best nginx configuration for improved security(and performance)»
>>Ну и директивой ssl_prefer_server_ciphers on; принуждаем nginx это всё строго соблюдать.
На самом деле нет. ssl_prefer_server_ciphers on — указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские и все.
А относительно заголовков Content-Security-Policy и Content-Security-Policy-Report-Only нужно быть очень аккуратным и вначале тестировать политику через Content-Security-Policy-Report-Only и только потом писать заголовки Content-Security-Policy
На этот счет есть хорошая статья от Yandex -> http://habrahabr.ru/company/yandex/blog/206508/
И есть пара хороших сервисов для сбора отчетов и тестирования:
https://report-uri.io — для сбора отчетов о нарушении Content-Security-Policy и HTTP Public Key Pinning
https://securityheaders.io — удобный сервис для просмотра заголовков, которые отдает Ваш сервер.
На самом деле нет. ssl_prefer_server_ciphers on — указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские и все.
А относительно заголовков Content-Security-Policy и Content-Security-Policy-Report-Only нужно быть очень аккуратным и вначале тестировать политику через Content-Security-Policy-Report-Only и только потом писать заголовки Content-Security-Policy
На этот счет есть хорошая статья от Yandex -> http://habrahabr.ru/company/yandex/blog/206508/
И есть пара хороших сервисов для сбора отчетов и тестирования:
https://report-uri.io — для сбора отчетов о нарушении Content-Security-Policy и HTTP Public Key Pinning
https://securityheaders.io — удобный сервис для просмотра заголовков, которые отдает Ваш сервер.
Спасибо, хорошая инструкция.
Разве что SPDY уже deprecated.
На современных версиях nginx'а он тоже отсутствует. Но есть http2, который можно прописать вместо него.
Правда, при использовании openssl 1.0.1 оно всё равно не будет работать в chrome, т. к. гугл отключил поддержку NPN и требует стандартного ALPN, который появился только в openssl 1.0.2. Если, конечно, его не бэкпортировали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Nginx и https. Получаем класс А+