Комментарии 14
Для личного интранета, где сервера на nginx, достаточно сложно, если вообще возможно, выбрать шифры TLS 1.3. Но я просто включаю только TLS 1.3, а выбор шифров оставляю на предпочтениях клиентского устройства - ему лучше известно, есть аппаратная поддержка или нет.
Кстати, в жизни не видел вариантов использования CCM шифров, хотя бы узнал о них из статьи. :)
Аналогично и у нас в DC весь сыр бор начался из-за того, что ни один клиент не умел определять наличие аппаратной поддержки AES, а в списках шифров стояло неизвестно что.
По итогу у себя на сервере я оставил только AES-128 и ChaCha-Poly (AES-256 избыточен), а дальше клиент сам определится.
Кстати, в жизни не видел вариантов использования CCM шифров, хотя бы узнал о них из статьи. :)
ЕМНИП Safari одно время поддерживал CCM, а вот CCM_8 вроде как так и остался «теоретической возможностью», тем более он считается ненадежным.
Как было показано, хотя при использовании TLS 1.3 за сервером всегда будет последнее слово в выборе конкретного алгоритма, клиент имеет возможность выразить свои предпочтения. Он должен реализовать эту возможность, чтобы указать на ожидаемый уровень безопасности и производительности, дабы сервер мог произвести информированный выбор.
Если мы под клиентом подразумеваем браузер, то в большинстве случаев пользователь не имеет возможности выразить свои предпочтения по порядку предпочтения шифронаборов by design. И уж точно не существует общепринятого способа для клиента и сервера обменяться знаниями об их процессорах и выбрать шифронабор исходя из этих соображений.
Строго говоря, сферическому в вакууме пользователю это не нужно; у сервера есть администратор, а у клиента разработчик.
Так-то иногда достаточно правки строки доступных шифронаборов, чтобы не создавать ненужную нагрузку.
Вы много знаете пользователей,
По-моему, всё несколько сложнее (или проще?).
Во-первых, представления о прекрасном это не плохо – если они реально есть, конечно. Конкретно свой кейс в рамках файлообменной сети я описал выше. Но извините, он и родился потому, что некто Дэлион полез в исходники популярных DC клиентов и обнаружил, что там не то что с приоритезацией, но и с доступными шифрами не всё гладко.
Во-вторых, ну вот сейчас я копнул, как это делается в Firefox, и, внезапно, оказывается, чтобы отключить шифронаборы конкретно для всё того же TLS 1.3, их нужно сначала задать. Кстати, задал, спасибо за идею)
То есть фактически мы приходим к тому, что вышеупомянутой версии TLS под капот если и лезть, то именно что с представлениями о прекрасном.
клиент имеет возможность выразить свои предпочтения
скажем так, смелое утверждение.
Ну... Предпочтения моего браузера сервер вполне себе учёл.
![](https://habrastorage.org/getpro/habr/upload_files/ecf/4d2/105/ecf4d2105bbdfaa20749f4d2bd1651f3.png)
А вот то, что я задал их самостоятельно – это, конечно, несколько другая история.
Кстати, какая чудная история у Хабра с HSTS… про список поддерживаемых шифронаборов для TLS 1.2 вообще молчу…
И тут должна сработать вся сила дефолтов. Библиотеки должны на типичном железе сами выбирать разумные наборы шифронаборов.
Для всего непонятного железа есть CHACHA20. Разработчики стандартов уже подумали об этом.
Заметки по выбору шифров для TLS 1.3