Сформирован выпуск основной ветки nginx 1.19.4, в рамках которой продолжается развитие новых возможностей (в параллельно поддерживаемой стабильной ветке 1.18 вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53976
а чё это они с такой частотой релизов - и до сих пор на свободе?
https://www.opennet.dev/openforum/vsluhforumID3/122243.html#9
Доколе? У nginx есть хоть LTS? Что за темп нововведений?
У nginx есть stable и mainline.
Stable это 1.x.y, где x — четное число. Новый stable с добавлением фич выпускается один раз в год в апреле, между выпусками выходят только багфиксы. Mainline 1.n.m, где n — нечетное число, в этой ветке ведется разработка и добавление новых фич, из нее создается в апреле новый stable.Но крупные игроки, типа CF и Yandex рекомендуют использовать mainline, как не странно.
> Доколе? У nginx есть хоть LTS?конечно есть - nginx+ называетсо. Всего лишь полторы тыщи долларов в год за одноядерную конфигурацию - вот тебе LTS! И mod-status работает, а не бесполезный огрызок, поди плохо за эти мелкие деньги?
> Что за темп нововведений?Дежурный, строго по графику. Появилась строчка для комит-лога - выпускаем новую версию. Иначе инвесторы не поймут-с.
Нахрена нужен лтс, когда можно новые фичи сразу иметь в проде? Просто чтобы иметь их позже? Или вы в тестирование и мониторинг не умеете из-за чего ссыте их катить и думаете если вы на годит их себя лишите у вас ничего никогда не сломается?
Service Discovery так и не завезли?
Почему по умолчанию отключён ssl_reject_handshake on?
Включать по дефолту фичу которая только появилась? А ты — оригинал, блин
> ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;Два года ждал... Правда в первую неделю ожидания научился это делать глобально в /etc/ssl/openssl.cnf, как они же и предлагали в issue, и уже не особо и нужно.
> ssl_reject_handshake on;
> ... отвергать все попытки согласования SSL-соединений ...Это как? Специально отвергать все рукопожатия чтобы никто не смог вообще зайти по https? Если да то зачем, если нет обяъсните, пожалуйста, эту опцию подробнее.
> В почтовый прокси...
Объясните, пожалуйста, это nginx может как sqiud или 3proxy выступать smtp-прокси-сервером? Для чего именно это нужно?
> Это как? Специально отвергать все рукопожатия чтобы никто не смог вообще зайти по https?Additionally, the ssl_reject_handshake directive makes configuring certificates for the default server block optional. If no certificates are configured in the default server for a given listening socket, certificates must be defined in all non-default server blocks with the listening socket in question.
Это вот так. По ссылке есть все, пройди туда.
> Объясните, пожалуйста, это nginx может как sqiud или 3proxy выступать smtp-прокси-сервером?
Всегда мог, ну то есть в 0.7.x уже точно мог, может и раньше.
И smtp, и imap4, и pop3https://nginx.org/en/docs/mail/ngx_mail_core_module.html
тебе в помощь
>> Объясните, пожалуйста, это nginx может как sqiud или 3proxy выступать smtp-прокси-сервером?
> Всегда мог, ну то есть в 0.7.x уже точно мог, может и
> раньше.
> И smtp, и imap4, и pop3
> https://nginx.org/en/docs/mail/ngx_mail_core_module.html
> тебе в помощьМне всё равно не понятно зачем web-серверу проксировать postfix с dovecot.
Ну потому что изначально Игорь его создавал не только как веб-сервер. Игорь его писал будучи админом и писал для себя. Ну а теперь выбрасывать из него функциональность mail proxy глупо, люди же могут использовать
Я правильно понимаю что после установки 1.19.4 надо добавить в соотестветствующий listen:ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;
ssl_conf_command CipherString ECDHE-RSA-AES256-GCM-SHA384;над
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-AES256-GCM-SHA384';и Key Exchange и Cipher Strength в ssllabs достигнут 100 ?
Cipher Strength будет в 100, Key Exchange в 90
Но, да, это совсем дофига попугаев :)
Чтобы и Key Exchange 100 стало надо чачу отключить ?
Не исключаю :-D
Но, вообще, для LE вроде рекомендуют Use 4096-bit RSA or secp256 and higher ECC Certificate (This is a must if you want 100% on Key Exchange). Но я для теста попробовал, с 4096, все равно 90.
Что-то не заработало у меня :(В TLS 1.3 остались по-мимо нужного TLS_AES_256_GCM_SHA384 и ненужные мне TLS_AES_128_GCM_SHA256 и TLS_CHACHA20_POLY1305_SHA25
при
ssl_protocols TLSv1.2 TLSv1.3;
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384;
ssl_conf_command CipherString ECDHE-RSA-AES256-GCM-SHA384;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:ECDHE-RSA-AES256-GCM-SHA384';
Вот что у меня на тестовом на котором выходит 100-100-90-100 по ssl'у в конфиге nginx'а(даю все связанное, что бы ты мог посмотреть на свое и сравнить)ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_early_data on;ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;
ssl_conf_command CipherString ECDHE-RSA-AES256-GCM-SHA384;ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.1.1 valid=60s;А в /etc/letsencrypt/cli.ini у меня
rsa-key-size = 4096
было дописано перед тем как перевыпустить сегодня досрочно сертификаты.
P.S. Думаю про резолвер пояснять не нужно, если уж ты пытаешься разобраться :)
Я сам дурак - у меня вся статика с поддомена а там я конфиг не поменял !Сейчас всё в порядке
https://www.ssllabs.com/ssltest/analyze.html?d=www.babai.ru&...
Ну круто, теперь у нас с тобой попугаев столько, что можно открывать попугайскую птицефабрику :)
> ssl_reject_handshake on;
> ... отвергать все попытки согласования SSL-соединений ...Я правильно понял? Теперь вместо этого
server
{
listen 443 default_server http2 ssl;
ssl_certificate /etc/nginx/certs/example.com.crt;
ssl_certificate_key /etc/nginx/certs/example.com.key;
return 444;
}
можно просто написать вот этоserver
{
listen 443 http2 ssl;
ssl_reject_handshake on;
}
И он будет слать лесом тех, кто обращается к серверу по IP или не определённому в конфиге имени сервера?
При этом не нужно теперь указывать сертификаты, return 444 и директиву default_server? Я правильно понял?
Что-то похожее на это, посмотри все же по ссылке. Но я бы пока не стал включать это дело, подождал бы до 1.19.5 хотя бы, обычно такие новые фичи приходится править в следующих релизах
Благодарю, именно так!
If no certificates are configured in the default server for a given listening socket, certificates must be defined in all non-default server blocks with the listening socket in question.
Да не за что
Вообще меня директива заинтересовала, но я подожду 1.19.5 хотя бы и почитаю что будут писать в рассылке про возможные проблемы.
Ох уже мне эти выжидальщики. Прогнал тесты и запустил в прод, полёт нормальный.
Ну извини, если у тебя прод это твой сайт, то можно и пускать, а у меня прод это сайты клиентов и мне там косяки не нужны
У себя-то я само собой потестирую, но буду ждать следующего релиза и читать рассылку, что бы не самому все грабли собирать
У меня прод это мой бизнес за счёт которого я живу и кормлю семью. И конечно же я не буду терять преимущество отказываясь от новых фич, не буду тратить время чтобы сидеть читать какие-то сраные рассылки, а потом всё равно дрожать перед обновлением, потому что гарантий что твой кейс не пропустили нет никаких.А вы сразу скажите что у вас за контора, чтобы не дай бог вашим клиентом не стать. Во времена виртхостинга мне уже возвращали деньги и неустойку одни (всё ещё популярные, на букву v) уроды с некомпетентными работаетнетрогаями вместо админов и древней тухлятиной вместо софта, под который нужно специальным образом писать код чтобы не дай бог не заиспользовать фичу PHP, питона или nginx пятилетней давности которая там ещё не поддерживается.
Отказ от новых фич и внедрение в прод фичи которая только что вышла в mainline-ветке это разные вещи.Мы используем именно mainline для nginx, у нас свой репозиторий(из-за использования модулей которые не входят в официальный, например brotli), но включать новую фичу клиентам сразу после релиза я не буду, что бы не сломать им ничего. Я выжду месяц(примерно столько между релизами в mainline), почитаю рассылку, протестирую у себя на некритичных проектах, а потом уже внедрю
У тебя вышел какой-то френдли-файр, прямо скажем :)
> Да не за что
> Вообще меня директива заинтересовала, но я подожду 1.19.5 хотя бы и почитаю
> что будут писать в рассылке про возможные проблемы.Вы были правы!
Проверил сегодня эту опцию. По IP отрабатывает как и ожидалось, но вот только, бонусом, нафиг отрубается TLS 1.3 на всех хостах!https://trac.nginx.org/nginx/ticket/2071
Охренеть это ещё и по дизайну! Короче про эту опцию нужно просто забыть, и использовать return 444 как и раньше!
Ну я просто знаю что такие серьезные вещи всегда имеют какие-то подводные камни и нужно ждать, а не внедрять сразу
Зачастили как-то релизы nginx-а...
Как будто что-то плохое.
Apache наше все, долой клонов индейца!
ssl_reject_handshake это бомба, надо же было им столько времени потратить чтобы докумекать до неё. Теперь наконец можно нормально настроить ssl'ный default_server без костылей.
Будьте аккуратнее, эта опция ломает TLS1.3: