SLY_G 9 мая 2015 в 21:27

Как перевести сайт целиком на постоянный HTTPS для всех

6 мин

44K

Nginx*

Перевод

+35

Комментарии 38

farcaller 9 мая 2015 в 22:07

Аналогично для nginx решается через:

listen 80;
rewrite ^ https://$server_name$request_uri? permanent;

для HTTP, и

listen 443 ssl spdy;

ssl on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_certificate /etc/nginx/ssl/xxx.pem;
ssl_certificate_key /etc/nginx/ssl/yyy.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_protocols TLSv1.1 TLSv1.2; для поддержки старого андроида
ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:DES-CBC3-SHA:!DES:!RC4:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS:!CAMELLIA:!SEED";
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;

ssl_stapling on;
ssl_stapling_verify off;
ssl_trusted_certificate /etc/nginx/ssl/zzz.pem;
resolver 8.8.8.8;

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

для HTTPS

+39

farcaller 9 мая 2015 в 22:25

для поддержки старого андроида

конечно же имелось в виду — если не нужна поддержка старого андроида

jonic 9 мая 2015 в 23:16

Тот случай когда коммент полезнее топика.

+20

AlexWinner 10 мая 2015 в 05:46

Я бы только заменил

rewrite ^ https://$server_name$request_uri? permanent;

на

return 301 https://$server_name$request_uri;

ИМХО return логичнее и читабельнее.

shamanis 11 мая 2015 в 05:59

А я заменил https://$server_name$request_uri на https://$server_name$uri, т.к. у Nginx есть баг при редиректе дублировать GET-переменные. Сам столкнулся недавно. Но, возможно, данный баг возникает только при стеке с Django.

VBart 11 мая 2015 в 11:57

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

Если в строке замены указаны новые аргументы запроса, то предыдущие аргументы запроса добавляются после них. Если такое поведение нежелательно, можно отказаться от этого добавления, указав в конце строки замены знак вопроса, например:
rewrite ^/users/(.*)$ /show?user=$1? last;

Обратите внимание, что у человека выше было указано правильно: https://$server_name$request_uri?, хотя как уже было сказано, правильнее будет использовать return.

НЛО прилетело и опубликовало эту надпись здесь

farcaller 10 мая 2015 в 10:54

Почти что идентично, оно основано как раз на этом посте.

armab 10 мая 2015 в 13:18

У меня уже давно правильно сконфигурированный SSL является одним из факторов оценки IT компании (и ее команды).

К сожалению, очень многие не парятся и в тестах их SSL www.ssllabs.com/ssltest показывает целый букет брешей.
Наиболее встречаемые: POODLE, использование слабого RC4, использование SHA1 сертификата вместо SHA2.

Реально эти тесты косвенно показывают:

- насколько компания реально заботится о безопасности
- насколько админ/команда технически подкованы
  - следят за новостями безопасности
  - если такие простые элементы безопасности не учтены, то что же творится в самой системе?
  - косвенно: насколько hire отдел/CEO квалифицирован при выборе работников

-2

НЛО прилетело и опубликовало эту надпись здесь

armab 10 мая 2015 в 16:53

Вы правы, это сугубо субъективная оценка и наверное планка слишком высока.
Здесь главное не впадать в крайности. Это можно применять к tech-компаниям с 10+ человек в команде, где уже какие-то тех. процессы устоялись и обычно кто-то занимается серверами. Конечно, бесмысленно говорить об очень маленьких компаниях вроде «2 человека и собака» и конечно есть исключения из правил.

Приведу пример:
Западный стартап, с помощью которого можно заказать чартер/частный самолет. $6к+ средняя транзакция. Полный букет брешей в SSL тесте — первый плохой знак.
Смотрим глубже — PHP 5.3 светится в хедерах. Дальше — domain.com/blog/readme.html — старая дырявая версия Wordpress.
Можно ли уже сказать что-то о технической части проекта? Спрашиваем овнера: «Что происходит?». Оказывается работают индусы за копейки :)

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

Просто это не единственный фактор, это часть паттерна, некий звоночек.

НЛО прилетело и опубликовало эту надпись здесь

reji 10 мая 2015 в 21:11

[ sarcasm on ]
Обоже, Яндекс и Google нанимают слабых айтишников!
[ sarcasm off ]

armab 10 мая 2015 в 21:33

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

armab 10 мая 2015 в 22:22

Проблема достаточно большая.

Интерактивная инфографика со средней температурой по интернету для топ 1М сайтов:
www.trustworthyinternet.org/ssl-pulse

У четверти сайтов - мусорный F рейтинг

Те четверть сайтов такие

grossws 10 мая 2015 в 18:18

Ещё можно добавить server_tokens off; в http/server, чтобы заголовок Server: nginx/1.x.y отдавался без версии (Server: nginx).

AutomationD 10 мая 2015 в 03:02

Расскажите, кто пользовался HAProxy и nginx в качестве балансировщика, какие преимущества HAProxy имеет перед nginx?

vaniaPooh 10 мая 2015 в 05:18

Если я не ошибаюсь, то Nginx в бесплатной версии не умеет делать активную балансировку, т.е. если реплика завалилась, то пользователь это увидит с определенной вероятностью.

-2

AutomationD 10 мая 2015 в 05:54

Читаю документацию по бесплатной версии:

Reverse proxy implementation in nginx includes in-band (or passive) server health checks. If the response from a particular server fails with an error, nginx will mark this server as failed, and will try to avoid selecting this server for subsequent inbound requests for a while.

The max_fails directive sets the number of consecutive unsuccessful attempts to communicate with the server that should happen during fail_timeout. By default, max_fails is set to 1. When it is set to 0, health checks are disabled for this server. The fail_timeout parameter also defines how long the server will be marked as failed. After fail_timeout interval following the server failure, nginx will start to gracefully probe the server with the live client’s requests. If the probes have been successful, the server is marked as a live one.

То есть если health check не прошел, трафик перестает идти на эту ноду.

AlexWinner 10 мая 2015 в 07:38

Вот как раз в вашей цитате написано: «passive» health checks. То есть, запрос от пользователя пойдет на упавшую ноду, провисит там до таймаута, и потом nginx может переслать его на здоровую ноду. Таким образом, пользователь будет ждать всё это время таймаута. (После этого да, nginx может пометить ноду как упавшую).
В то время как varnish и haproxy умеют делать active health checks — они сами посылают раз в какое-то время запросы на ноды, чтобы проверить их.

AutomationD 10 мая 2015 в 07:39

Да, точно. Ключ в 'in-band (or passive)'. Спасибо!
Есть github.com/yaoweibin/nginx_upstream_check_module, wiki.nginx.org/HttpHealthcheckModule и еще пара модулей которые должны реализовать активные проверки, никто не использует, случайно?

Alukardd 10 мая 2015 в 12:16

На нагруженном проекте, это не важно, т.к. запрос от пользователя придёт с большой долей вероятности раньше чем отработает active check…

trublast 10 мая 2015 в 16:42

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

kemko 10 мая 2015 в 07:40

И не только. Если один бэкэнд провалил запрос — его можно попытаться всё-таки выполнить на другом: nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
Это, конечно, не полноценный health check, но уже что-то.

n1nj4p0w3r 10 мая 2015 в 05:38

Что вспомнилось из практики:
— proxy protocol для tcp, что позволяет с удобствами балансировать тот-же postfix
— kerberos/ntlm при L7 балансировке
— haproxy умеет RPC over HTTP v1 и RPC over HTTP v2, что позволяет ему выполнять L7 балансировку до exchange rpc over http (outlook anywhere) и rdp over http (MS Terminal Services Gateway)

Упоминая L7 балансировку я прежде всего я имею ввиду ssl offloading, а уж потом игры с заголовками, куками и т.д.

AutomationD 10 мая 2015 в 06:01

Про TCP и Kerberos/NTLM понял, спасибо.
Но ведь nginx умеет (и умел) ssl offloading, а http заголовки и cookies (в том числе через lua) хорошо должны быть доступны?

n1nj4p0w3r 10 мая 2015 в 06:24

Я не имел ввиду, что nginx не умеет ssl offoading или ковыряние в заголовках, я обратил внимание на то, что ssl offloading в моих юзкейсах критичен, а kerberos/rpc over http при tcp балансировке можно получить и на nginx.

Botkin 10 мая 2015 в 09:31

Проксирование виндовых серверов с NTLM смог осилить только на haproxy. Может, конечно, руки кривые, но этот продукт показался мне очень дружелюбным и очевидным в настройке.
До haproxy извращался с arr в IIS (писал на хабр об этом)

VBart 21 мая 2015 в 18:53

Вдруг кому пригодится: Load Balancing Microsoft Exchange with NGINX Plus. Оно в значительной степени верно и для бесплатной версии.

RPC over HTTP прекрасно работает начиная с 1.7.11.

onthefly 10 мая 2015 в 09:02

добавление ещё одного приложения в стопку

слово «стек» можно было и не переводить

SLY_G 10 мая 2015 в 21:23

Иногда мозг в режиме перевода начинает переводить всё подряд. Исправил.

alkresin 10 мая 2015 в 09:19

Эра незашифрованного веба проходит, и это хорошо

А что хорошего-то?

НЛО прилетело и опубликовало эту надпись здесь

questor 10 мая 2015 в 11:33

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