Кратко

  • В полном TLS-handshake False Start разрешал клиенту отправить данные под свежими ключами после своего Finished, пока Finished сервера шёл обратно.
  • Обычное рукопожатие сохранялось; ранний выпуск требовал opt-in приложения, узких криптографических списков, выбранного протокола и правил на случай позднего отказа.

Первый record обогнал последнее доказательство

В порядке RFC 5246 клиент обрабатывает сертификат и обмен ключами сервера, отправляет ChangeCipherSpec и Finished, затем ждёт соответствующие сообщения сервера. Только проверив чужой Finished, он считает handshake завершённым и передаёт прикладные данные.

False Start поместил первый record внутрь ожидания. Клиент уже получил свежие ключи и отправил своё доказательство. Шифрованный record шёл к серверу, а его финальное подтверждение — навстречу.

RFC 7918 называет успешный итог ретроактивной валидацией. Если Finished сервера верен, обычный handshake действителен; изменено только время. Сетевой обмен не исчез, его длительность использовали до результата.

Ключи были готовы, подтверждение — нет

Клиент уже видел ServerHello, suite, сертификат и параметры обмена. Record защищён новым Cipher Spec. Это не plaintext и не слепая отправка вместе с ClientHello.

Но Finished сервера ещё должен доказать общие секреты и transcript. Если он отсутствует или неверен, handshake никогда не валиден. Нормальный клиент удержал бы данные; False Start уже выпустил их.

Вопрос — какие сведения допустимо раскрыть до последнего результата аутентификации, а не только включено ли шифрование.

Поведение клиента, а не новая выдача разрешения

False Start не добавлял extension, которым сервер соглашался. RFC 7918 определял необязательное поведение клиента. Совместимый сервер терпел защищённые records до обычной точки обработки.

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

Функцию просило приложение. Только оно знало, является первый запрос безопасным чтением, credential или необратимой командой. Библиотека давала возможность, приложение определяло смысл.

Whitelist ограничивал ускорение

RFC 7918 ограничивает версию, симметричный cipher, key exchange, параметры и тип клиентского сертификата. Рекомендуемые DHE/ECDHE дают forward secrecy. Сомнительные комбинации исключаются.

Так downgrade не должен выпустить данные под слабой конфигурацией до провала последней проверки. Но whitelist становится lifecycle-политикой: update, fallback или новый default меняют круг ранней отправки. Расширение нельзя наследовать без ревью.

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

Прикладный язык выбирался до отправки

RFC 7301 размещает ALPN в hello: предложения в ClientHello, выбор в ServerHello. Клиент знает прикладную грамматику до False Start.

ALPN не авторизует ускорение, но устраняет угадывание протокола. Opt-in, выбор и криптографический профиль должны совпасть. Сильное шифрование не делает байты безопасными для неправильного parser.

Ошибка не возвращает уже ушедший record

Верный Finished продолжает сессию; отсутствие или ошибка требуют завершения с ошибкой аутентификации. Нельзя превращать её в обычный timeout или автоматически повторять опасное действие.

Закрытие останавливает будущее, но не забирает record у peer или активного endpoint. Конфиденциальность пути и право раскрыть данные этому адресату сейчас — разные решения.

False Start не был 0-RTT

RFC 8446 определяет TLS 1.3 и другое 0-RTT. При resumption данные идут после ClientHello под ключом из прежнего PSK; они не forward secret и не защищены от replay между соединениями.

False Start использует полный handshake, свежие ключи и ждёт Client Finished. Непроверен Server Finished, а не replay PSK-данных.

RFC 8470 создал HTTP Early-Data и 425 Too Early для 0-RTT, не False Start. RFC 9325 требует прикладной спецификации для 0-RTT и явных ALPN/cluster-контролей. Метод дисциплины общий, свойства различны.

Источники и пределы

Использованы RFC 5246, RFC 7301, RFC 7918, RFC 8446, RFC 8470 и RFC 9325. Они не измеряют текущую долю. False Start не отправлял plaintext, не пропускал сертификат, не возобновлял сессию и не требовал специальной server extension.