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 некаде. Прашајте го тоа пред да потрошите вечер на прокси правила. Повеќето неуспеси овде се архитектонски, а не недостига поставка.

Правилно читање на трага

Очекувајте прво контролна размена, потоа многу поголем број податочни пораки, двете делат еден транспорт. Ако контролната фаза заврши, а податочната фаза заглави, дефектот се однесува на клучеви, рутирање или филтрирање на податочната патека, а не на ракувањето. Фатете неколку податочни пораки и проверете дали воопшто го напуштаат клиентот. Тоа едно набљудување ја дели потрагата на половина.

Историските описи на методите за клуч во документацијата на протоколот не значат дека дадено издание сѐ уште поддржува секој стар формат. Проверете ја верзијата што ја извршувате пред да изградите очекување врз пасус што опишува како работите порано функционирале.