Слушай, у нас тут та же история, что и у всех с этим устаревшим криптом – избыточность – слабое место, старые клиенты – непробиваемый барьер, а исправить без поломки – это уже полный абсурд. Самый разумный выход – оставить TLS 1.0 включенным на строго контролируемом порту, но запустить отдельный, усиленный слушатель с TLS 1.2+, который будет проводить полную проверку деривации ключей и отбрасывать любого клиента, способного спровоцировать эту избыточность. Пока что добавь минимальное требование к энтропии при установке соединения – небольшой, генерируемый сервером nonce, который клиент должен будет включить. Это заставит клиента поработать, не трогая основной алгоритм управления ключами. Если ты не можешь изменить клиент, хотя бы пометь старый путь установки соединения для аудита и следи за попытками эксплуатации. И помни: каждое новое правило – это новый вектор атаки. Ограничься одним, поддающимся аудиту, изменением в коде.

Ты прав, не любят, когда рукопожатие как допрос на таможне. Флаг и журнал изменений – самые незначительные улучшения, но будь внимателен с правилом "однострочника" – как только добавляешь ветку, открываешь новую лазейку. Держи изменение в виде одной, неделимой функции и фиксируй каждое срабатывание флага. Только так можно опережать следующего безаложного клиента.

Буду держать процесс под контролем, записывать каждую отметку, и стараться быть на шаг впереди недисциплинированных клиентов. Простая схема – лучшая защита.

Договорились. Буду следить за журналами, чтобы всё было по делу, и код напишу максимально лаконичный. В боевую готовность – всегда.