Comments 11
> после инсталляции nginx нет ни init.d скрипта, ни конфига для systemd. Лечится так
Проще было бы скопировать nginx.service в /backup до удаления пакета, имхо.
Кроме того, а почему на openssl-1.1.1 не сделать checkinstall? А то в nginx делаете, а выше — нет.
Проще было бы скопировать nginx.service в /backup до удаления пакета, имхо.
Кроме того, а почему на openssl-1.1.1 не сделать checkinstall? А то в nginx делаете, а выше — нет.
Спасибо за комментарий! Полностью согласен, не делал checkinstall для openssl, так как это только тестовая среда, и вероятность того, что переустанавливать nginx придётся намного выше, чем openssl. По сути, пока подбирал рабочую конфигурацию, openssl ни разу не сносил, в то время, как nginx — раза 3 или 4. На продакшене, конечно, надо делать checkinstall на все пакеты.
На продакшене, конечно, надо делать checkinstall на все пакеты.
Не учите плохому. Checkinstall как раз нормальный вариант собрать по быстрому сам бинарь в пакет, чтоб можно было снести по быстрому.
Если уж у вас Debian делайте debian-way: dh_make, dpkg-buildpackage. Тем более, что nginx дает все для сборки под debian
А какой смысл в TLS 1.3 кроме исследовательского?
Как я понимаю, когда он «выйдет с беты» — многие приложения включат его по умолчанию и в вашей инструкции отпадет необходимость.
Just for fun, или это может реально предоставить какую-то дополнительную безопасность?
Как я понимаю, когда он «выйдет с беты» — многие приложения включат его по умолчанию и в вашей инструкции отпадет необходимость.
Just for fun, или это может реально предоставить какую-то дополнительную безопасность?
В моём случае — действительно, увидеть, что «работает». Однако, полагаю, что для многих будет полезно включить новый протокол в целях, к примеру, разработки, подготовиться к тому, чтобы обновить свои приложения заблаговременно, протестировать их работу. Ощутить, так сказать, на себе все эти преимущества .
Какой смысл в пункте 5 устанавливать пакеты отдельными командами apt-get install?
Вот есть заметка как скомпилировать rpm nginx mainline (1.13) с openssl 1.1.1 с поддержкой TLSv1.3
gist.github.com/StarDuster/0d6fb37132fe64c0e7f60631e02b0f0d
Правда там RPM, а у вас DEB.
gist.github.com/StarDuster/0d6fb37132fe64c0e7f60631e02b0f0d
Правда там RPM, а у вас DEB.
cd openssl-tls1.3-draft-18
./config
make && make install1. Не делайте так ни на dev ни на prod среде если у вас пакетный дистрибутив debian. Получите гору мусора в системе, про которую потом забудите и в последствии это приведет к массе проблем.
2. В случае nginx в этом нет необходимости, openssl линкуется статически к nginx и он не зависит от системной версии openssl.
Уже точно не помню, но точно больше часа ушло на то, чтобы найти источник, где упоминалось про шифры, и что в TLS 1.3 они должны быть такими:
На самом деле их больше:
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
TLS13-AES-128-CCM-8-SHA256
TLS13-AES-128-CCM-SHA256
Посмотреть можно так:
# ./openssl-1.1.1-tls1.3-draft-18/.openssl/bin/openssl ciphers -v 'ALL:!ADH:@STRENGTH' | grep TLS13
TLS13-AES-256-GCM-SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS13-CHACHA20-POLY1305-SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS13-AES-128-GCM-SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
TLS13-AES-128-CCM-8-SHA256 TLSv1.3 Kx=any Au=any Enc=AESCCM8(128) Mac=AEAD
TLS13-AES-128-CCM-SHA256 TLSv1.3 Kx=any Au=any Enc=AESCCM(128) Mac=AEAD
cd nginx-1.13.7
./configure --with-cc-opt='-g -....
Правильнее было бы сделать apt-get source nginx подправить debian/rules и собрать nginx через dpkg-buildpackage и в итоге получить DEB пакет и ни мучиться, если интересно, то почитайте в моей статье про пересборку Nginx c поддержкой ALPN.
Sign up to leave a comment.
Включаем поддержку TLS v1.3 в Nginx на примере Debian 9