Как стать автором
Обновить

Комментарии 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. И уж точно не существует общепринятого способа для клиента и сервера обменяться знаниями об их процессорах и выбрать шифронабор исходя из этих соображений.

Строго говоря, сферическому в вакууме пользователю это не нужно; у сервера есть администратор, а у клиента разработчик.

Так-то иногда достаточно правки строки доступных шифронаборов, чтобы не создавать ненужную нагрузку.

Ну да, и сервер согласует шифронабор в соответствии со своими представлениями о прекрасном, вернее с админскими. Если тот вообще заморочится задать приоритет. Я вот видел массу серверов, у которых _CBC_ шифронаборы приоритетнее _GСM_ и клиенты без юзерских настроек получат именно их.

Вы много знаете пользователей, заморачивающихся этой правкой знающих, что такое вообще возможно? И если для клиентов, полагающихся на SChannel можно задать именно приоритет, то, скажем, для Firefox можно только отключить лишние шифронаборы, но не задать их порядок :(

По-моему, всё несколько сложнее (или проще?).

Во-первых, представления о прекрасном это не плохо – если они реально есть, конечно. Конкретно свой кейс в рамках файлообменной сети я описал выше. Но извините, он и родился потому, что некто Дэлион полез в исходники популярных DC клиентов и обнаружил, что там не то что с приоритезацией, но и с доступными шифрами не всё гладко.

Во-вторых, ну вот сейчас я копнул, как это делается в Firefox, и, внезапно, оказывается, чтобы отключить шифронаборы конкретно для всё того же TLS 1.3, их нужно сначала задать. Кстати, задал, спасибо за идею)

То есть фактически мы приходим к тому, что вышеупомянутой версии TLS под капот если и лезть, то именно что с представлениями о прекрасном.

Вот мы и приходим к тому, что:
клиент имеет возможность выразить свои предпочтения

скажем так, смелое утверждение.

Ну... Предпочтения моего браузера сервер вполне себе учёл.

А вот то, что я задал их самостоятельно – это, конечно, несколько другая история.

Что значит учел? Вы оставили единственный включенный шифронабор, и сервер согласился работать с ним, т.к. тоже поддерживает его среди прочих? ;)
Кстати, какая чудная история у Хабра с HSTS… про список поддерживаемых шифронаборов для TLS 1.2 вообще молчу…

Да буквально. Вон у Ютуба о прекрасном всё же своё представление.

И тут должна сработать вся сила дефолтов. Библиотеки должны на типичном железе сами выбирать разумные наборы шифронаборов.

Для всего непонятного железа есть CHACHA20. Разработчики стандартов уже подумали об этом.

Библиотеки ничего подобного не должны, библиотеки — это инструкции, как работать с тем или иным шифронабором, а вот какой шифронабор выбрать — это уже логика, реализуемая в клиенте или сервере. У веб-сервера она более гибкая, но даже они не умеют в определение железа клиента и подбор шифронаборов под его аппаратную часть.

Сейчас TLS есть просто везде. Заставлять всех разработчиков выбирать шифронабор не приведет ни к чему хорошему. Вписать что угодно что заработает это ожидаемое поведение типичного разработчика.

Тут помогут только дефолты библиотек. Не надо лучшие. Надо приемлимые выбрать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории