TLS іде всередині каналу керування, а не всім тунелем

Побачити слово TLS в описі VPN і зробити висновок, що вебпроксі зрозуміє цей трафік, — поширене спрощення. Усередині цього протоколу вузли обмінюються власними пакетами, і TLS працює як частина одного каналу в цьому обміні. Корисне навантаження, важливе для користувача, іде в іншому форматі повідомлень, тому ці дві речі ніколи не збігаються зі звичайною сесією HTTPS.

Спершу йде конверт

Кожен пакет тунелю починається з власного заголовка протоколу: типу повідомлення, ідентифікатора ключа і, на транспорті байтового потоку, префікса довжини, який позначає, де пакет закінчується. Читач, який не розбирає цей конверт, не може знати, де починається наступне поле.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Цей начерк — карта, а не таблиця байтів, бо точні поля залежать від типу повідомлення, хоча перший октет завжди упаковує код операції та ідентифікатор ключа разом. Здогадка про тип повідомлення за номером порту — це те, через що декодери зрештою неправильно називають побачене. Для діагностики важливий порядок: транспорт, потім конверт протоколу, потім один із двох видів роботи. Прочитайте конверт, перш ніж складати думку про те, що йде далі. Декодер, який починає не з того місця, видає впевнену нісенітницю.

Шар надійності належить протоколу

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

Перевага в тому, що рукостискання TLS отримує надійний носій навіть тоді, коли зовнішній транспорт — UDP. Ціна в тому, що одна датаграма може містити лише частину цієї розмови, тому ставлення до неї як до самостійного запису TLS дає нісенітницю. Перескладання має відбуватися на рівні протоколу. Тому захоплений пакет рідко виглядає як повний крок рукостискання.

Перемикання зовнішнього транспорту на TCP не прибирає цього шару. Надійний транспорт означає менше повторних передач на рівні протоколу, а не те, що кадрування зникає або трафік стає HTTP.

Пакети даних використовують інший формат

Коли сесія існує, корисне навантаження приходить як повідомлення даних, що несуть внутрішні пакети IP або кадри Ethernet. Вони захищені власними ключами та власною обробкою і не є прикладними записами TLS у жодному сенсі, який прийняла б бібліотека TLS.

Цей поділ видно в конфігурації: канал керування та канал даних мають окремі налаштування шифру, тому рядок журналу, що називає один, нічого не каже про інший. Читати сильний шифр керування як доказ сильного шифру даних — поширена помилка у звітах.

Тримайте й пов'язану оману поза поясненням. TLS — це не канал із відкритим ключем поряд із симетричним каналом даних, бо сам TLS захищає свої записи симетрично після встановлення ключів. Справжня відмінність — роль і формат пакета, а не те, яку криптографію використовує кожна сторона.

Чому проксі HTTPS не може допомогти

Проксі, що завершує TLS, очікує потік записів TLS, а потім прикладний протокол усередині нього. Канал керування цього протоколу переноситься всередині власного кадрування з шаром надійності навколо, тому проксі, що завершує, читає це кадрування як пошкоджений вхід.

Прозорий форвардер, який пропускає байти або датаграми, не інтерпретуючи їх, може працювати, за умови, що він не переписує і не перескладає потік. Питання, яке треба поставити про будь-якого посередника, — чи передає він фактичний транспорт і кадрування, а не чи підтримує він TLS десь. Запитайте це, перш ніж витрачати вечір на правила проксі. Більшість збоїв тут архітектурні, а не відсутнє налаштування.

Як правильно читати трасу

Очікуйте спершу обмін керування, потім значно більше повідомлень даних, причому обидва поділяють один транспорт. Якщо фаза керування завершується, а фаза даних застрягає, несправність стосується ключів, маршрутизації або фільтрації шляху даних, а не рукостискання. Захопіть кілька повідомлень даних і перевірте, чи вони взагалі залишають клієнт. Це єдине спостереження ділить пошук навпіл.

Історичні описи методів ключа в документації протоколу не означають, що певний випуск досі підтримує кожен старий формат. Перевірте версію, яку ви запускаєте, перш ніж будувати очікування на абзаці, що описує, як речі працювали раніше.