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 някъде. Питайте това, преди да прекарате вечер върху правила за прокси. Повечето провали тук са архитектурни, а не липсваща настройка.

Как да четем следа правилно

Очаквайте първо обмен за управление, после много по-голям брой съобщения с данни, като двете споделят един транспорт. Ако фазата на управление завърши, а фазата на данните зацикли, неизправността засяга ключове, маршрутизация или филтриране на пътя на данните, а не ръкостискането. Запишете няколко съобщения с данни и проверете дали изобщо напускат клиента. Това единствено наблюдение разделя търсенето наполовина.

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