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

Ну, прежде всего – это развитие прошлой заметки на тему соответствия XMPP-сервера стандартам.

На момент теста TLS-подключения было несколько слабых моментов:

• Протоколы: были разрешены TLS 1.0 и TLS 1.1. В конфиге ejabberd.yml наконец-то раскомментировал в ‘TLS_OPTIONS’ параметры  no_tlsv1 и no_tlsv1_1, в итоге в тестере остался TLS 1.2 и этот тест стал проходить на 100%. Тут немного спорный момент – потенциально может теряться связь с какими-то серверами – поэтому опции и были закомментированы. С другой стороны – какого черта? TLS 1.2 появился еще в 2008 году – думаю, за 15 лет его должно поддерживать ВСЁ. Более старые версии признаны устаревшими еще 3 года назад. Так что пора.
• TLS 1.3 тот тест не показывает. Другой (см. ниже) тоже не детектит эту версию. С другой стороны – тут пишут про проблемы с некоторыми клиентами и использование опции no_tlsv1_3 для исправления этого – т.е., ejabberd это таки умеет.
• Ключи. У меня светились желтым “Certificats: RSA 2048 bits” – да, я давно планировал обновить ключи до 4 Кбит, но как-то руки не дошли. Исправляем: sed -i '/renewalparams/s/$/\nrsa_key_size = 4096/g' /etc/letsencrypt/renewal/*.conf – при следующем обновлении сертификата получим уже корректный вариант. Можно тем или иным способом форсировать обновление при необходимости.
• Вот с ECC 256 bit вышла загвоздка и я до сих пор не знаю, каким образом это решается. Что найдено по теме:
  • У certbot есть параметр –elliptic-curve, дефолтно он в значении secp256r1. Пытался вписать в секцию обновлений elliptic-curve = secp384r1, но именно эта строчка съедается. Честно говоря, пока не знаю, в ту ли сторону я копаю и вообще надо ли трогать эти эллиптические кривые.
  • Ссылка 1
  • Ссылка 2
  • Вот тут интересное обсуждение было. Особенно насчет defaults в 256 bit. Толком не ясно, чем в итоге все закончилось, но было это 6 лет назад. Возможно, так все и оставили? На Prosody у участника моей конференции светится 384 бита.
• В Good practices у меня светится зеленым бирка “REQUIRED” – да, я был одним из тех, кто в свое время голосовал за принудительное шифрование, так что и на своем сервере, естественно, тоже включил такое.

В итоге рейтинг сервера поднялся до 96%, однако grade остался почему-то “M”. На других серверах с таким же или более низким рейтингом вижу B, а то и А.

Еще что было найдено полезного:

• https://extralan.ru/?p=2901 – включение TLS 1 и 1.1 обратно в случае, если они не включаются для каких-то старых версий Psi.
• С того же блога ссылка на скрипт для тестирования TLS.
• Между делом перегенерировал файл с параметрами DH под больший размер: openssl dhparam -out dhparams.pem 4096 – его положил в /etc/ejabberd/dhparams.pem
• В блоге process one нашел полезную статью по улучшению безопасности сервера. Тут несколько моментов:
  • dhparams.pem изначально был сгенерирован под 2048, а я переделал под 4096.
  • В ‘TLS_CIPHERS’ у меня “HIGH:!aNULL:!eNULL:!3DES:@STRENGTH” – в свою очередь, в статье дается вполне конкретный список алгоритмов. Но актуален ли он на сейчас, с учетом того, что пост 2016 года? При случае можно будет сравнить макросы HIGH и все остальное – пример команд есть по ссылке – с приведенным списком. Возможно, в каком-то случае будет лучше оставить макрос, так как он будет обновляться с обновлением openssl, отсекая слабые шифры. В случае с жестко заданным списком этого может не происходить.
  • Местами встречаю, что отдельный порт с TLS’ом не труЪ и надо использовать STARTTLS.  С другой стороны, у Compliance tester’а это один из пунктиков на соответствие современному серверу.
  • tls_compression стоит в false. Не знаю пока, плохо ли это или хорошо. У меня стоит в true, при этом в параметрах TLS’а – no_compression. Надо изучить подробнее.
• Статья на хабре.

Пока все.