Кто может похвалить/покритиковать sstp?

Проблема в парольной аутентификации.

Можно еще port knocking прикрутить сверху, чтобы от active probing спрятать

тащемта хитрые dpi даже доставку вирусов по https могут определять. так что вопрос только в ресурсах и желании.

Но там-же сертификаты еще

vpn

парольной аутентификации.

Проблема

эээ...

Хм, похоже на Cisco AnyConnect. Про сервак не знаю, а вот клиент под Линукс родной (OpenVPN ЕМНИП).

OpenVPN ЕМНИП

Эм нет - это два разных vpn.

Да, перепутал.
Вот так подключаюсь:

$ openconnect --script /etc/vpnc/vpnc-script сервер

OpenConnect is an SSL VPN client initially created to support Cisco's AnyConnect SSL VPN. It has since been ported to support the Juniper SSL VPN which is now known as Pulse Connect Secure.

OpenConnect is released under the GNU Lesser Public License, version 2.1.

Сервак тоже есть, но я не пробовал:

OpenConnect VPN Server

OpenConnect server (ocserv) is an SSL VPN server. Its purpose is to be a secure, small, fast and configurable VPN server. It implements the OpenConnect SSL VPN protocol, and has also (currently experimental) compatibility with clients using the AnyConnect SSL VPN protocol. The OpenConnect protocol provides a dual TCP/UDP VPN channel, and uses the

А что значит прикинуться https?

сервер

~ $ openssl req -x509 -newkey rsa:4096 -nodes -keyout https.key -out https.pem -days 365
...
Common Name (e.g. server FQDN or YOUR name) []:localhost
...
~ $ openssl s_server -key https.key -cert https.pem

клиент

~ $ openssl s_client -CAfile https.pem

Я прикинулся https?

1. Клиентом устанавливается TCP соединение на 443-ий порт SSTP сервера.
2. Проходит установление SSL/TLS соединения поверх TCP соединения. Клиент проверяет сертификат сервера.
3. Проходит HTTPS приветствие.
4. Начинается установление SSTP соединения. Все SSTP пакеты идут внутри HTTPS. Клиент посылает

До SSTP устанавливается https сессия

1. Лего

openssl s_server -key https.key -cert https.pem -accept 443

openssl s_client -CAfile https.pem -port 443

2. Уже проверяет. Хотя клиенту можно еще добавить -verify_return_error
3. Мы ведь уже в приватном канале, кому какая разница какое там приветствие?
4. Тоже, что и в 3.

Со стороны dpi это будет выглядеть как https или не совсем?

Не для аутентификации вроде. По крайней мере в микротике.

Надо по открытому ключу.

Та мсначала SSL/TLS устанавлвиавется,а уже потом парользая авториазция по pap/chap/ms-chap/ms-chap2.

Спасибо, сам уже сообразил, когда комментарий отправлял :)

Линуксовый клиент не умеет обрабатывать ситуацию смены пароля. Если на сервере пароли регулярно меняются, придётся держать виртуалку с Windows.

Эм, а просто поменять пароль руками - нет?

а просто поменять пароль руками - нет?

Если пользователь не может придти к серверу и поменять пароль на нём, а может только подключаться удалённо, когда-нибудь настанет неудобная ситуация. Подключаешься, а клиент пишет, что пароль не подходит. Виндовый в этом случае предлагает тебе сменить пароль прямо на месте, а в линуксовом этого я не увидел.

Хотя если ты контролируешь и клиент, и сервер, то можно. Можно вообще отключить принудительную ротацию паролей.

Хм, но если не подключается и ты можешь узнать обновленный пароль(пользователи win его не придумывают ведь), то что меняет поправить в конфиге?

пользователи win его не придумывают ведь

Как раз и придумывают. Обычное дело. Приходишь на рабочее место, логинишься, а тебе: «пароль устарел, меняй. Пока не поменяешь, дальше не пущу». Админы срок действия пароля обычно оставляют 42 дня, по дефолту.

Тут то же самое, только удалённо.

Хм, забавно не читал про такое. Типа пароль задает не сервер а пользователь? Видимо для «Удаленных рабочих мест» виндовых фитча.

Типа пароль задает не сервер а пользователь?

Конечно пароль задаёт пользователь. Когда создают учётную запись, пользователю выдают пароль. При первом же логине от него требуется придумать новый пароль. Как только срок действия пароля истекает, от него требуется придумать новый. В зависимости от настроек параноидальности могут потребовать, чтобы хеш от нового пароля не совпадал с хешами N последних паролей.

Это же вроде стандартно у всех, разве нет?

Так вот это я и сам хотел бы выяснить. Как dpi понимает, что именно по шифрованному передается.

Это относительно новый VPN-протокол, поддерживаемый в Windows, начиная с Vista. От PPTP он отличается более простыми требованиями к каналу: SSTP работает везде, где работает обычное HTTPS-соединение. И больше не нужно никакого GRE.

SSTP-сервер есть на Windows, начиная с Windows Server 2008, SSTP-сервер для Linux, на MikroTik SSTP-сервер тоже есть и прекрасно работает.

Хттпс научились расшифровывать? А мужики то не знали!

Так https же невозможно отличить от любого другого tls-соединения: ведь всё начинается с tls клиент-сервер-приветов, а что потом - постороннему неведомо. Есть только один косвенный признак: стандартный порт, который, очевидно, можно использовать и для того, чтобы косить под «https».

С нужными сертификатами (или из-за ошибки) вообще тривиально.

нет канешна. выделяют определенные патерны и по ним блокируют.

Это же вроде стандартно у всех, разве нет?

Да нет, обычно пароль выдает администратор vpn сервера и меняет его сам либо по запросу клиента.

Какие ещё паттерны в шифрованном потоке?

Это 4.2

Это да. Простота получения сертификата сводит все шифрование на нет. Даже пиннинг ключей не сильно рабочий (даже в теории) Разве что на основе dnssec можнл придумать что нибудь рабочее. Но все равно все сведется к доверии к корневым ключам.

lol.
я ж не говорю про внедрение внутрь.
вон скайп когда ещё он был децентрализованным и защищенным, тоже умели блокировать.