Pull to refresh

Comments 38

Аналогично для 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
для поддержки старого андроида
конечно же имелось в виду — если не нужна поддержка старого андроида
Тот случай когда коммент полезнее топика.
Я бы только заменил

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

на

return 301 https://$server_name$request_uri;

ИМХО return логичнее и читабельнее.
А я заменил https://$server_name$request_uri на https://$server_name$uri, т.к. у Nginx есть баг при редиректе дублировать GET-переменные. Сам столкнулся недавно. Но, возможно, данный баг возникает только при стеке с Django.
Баг на самом деле не в nginx, и заключается в том, что люди не читают документацию, где черными русскими буквами на белом фоне написано:
Если в строке замены указаны новые аргументы запроса, то предыдущие аргументы запроса добавляются после них. Если такое поведение нежелательно, можно отказаться от этого добавления, указав в конце строки замены знак вопроса, например:

rewrite ^/users/(.*)$ /show?user=$1? last;
Обратите внимание, что у человека выше было указано правильно: https://$server_name$request_uri?, хотя как уже было сказано, правильнее будет использовать return.
UFO just landed and posted this here
Почти что идентично, оно основано как раз на этом посте.
У меня уже давно правильно сконфигурированный SSL является одним из факторов оценки IT компании (и ее команды).

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

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

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


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

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

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

Просто это не единственный фактор, это часть паттерна, некий звоночек.
UFO just landed and posted this here
Не надо троллить. Там цепочка для поддержки старых браузеров
Проблема достаточно большая.

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

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


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

Ещё можно добавить server_tokens off; в http/server, чтобы заголовок Server: nginx/1.x.y отдавался без версии (Server: nginx).
Расскажите, кто пользовался HAProxy и nginx в качестве балансировщика, какие преимущества HAProxy имеет перед nginx?
Если я не ошибаюсь, то Nginx в бесплатной версии не умеет делать активную балансировку, т.е. если реплика завалилась, то пользователь это увидит с определенной вероятностью.
Читаю документацию по бесплатной версии:
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 не прошел, трафик перестает идти на эту ноду.
Вот как раз в вашей цитате написано: «passive» health checks. То есть, запрос от пользователя пойдет на упавшую ноду, провисит там до таймаута, и потом nginx может переслать его на здоровую ноду. Таким образом, пользователь будет ждать всё это время таймаута. (После этого да, nginx может пометить ноду как упавшую).
В то время как varnish и haproxy умеют делать active health checks — они сами посылают раз в какое-то время запросы на ноды, чтобы проверить их.
На нагруженном проекте, это не важно, т.к. запрос от пользователя придёт с большой долей вероятности раньше чем отработает active check…
В целом согласен, хотел написать тоже самое. А для ненагруженных вряд ли кто использует балансировщики.
Ну разве что ситуация, когда нужно не распределение нагрузки, а резервирование, в этом случае активная проверка имеет право на существование.
Что вспомнилось из практики:
— 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, а уж потом игры с заголовками, куками и т.д.
Про TCP и Kerberos/NTLM понял, спасибо.
Но ведь nginx умеет (и умел) ssl offloading, а http заголовки и cookies (в том числе через lua) хорошо должны быть доступны?
Я не имел ввиду, что nginx не умеет ssl offoading или ковыряние в заголовках, я обратил внимание на то, что ssl offloading в моих юзкейсах критичен, а kerberos/rpc over http при tcp балансировке можно получить и на nginx.
Проксирование виндовых серверов с NTLM смог осилить только на haproxy. Может, конечно, руки кривые, но этот продукт показался мне очень дружелюбным и очевидным в настройке.
До haproxy извращался с arr в IIS (писал на хабр об этом)
Иногда мозг в режиме перевода начинает переводить всё подряд. Исправил.
Эра незашифрованного веба проходит, и это хорошо

А что хорошего-то?
UFO just landed and posted this here
Провайдеры перестанут внутрь веб-страниц свои левые скрипты вставлять, баннеры, собственные панели и прочую муть. На мой взгляд — уже весомый плюс, можно и согласиться на некоторый оверхед ресурсов.
UFO just landed and posted this here
UFO just landed and posted this here
Билайн и бесплатное WiFi в метро, например.
Sign up to leave a comment.

Articles