Уровни 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"

Похожие статьи