Слоевете на 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"

Подобни статии