Comments 38
Аналогично для nginx решается через:
для HTTP, и
для HTTPS
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 логичнее и читабельнее.
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.
Реально эти тесты косвенно показывают:
К сожалению, очень многие не парятся и в тестах их 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 мире, а уж тем более тот кто занимается серверами.
Просто это не единственный фактор, это часть паттерна, некий звоночек.
Здесь главное не впадать в крайности. Это можно применять к tech-компаниям с 10+ человек в команде, где уже какие-то тех. процессы устоялись и обычно кто-то занимается серверами. Конечно, бесмысленно говорить об очень маленьких компаниях вроде «2 человека и собака» и конечно есть исключения из правил.
Приведу пример:
Западный стартап, с помощью которого можно заказать чартер/частный самолет. $6к+ средняя транзакция. Полный букет брешей в SSL тесте — первый плохой знак.
Смотрим глубже — PHP 5.3 светится в хедерах. Дальше — domain.com/blog/readme.html — старая дырявая версия Wordpress.
Можно ли уже сказать что-то о технической части проекта? Спрашиваем овнера: «Что происходит?». Оказывается работают индусы за копейки :)
Не обязательно содержать инфобезника, должен быть баланс, когда программист хоть немного интересуется что происходит нового в IT мире, а уж тем более тот кто занимается серверами.
Просто это не единственный фактор, это часть паттерна, некий звоночек.
[ sarcasm on ]
Обоже, Яндекс и Google нанимают слабых айтишников!
[ sarcasm off ]
Обоже, Яндекс и Google нанимают слабых айтишников!
[ sarcasm off ]
Проблема достаточно большая.
Интерактивная инфографика со средней температурой по интернету для топ 1М сайтов:
www.trustworthyinternet.org/ssl-pulse
Интерактивная инфографика со средней температурой по интернету для топ 1М сайтов:
www.trustworthyinternet.org/ssl-pulse
У четверти сайтов - мусорный F рейтинг
Те четверть сайтов такие
Ещё можно добавить server_tokens off; в http/server, чтобы заголовок
Server: nginx/1.x.y
отдавался без версии (Server: nginx
).Расскажите, кто пользовался HAProxy и nginx в качестве балансировщика, какие преимущества HAProxy имеет перед nginx?
Если я не ошибаюсь, то Nginx в бесплатной версии не умеет делать активную балансировку, т.е. если реплика завалилась, то пользователь это увидит с определенной вероятностью.
Читаю документацию по бесплатной версии:
То есть если health check не прошел, трафик перестает идти на эту ноду.
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 — они сами посылают раз в какое-то время запросы на ноды, чтобы проверить их.
В то время как varnish и haproxy умеют делать active health checks — они сами посылают раз в какое-то время запросы на ноды, чтобы проверить их.
Да, точно. Ключ в 'in-band (or passive)'. Спасибо!
Есть github.com/yaoweibin/nginx_upstream_check_module, wiki.nginx.org/HttpHealthcheckModule и еще пара модулей которые должны реализовать активные проверки, никто не использует, случайно?
Есть github.com/yaoweibin/nginx_upstream_check_module, wiki.nginx.org/HttpHealthcheckModule и еще пара модулей которые должны реализовать активные проверки, никто не использует, случайно?
На нагруженном проекте, это не важно, т.к. запрос от пользователя придёт с большой долей вероятности раньше чем отработает active check…
И не только. Если один бэкэнд провалил запрос — его можно попытаться всё-таки выполнить на другом: nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
Это, конечно, не полноценный health check, но уже что-то.
Это, конечно, не полноценный health 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, а уж потом игры с заголовками, куками и т.д.
— 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 offloading, а http заголовки и cookies (в том числе через lua) хорошо должны быть доступны?
Проксирование виндовых серверов с NTLM смог осилить только на haproxy. Может, конечно, руки кривые, но этот продукт показался мне очень дружелюбным и очевидным в настройке.
До haproxy извращался с arr в IIS (писал на хабр об этом)
До haproxy извращался с arr в IIS (писал на хабр об этом)
Вдруг кому пригодится: Load Balancing Microsoft Exchange with NGINX Plus. Оно в значительной степени верно и для бесплатной версии.
RPC over HTTP прекрасно работает начиная с 1.7.11.
RPC over HTTP прекрасно работает начиная с 1.7.11.
добавление ещё одного приложения в стопку
слово «стек» можно было и не переводить
Эра незашифрованного веба проходит, и это хорошо
А что хорошего-то?
UFO just landed and posted this here
Провайдеры перестанут внутрь веб-страниц свои левые скрипты вставлять, баннеры, собственные панели и прочую муть. На мой взгляд — уже весомый плюс, можно и согласиться на некоторый оверхед ресурсов.
Sign up to leave a comment.
Как перевести сайт целиком на постоянный HTTPS для всех