Рівні SSTP пояснено: що все ще викриває внутрішній пакет

SSTP загортає PPP і внутрішній пакет у TLS, але зовнішнє TCP-з’єднання все одно показує, хто з ким говорив. Позначте кожен рівень, перш ніж читати перехоплення.

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

Почніть із зовнішнього носія

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

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

Ідіть за інкапсуляцією всередину

Усередині захищеного каналу розміщено керівний обмін SSTP, далі сеанс PPP, далі мережевий пакет, який клієнт хоче отримати. Кожен рівень має власні переговори, власні повідомлення про помилки й власну машину станів. Тому збій з одного погляду може виглядати як збій TLS, а з іншого — як збій PPP. Читання рівнів по порядку показує, яка машина станів зупинилася.

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

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

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Позначте спостерігача, перш ніж читати перехоплення

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

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

Збережіть перевірки, які схема не може довести

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

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

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"

Схожі статті