Настройка ssl и hsts в nginx

Я хочу перенаправить с http на https и использовать hsts

https://hstspreload.org/
(тест не пройден) Ошибка: нет заголовка HSTS Ошибка ответа: нет Заголовок HSTS присутствует в ответе.

Заодно как я могу перенаправить и настроить hsts?

P.S Я настроил балансировку нагрузки с помощью сертификата aws ssl и elb.

/etc/nginx/conf.d/default.conf

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name My_domain;

if ($http_x_forwarded_proto = "http") {
    return 301 https://$server_name$request_uri;
}

location / {
    root /usr/share/nginx/html;
    try_files $uri $uri/ /index.html;
}

location /api/ {
    proxy_pass              http://localhost:8080;
}

server {
    listen 443 ssl;
    server_name My_domain;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

person Andrew Nam    schedule 13.04.2018    source источник
comment
Если пересылка не указана, перенаправление не выполняется.   -  person Andrew Nam    schedule 13.04.2018


Ответы (2)


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

Я предполагаю, что вы выгружаете свой SSL на свой ELB и отправляете открытые HTTP-сообщения в Nginx с заголовком HTTP_X_FORWARDED_PROTO, установленным на исходную схему.

Поэтому, если пользователь переходит на https://www.example.com, он выгружает SSL / TLS и направляет трафик на http://www.example.com с HTTP_X_FORWARDED_PROTO, установленным на «https». В этом сценарии нет перенаправления (поскольку пользователь уже использует HTTPS), но также нет заголовка HSTS (поскольку пользователь не использует HTTPS для nginx, и вы устанавливаете этот заголовок только в конфигурации своего сервера 443). Вы должны добавить это на свой сервер с портом 80, чтобы также обслуживать заголовок HSTS для этого сценария:

if ($http_x_forwarded_proto = "https") {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Технически вы не должны обслуживать заголовок HSTS через HTTP и только через HTTPS, поэтому лучше установить его на уровне балансировки нагрузки, но я думаю, что с заголовком $http_x_forwarded_proto это нормально.

Однако, если мое предположение верно, то это доказывает, что вы неправильно используете HSTS, поэтому было бы упущением с моей стороны не добавить здесь предупреждение.

HSTS не лишен рисков.

HSTS отлично подходит для решения того факта, что в настоящее время Интернет по умолчанию не поддерживает HTTPS, и это приводит к различным рискам безопасности. Однако это сопряжено с определенными рисками, если вам когда-либо понадобится использовать HTTP. Например, если у вас есть поддомены, которые вы еще не преобразовали в HTTPS (например, blog.example.com), или если вы используете тот же домен для внутренних сайтов, которые еще не преобразовали (например, intranet.example.com) или сайтов разработки ( dev.example.com). Последнее также может быть проблемой, потому что HSTS не позволяет пропустить ошибки HTTPS (например, при использовании самозаверяющего сертификата для ваших доменов разработчиков). Это не значит, что вам не следует использовать HSTS - но вы должны полностью понять его и протестировать, прежде чем причинить себе (и своей организации) много боли.

По этой причине рекомендуется начинать с небольшого максимального возраста, а не переходить на полный год (максимальный возраст = 31536000) и наращивать. Вместо того, чтобы идти с полной суммой и ломать вещи. Таким образом, если вы найдете сайт, который нужно преобразовать, вы не заблокируете его в течение года или до тех пор, пока не перейдете на HTTPS.

Это особенно верно для предварительной загрузки, когда вы вставляете заголовок в базу кода браузеров, чтобы он был включен с самого начала, даже до того, как вы посетили сайт. Вы в принципе не можете отменить это (Chrome потребуется не менее 3 месяцев, чтобы удалить его, а другие браузеры не указывают сроки). Таким образом, поскольку это в основном необратимо, вам НИКОГДА не следует использовать предварительную загрузку, пока вы не полностью протестируете его, что, похоже, у вас еще не было. У Chrome есть проблема с отслеживанием всех ошибок, которые сделали сайты там, где они есть. просил предзагрузку а потом сломал вещи. У меня есть блог об этой опасности, поскольку есть другие. Кроме того, у предварительной загрузки есть некоторые другие требования (вы должны добавить атрибут preload в свой заголовок, и вы должны обслуживать этот заголовок в своем базовом домене (https://example.com)), с которыми вы, похоже, не встречаетесь.

Проблема с базовым доменом может особенно вызвать проблемы, если, например, вы никогда не посещаете его обычно, поэтому тестирование https://www.example.com выглядит нормально, а http://intranet.example.com по-прежнему работает (как и вы (мы никогда не устанавливаем заголовок HSTS в базовом домене, чтобы его можно было продолжать отправлять по HTTP), а затем вы выполняете предварительную загрузку и запускаете - http://intranet.example.com перестает работать. Самый простой способ проверить это - добавить ресурс из этого базового домена на ваш www-сайт (например, https://example.com/pixel.png), который заставит заголовок HSTS для базового домена для всех, кто посетит ваш сайт.

HSTS великолепен. Каждый сайт должен использовать его, и каждый сайт должен использовать только HTTPS, но пока они этого не сделают, это сопряжено с определенными рисками. Убедитесь, что вы понимаете это при развертывании. И делайте это медленно и увеличивайте максимальный возраст. И только потом переходите к предварительной нагрузке.

person Barry Pollard    schedule 13.04.2018
comment
Большое спасибо за ваш совет - person Andrew Nam; 13.04.2018

Чтобы успешно пройти тест на https://hstspreload.org/, не забудьте добавить директиву предварительной загрузки в конфигурацию заголовка. :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Это не является частью спецификации, но Google рекомендует включить его в ответ

person druss    schedule 24.11.2019