TLS 1.3 теперь не новое поколение, а значение по умолчанию
Чтобы протокол стал операционной базовой линией, требуются годы. IETF опубликовал TLS 1.3 в RFC 8446 в 2018 году. С того дня протокол распространился в браузерах, закрепился в библиотеках, вошёл в аудиторские фреймворки. К 2026 году пройден порог: поддерживать более старые протоколы теперь дороже, чем отказаться от них.
Клиенты, которым нужен TLS 1.2, либо обновились, либо стали нерелевантны, либо сузились до популяции, которая не оправдывает стоимость непрерывного обслуживания. Клиенты, требующие TLS 1.3 — по соображениям соответствия, производительности или модернизации, — всё чаще читают фразу «всё ещё поддерживает TLS 1.2 по умолчанию» как красный флаг при покупке.
Этот тренд не нов. Браузеры вывели TLS 1.0 и 1.1 из эксплуатации в 2020 году. PCI-DSS 4.0 (вступил в силу в 2024-2025 годах) требует «надёжной криптографии», которую совет трактует как TLS 1.2 или выше; перспективное ожидание явно — TLS 1.3. FIPS 140-3 всё чаще предполагает TLS 1.3 как базовую линию. Что изменилось в 2026 году — это достаточное истончение длинного хвоста клиентов TLS 1.2: решение «просто отключить 1.2» теперь операционно осуществимо для большинства корпоративных развёртываний, а не только теоретически.
Эта статья охватывает три вещи: во сколько на самом деле обходится вам поддержка TLS 1.2 в 2026 году, аргументы по соответствию и производительности в пользу только TLS 1.3 и как аппаратное ускорение SSL меняет математику миграции. Написано не для криптографов, а для команд, принимающих операционное решение; детали протокола изложены кратко, не исчерпывающе.
Реальная стоимость поддержки TLS 1.2 для вас в 2026 году
Издержки поддержки TLS 1.2 наряду с TLS 1.3 по отдельности не катастрофичны; но в масштабе они накапливаются, и ни одна из них не приходит только со старым. По отдельности ни одна не выглядит крупной — но когда все они присутствуют одновременно, поддержка старого протокола становится дороже отказа от неё.
Более медленные handshake
TLS 1.2 требует двух круговых обменов для свежего handshake; TLS 1.3 — одного. Для клиентов с высокой задержкой — мобильных, международных — разница ощутима: 100-300 мс экономии на свежее подключение. Умноженное на миллионы соединений, влияние на пользовательский опыт и конверсию становится измеримым.
Более широкая поверхность cipher suite
Поддержка TLS 1.2 означает принятие более широкого списка cipher — включая старые конструкции с известными уязвимостями или слабыми свойствами forward secrecy. Даже при тщательной конфигурации поверхность атаки больше; риск дрейфа конфигурации выше.
Старый код на критическом пути
Каждая библиотека TLS на пути соединения содержит реализацию TLS 1.2. Этот код редко находится в фокусе нового исследования безопасности; но исторически был источником уязвимостей (BEAST, Lucky13, ROBOT). Удаление 1.2 убирает и эту поверхность критического пути.
Несогласованность forward secrecy
TLS 1.3 делает forward secrecy обязательным — у каждой сессии есть эфемерные ключи. TLS 1.2 оставляет его опциональным и зависимым от выбора cipher. Смешанные развёртывания означают, что одни сессии forward-защищены, а другие нет — это усложняет оценку риска для долгосрочной конфиденциальности.
Аудиторское давление
В 2025-2026 годах аудиты PCI-DSS 4.0 всё чаще ссылаются на TLS 1.3 как на best practice, даже если 1.2 технически соответствует. FIPS 140-3 предполагает 1.3. Отчёты SOC 2 отмечают смесь версий как контрольную проблему. Давление соответствия однонаправленно и нарастает.
Операционная сложность
Два семейства протоколов означают две политики cipher suite, два пути кода отладки, два представления мониторинга и два режима отказа. Каждое дополнительное измерение умножает операционные издержки. Отказ от 1.2 упрощает это измерение.
TLS 1.3 в цифрах (с аппаратным ускорением)
TLS 1.3 — против 2 RTT для TLS 1.2. Выигрыш на каждом свежем подключении.
IETF RFC 8446Для повторных подключений данные приложения можно отправить в первом пакете; задержки handshake нет.
IETF RFC 8446Степень снижения у аппаратного ускорения TR7 по сравнению с программной базовой линией; стоимость CPU на handshake обрушивается.
TR7 SSL AccelerationУ каждой сессии TLS 1.3 есть эфемерные ключи; ретроспективная расшифровка долгосрочных секретов становится невозможной.
IETF RFC 8446Картина соответствия: давление однонаправленно
Шесть разных фреймворков указывают на TLS 1.3, пусть и разными словами, в одном направлении. Ни один не говорит «вернитесь к 1.2»; все указывают на 1.3 либо прямо, либо косвенно. Общее послание: TLS 1.3 становится не best practice, а значением по умолчанию.
PCI-DSS 4.0
Вступил в силу в марте 2024 года, полный переход завершён в марте 2025 года. Требует «надёжной криптографии» для данных держателей карт; TLS 1.0/1.1 явно запрещены, TLS 1.2 приемлем, а на перспективу ожидается TLS 1.3. В течение 2025-2026 годов аудиторская обратная связь всё чаще представляет 1.3 как best practice.
FIPS 140-3
Стандарт валидации криптографических модулей. Лаборатории валидации в 2025-2026 годах предполагают TLS 1.3 как контекст развёртывания. Модули, валидированные только для TLS 1.2, в регулируемых отраслях всё труднее позиционировать для новых закупок.
SOC 2 и ISO 27001
Оба ожидают «отраслевую стандартную криптографию». Комментарий аудиторов в 2026 году рассматривает развёртывание TLS 1.3 как доказательство актуальной практики; развёртывание только TLS 1.2, даже технически соответствующее, всё чаще притягивает аудиторские замечания.
DORA (финансовая устойчивость ЕС)
Вводит требования операционной устойчивости для финансовых организаций ЕС. Криптографическая гибкость — способность быстро обновлять протоколы — является частью картины операционного риска. Развёртывание TLS 1.3 — положительный сигнал; привязка к TLS 1.2 — отрицательный.
CNSA 2.0 / путь к PQC
Криптографический пакет национальной безопасности США движется к PQC к 2030 году. Он предполагает TLS 1.3 как базовый протокол под миграцией PQC — гибридный обмен ключами ML-KEM определён для TLS 1.3, а не для 1.2. Пропуск TLS 1.3 оставляет более трудную миграцию PQC потом.
Требования браузеров
Chrome, Firefox, Safari, Edge — все поддерживают TLS 1.3 по умолчанию и имеют графики вывода TLS 1.2 из эксплуатации. Индикаторы понижения соединения в DevTools браузеров всё чаще помечают TLS 1.2 в тестах, обращённых к пользователю.
Как мигрировать, ничего важного не сломав?
Проведите инвентаризацию трафика TLS 1.2
Включите на вашем ADC логирование версии TLS для каждого соединения. Агрегируйте по user-agent, диапазону исходных IP и эндпоинту. Результат: популяция клиентов, которая потеряет доступ, если вы отключите TLS 1.2. Большинство организаций находят популяцию меньше, чем опасались.
Классифицируйте популяцию TLS 1.2
Сгруппируйте инвентарь по категориям: браузеры, обращённые к клиентам (в 2026 году должно быть близко к нулю), партнёрские API-интеграции, внутренние сервисы, встроенные устройства. У каждой категории свой путь устранения.
Задайте политику для каждого эндпоинта
Только TLS 1.3 — это не всё или ничего. Настраивайте для каждого эндпоинта: публичные клиентские эндпоинты получают только TLS 1.3; внутренние сервисы с документированной потребностью в 1.2 временно сохраняют его; партнёрские интеграции получают путь вывода из эксплуатации с документированным сроком.
Свяжитесь с партнёрами
Для B2B-интеграций, требующих TLS 1.2, отправьте партнёру документированный план вывода из эксплуатации с реальным сроком. Большинство партнёров обновятся быстрее, чем «крах TLS 1.2», если их попросить; многие, возможно, ждут принуждающей функции.
Сделайте TLS 1.3 значением по умолчанию
Для новых эндпоинтов переключите значение по умолчанию на только TLS 1.3. Существующие эндпоинты с документированными потребностями в 1.2 получают переопределение; всё прочее по умолчанию идёт на современную базовую линию. Это останавливает накопление нового технического долга.
Раз уж вы здесь, спланируйте и PQC
Если вы и так трогаете конфигурацию TLS, включите гибридный обмен ключами ML-KEM в TLS 1.3. Изменение консервативно (гибридный режим откатывается к классической безопасности) и начинает защищать трафик от «собери сейчас, расшифруй потом». Миграции PQC и TLS 1.3 — это один проект; выполняются в одном и том же переходе конфигурации.
Где здесь аппаратное ускорение SSL?
Преимущества производительности TLS 1.3 наиболее заметны, когда криптографические операции не являются узким местом. При высоком объёме программный TLS оказывает заметное давление на ядра общего назначения; на пике одни только handshake TLS могут потреблять 20-30 процентов доступного CPU на загруженных балансировщиках нагрузки. Аппаратное ускорение SSL выгружает эти операции на специализированные крипто-блоки и драматически снижает стоимость CPU на соединение.
Аппаратное ускорение SSL от TR7 снижает нагрузку обработки SSL примерно на 95 процентов по сравнению с программной. Практический эффект: то же оборудование обрабатывает гораздо больше одновременных сессий TLS, задержка становится более стабильной (специализированное оборудование не конкурирует за CPU), а стоимость на handshake падает ниже порога, где выбор протокола TLS оказывает измеримое влияние на приложение.
Для пути PQC аппаратное ускорение ML-KEM и AEAD-cipher — это путь к высокообъёмному развёртыванию PQC. Размер handshake растёт (ML-KEM — около 1,1 КБ против около 100 байт для X25519); но стоимость CPU на операцию может конкурировать с RSA-2048. Оборудование, включающее примитивы PQC, удерживает стоимость на handshake стабильной по мере продвижения миграции. Дорожная карта TR7 выравнивает аппаратное ускорение с графиком миграции PQC; для миграции не нужно менять оборудование.
Главная мысль в этой точке возвращается ещё раз: миграция на TLS 1.3 и миграция на PQC к 2030 году — это один и тот же путь конфигурации. Аппаратное ускорение — это компонент, делающий стоимость обоих операционно невидимой.
Ссылки и источники
Спецификация протокола, включающая дизайн 1-RTT handshake, данные 0-RTT, обязательный forward secrecy и удалённые старые cipher suite. https://datatracker.ietf.org/doc/html/rfc8446
Действующая версия Payment Card Industry Data Security Standard. Полный переход завершён в марте 2025 года. https://www.pcisecuritystandards.org/document_library/
Федеральный стандарт обработки информации для валидации криптографических модулей. https://csrc.nist.gov/projects/cryptographic-module-validation-program
Regulation (EU) 2022/2554, вводящий требования операционной устойчивости для финансовых организаций, включая криптографическую гибкость. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Commercial National Security Algorithm Suite 2.0 — TLS 1.3 как протокол по умолчанию под графиком миграции PQC. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
Современный TLS, современное оборудование
Аппаратно-ускоренная обработка SSL от TR7 несёт TLS 1.3 с 0-RTT, гибридным обменом ключами ML-KEM и разгрузкой CPU примерно на 95 процентов по сравнению с программной. Миграция на TLS 1.3 и история PQC к 2030 году — это один и тот же путь конфигурации.
Изучить ускорение SSL от TR7