Не деплойте на следующей неделе, а то будете по колено в оливье дебажить, пока пьяная тёща танцует под «Руки вверх».

Доехал до 35c3.
В первый день не слижком много технических докладов, которые привлекают внимание, но много политоты(красным помечена).
Могу выделить выступление Hanno Böck — The Rocky Road to TLS 1.3 and better Internet Encryption
1. Неплохой обзор padding oracle уязвимостей TLS из прошлого. Спикер обращает внимание на то что с каждым очередным исправлением код обрастает "воркэраундами", которые сильно его усложняют. Причем некоторые исправления, вносимые как в код клиентов, так и в код серверов, пораждают необходимость делать другие исправления. Например, когда в openssl фиксили lucky thirteen то получили ещё один баг из примерно той же группы.

Хорошим примером является также SCSV, про него советую самим погуглить или посмотреть слайды до конца, скажу только:
Браузеры в какой-то момент реализовали последовательный даунгрейд версии TLS при обнаружении ошибки установления TLS соединения... вобщем оказалось что активный атакующий может понизить версию протокола до уязвимой(например до SSL 3) и понадобился ещё один воркэраунд.

Документация пухнет, код пухнет, обратная совместимость(и уязвимости) остаётся.

2. TLS 1.3 берёт новый курс и депрекейтит:
- CBC-Modes, RC4, Triple-DES
- GCM with explicit nonces
- RSA Encryption, PKCS #1 1.5
- MD5, SHA1
- Diffie Hellman with custom or small parameters
- Obscure, custom and insecure Elliptic Curves

Handshake улучшен и теперь быстрее и безопаснее.
Также новая версия TLS добавляет 0 RTT, но он не бесплатен и содержит грабли в виде replay атаки, которая становится возможной в системе с несколькими зонами, которые не принимают session ticket'ы друг-друга.
В таких системах возможно, например, дублирование действий, если реплеется не идемпотентный HTTP запрос, так что 0 RTT опционален и требует вдумчивого применения.

3. Новую версию нужно как-то распространить, это не просто и это нельзя сделать мгновенно. Основные проблемы:
- нужно поддерживать несколько версий одновременно, что включает в себя сценарии по типу "клиент с версией 1.3 обращается к серверу, который поддерживает максимум 1.0" или наоборот
- "кровавый энтерпрайз", который не любит обновляться и часто не работает со свежими версиями вообще
- анализаторы траффика

Второе названо "version intolerance" и предложено решение: оставим старую версию, т.е. TLS 1.2, с которой поддерживающий TLS 1.3 клиент будет соединяться с сервером, но добавим extension, в котором будут указаны поддерживаемые версии TLS, среди которых будут присутствовать такие, которые никогда не будут существовать, а сервер выберет наибольшую поддерживаемую. Это должно упростить релиз будущих версий протокола и отлов "version intolerance" на этапе тестирования кода разработчиками.

Некоторые анализаторы траффика настроены так что если видят пакет TLS 1.3 то... просто дропают его. Как фиксить?
- сделать траффик похожим на TLS 1.2
- отправлять ChangeCipherSpec после ServerHello/HelloRetryRequest чтобы анализатор думал что дальше траффик трогать не надо

(а-а-а-а-а-а, госпади, какой же ад)

Помимо всего этого(там ещё забавная история с принтером и NSA была):
- в банковском секторе нашлись недовольные депрекейтом RSA key-exchange'а, желающие отменить это решение
- были запросы сделать "visibility mode", чтобы шифрование можно было отключать

На эти пункты получили отрицательный ответ... так появился eTLS(TLS для энтерпрайза, ага):

eTLS, defined in TS 103 523-3, specifies an implementation variant of TLS 1.3. This variant is needed because TLS 1.3 removes support for certain key exchange methods, which prevents passive decryption of TLS 1.3 sessions at any scale.

Вроде бы он обратно-совместим с стандартом IETF. Ещё детали про новую версию TLS, которые всё ещё вполне актуальны, были на 33c3.
Слайды, видео.

Помимо этого выступления я побывал и на других, но выделить могу лишь Space Ops 101 про управление космическими миссиями по выводу спутников на орбиту и их жизненному циклу. Описывать не буду, смотрите запись.