Нашёл буквально несколько упоминаний о SSTP на Хабре, в связи с чем хочу рассказать про устройство этого протокола. Secure Socket Tunneling Protocol (SSTP) – протокол VPN от Microsoft, основанный на SSL и включённый в состав их ОС начиная с Windows 2008 и Windows Vista SP1. Соединение проходит с помощью HTTPS по 443 порту. Для шифрования используется SSL, для аутентификации — SSL и PPP. Подробнее про устройство — под катом.
Серверная часть протокола включена в ОС Windows Server 2008, 2008 R2, 2012, 2012 R2. Далее рассказывается про текущую (и, кажется, единственную) версию — 1.0.
В основном используется для подключения типа узел-узел или узел-сеть. По умолчанию для соединения используется 443 порт, но есть вариант использовать 80-ый порт.
Условно стек протоколов при передаче данных выглядит так (показаны только заголовки, относящиеся к VPN, без подлежащих уровней):
Структура собственно SSTP пакета:
Флаг C = 0 если пакет с данными, и C = 1, если пакет управляющий.
SSTP устроен довольно просто за счёт того, что он использует функционал других криптографических протоколов. Собственно, единственная криптографическая функция, реализуемая самим SSTP – это «cryptographic binding», о котором говорится ниже.
Всё шифрование данных осуществляется протоколом SSL. Все пакеты протоколов SSTP, PPP и выше передаются только в зашифрованном виде.
Авторизация проходит сразу по трём протоколам: SSL, PPP и, собственно, сам SSTP.
При установлении SSL соединения проходит авторизация сервера клиентом по SSL сертификату. Аутентификация клиента сервером допускается, однако не поддерживается ни одной из серверных Windows.
На уровне PPP происходит авторизация клиента сервером, и дополнительно может происходить аутентификация сервера. Windows Server поддерживают аутентификацию клиента на уровне PPP с помощью MS-CHAPv2, EAP-TLS, PEAP-MSCHAPv2, PEAP-TLS. Также поддерживаются Password Authentication Protocol (PAP – не шифрованный пароль) и CHAP, однако их использование не рекомендуется, т. к. они не предусматривают обмена ключевой информацией, которая необходима для «cryptographic binding». Собственно, тут те же методы аутентификации, что и в PPTP. Отличие от PPTP в том, что обмен происходит внутри уже созданного шифрованного канала SSL.
Теперь о том, что же такое этот «cryptographic binding». Из-за того, что аутентификация клиента и сервера происходит на разных уровнях, возможна атака человек посередине, когда нарушитель устанавливает SSL соединение с сервером и незащищённое PPP соединение с клиентом.
Для защиты от этого используется подписывание сообщения уровня SSTP об установлении соединения (Call Connected message, см ниже) ключом, выработанным в процессе аутентификации на уровне PPP. Таким образом сервер может убедиться, что тот, кто установил SSL соединение, и тот, кто прошёл PPP авторизацию — это один и тот же клиент. Собственно, это и называют «cryptographic binding».
1. Клиентом устанавливается TCP соединение на 443-ий порт SSTP сервера.
2. Проходит установление SSL/TLS соединения поверх TCP соединения. Клиент проверяет сертификат сервера.
3. Проходит HTTPS приветствие.
4. Начинается установление SSTP соединения. Все SSTP пакеты идут внутри HTTPS. Клиент посылает запрос на установление соединения (Call Connect Request message). В этом сообщении передаётся номер протокола, который будет использоваться внутри SSTP; в текущей версии стандарта это всегда PPP.
5. Сервер проверяет запрос и, если всё ОК, отвечает на него подтверждением (Call Connect Acknowledge message), в котором сообщает 32-битное случайное число (ClientNonce), используемое в следующем ответе клиента для защиты от повторения, а так же список хэш-функций для подписи следующего ответа (SHA1 и/или SHA256).
6. Происходит PPP авторизация. Все пакеты PPP вложены в SSTP пакеты и, соответственно, зашифрованы SSL.
7. Клиент посылает Call Connected message, в которое включаются ClientNonce и Хэш сертификата сервера (ClientCertificateHash), полученного при установлении SSL соединения.
Это сообщение подписывается с помощью указанной сервером хэш-функции (точнее HMAC на её основе) и ключа, полученного в процессе PPP авторизации. Таким образом осуществляется cryptographic binding. Если для авторизации в PPP используется протокол, не поддерживающий генерацию ключей для MPPE (PAP или CHAP), то HMAC вычисляется с использованием ключа, равного нулю; т. е. фактически cryptographic binding не производится и описанная выше атака человек посередине возможна.
8. Сервер проверяет Call Connected message, на этом SSTP считается установленным.
9. Заканчивается установление параметров PPP.
Всё, соединение установлено. Дальше стороны обмениваются пакетами с данными.
Что бы отличить простой канала от разрыва связи стороны «пингуют» друг друга. Если в течение 60 секунд обмена пакетами не было, посылается Echo Request (управляющий пакет протокола SSTP). Если в течение следующих 60 секунд нет ответа, соединение разрывается.
Завершение соединения происходит без особых нюансов, стороны обмениваются SSTP-сообщениями об окончании соединения и через несколько секунд рвут соединение.
Серверная часть протокола включена в ОС Windows Server 2008, 2008 R2, 2012, 2012 R2. Далее рассказывается про текущую (и, кажется, единственную) версию — 1.0.
В основном используется для подключения типа узел-узел или узел-сеть. По умолчанию для соединения используется 443 порт, но есть вариант использовать 80-ый порт.
Условная схема пакета с данными
Условно стек протоколов при передаче данных выглядит так (показаны только заголовки, относящиеся к VPN, без подлежащих уровней):
Структура собственно SSTP пакета:
Флаг C = 0 если пакет с данными, и C = 1, если пакет управляющий.
Немного слов об используемой криптографии
SSTP устроен довольно просто за счёт того, что он использует функционал других криптографических протоколов. Собственно, единственная криптографическая функция, реализуемая самим SSTP – это «cryptographic binding», о котором говорится ниже.
Всё шифрование данных осуществляется протоколом SSL. Все пакеты протоколов SSTP, PPP и выше передаются только в зашифрованном виде.
Авторизация проходит сразу по трём протоколам: SSL, PPP и, собственно, сам SSTP.
При установлении SSL соединения проходит авторизация сервера клиентом по SSL сертификату. Аутентификация клиента сервером допускается, однако не поддерживается ни одной из серверных Windows.
На уровне PPP происходит авторизация клиента сервером, и дополнительно может происходить аутентификация сервера. Windows Server поддерживают аутентификацию клиента на уровне PPP с помощью MS-CHAPv2, EAP-TLS, PEAP-MSCHAPv2, PEAP-TLS. Также поддерживаются Password Authentication Protocol (PAP – не шифрованный пароль) и CHAP, однако их использование не рекомендуется, т. к. они не предусматривают обмена ключевой информацией, которая необходима для «cryptographic binding». Собственно, тут те же методы аутентификации, что и в PPTP. Отличие от PPTP в том, что обмен происходит внутри уже созданного шифрованного канала SSL.
Теперь о том, что же такое этот «cryptographic binding». Из-за того, что аутентификация клиента и сервера происходит на разных уровнях, возможна атака человек посередине, когда нарушитель устанавливает SSL соединение с сервером и незащищённое PPP соединение с клиентом.
подробнее
Т.е. нарушитель сначала устанавливает HTTPS соединение с сервером. Затем легитимному клиенту предлагает авторизоваться у себя по PPP, представляясь каким-нибудь PPP (но не SSTP) сервером, а дальше шлёт клиенту PPP запросы авторизации, которые получает от SSTP сервера внутри HTTPS соединения, а серверу — полученные от легитимного пользователя ответы.
Для защиты от этого используется подписывание сообщения уровня SSTP об установлении соединения (Call Connected message, см ниже) ключом, выработанным в процессе аутентификации на уровне PPP. Таким образом сервер может убедиться, что тот, кто установил SSL соединение, и тот, кто прошёл PPP авторизацию — это один и тот же клиент. Собственно, это и называют «cryptographic binding».
подробнее
В процессе PPP авторизации между легитимным клиентом и сервером вырабатывается общий секрет, который невозможно получить прослушивая PPP соединение. Т.е. нарушитель этот секрет знать не может. Нарушитель также не может заставить клиента подписать SSTP сообщение, т.к. клиент считает, что устанавливал незащищённое PPP соединение и про SSTP соединение ничего не знает.
Порядок установления соединения
1. Клиентом устанавливается TCP соединение на 443-ий порт SSTP сервера.
2. Проходит установление SSL/TLS соединения поверх TCP соединения. Клиент проверяет сертификат сервера.
3. Проходит HTTPS приветствие.
4. Начинается установление SSTP соединения. Все SSTP пакеты идут внутри HTTPS. Клиент посылает запрос на установление соединения (Call Connect Request message). В этом сообщении передаётся номер протокола, который будет использоваться внутри SSTP; в текущей версии стандарта это всегда PPP.
5. Сервер проверяет запрос и, если всё ОК, отвечает на него подтверждением (Call Connect Acknowledge message), в котором сообщает 32-битное случайное число (ClientNonce), используемое в следующем ответе клиента для защиты от повторения, а так же список хэш-функций для подписи следующего ответа (SHA1 и/или SHA256).
6. Происходит PPP авторизация. Все пакеты PPP вложены в SSTP пакеты и, соответственно, зашифрованы SSL.
7. Клиент посылает Call Connected message, в которое включаются ClientNonce и Хэш сертификата сервера (ClientCertificateHash), полученного при установлении SSL соединения.
Это сообщение подписывается с помощью указанной сервером хэш-функции (точнее HMAC на её основе) и ключа, полученного в процессе PPP авторизации. Таким образом осуществляется cryptographic binding. Если для авторизации в PPP используется протокол, не поддерживающий генерацию ключей для MPPE (PAP или CHAP), то HMAC вычисляется с использованием ключа, равного нулю; т. е. фактически cryptographic binding не производится и описанная выше атака человек посередине возможна.
8. Сервер проверяет Call Connected message, на этом SSTP считается установленным.
9. Заканчивается установление параметров PPP.
Всё, соединение установлено. Дальше стороны обмениваются пакетами с данными.
Обрыв соединения
Что бы отличить простой канала от разрыва связи стороны «пингуют» друг друга. Если в течение 60 секунд обмена пакетами не было, посылается Echo Request (управляющий пакет протокола SSTP). Если в течение следующих 60 секунд нет ответа, соединение разрывается.
Завершение соединения
Завершение соединения происходит без особых нюансов, стороны обмениваются SSTP-сообщениями об окончании соединения и через несколько секунд рвут соединение.
Подробное описание протокола.
Очень краткое описание протокола.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:
- Massacres That Matter - Part 1 - 'Responsibility To Protect' In Egypt, Libya And Syria
- Massacres That Matter - Part 2 - The Media Response On Egypt, Libya And Syria
- National demonstration: No attack on Syria - Saturday 31 August, 12 noon, Temple Place, London, UK
Комментариев нет:
Отправить комментарий