Назад | Перейти на главную страницу

Безопасно ли для удаленного рабочего стола Windows запрашивать имя пользователя / пароль перед проверкой сертификата?

При подключении к удаленному рабочему столу на стороне клиента: (в моем случае клиент RD Windows 8.1 к Windows 10 Enterprise 1709 / 16299.98)

Нам нужно ввести и передать имя пользователя / пароль на клиенте, прежде чем проверять сертификат сервера.

1 \ Если имя пользователя / пароль неверны, клиент RD просто сообщает, что CREDENTIAL не работает, а затем запрашивает повторный ввод.

2 \ Если имя пользователя / пароль верны, клиент удаленного рабочего стола затем предупредит клиента о том, что СЕРТИФИКАТ сервера выдан недоверенной организацией (в большинстве случаев сам сервер выдается автоматически).

Так правильно ли это для защиты имени пользователя и пароля от атаки Man-in-middle? Или он просто использует имя пользователя / пароль в качестве ключа для симметричного шифрования?

Eсть много из авторизация, аутентификация и квитирование происходит даже до того, как будут отправлены какие-либо данные клиента. В разных версиях протокола многое изменилось. Если вам нужно особое поведение, используйте соответствующую версию.

Хорошие новости: ваш пароль никогда не отправляется через незащищенное соединение и не используется в качестве ключа для чего-либо. В любом случае это было бы невозможно, поскольку аутентифицирующая машина никогда не имеет к нему доступа.

2 \ Если имя пользователя / пароль верны, клиент удаленного рабочего стола выдаст сообщение для предупреждения сертификата клиента.

Вы уверены, что это не отображение сертификата проверки подлинности сервера? Этот сертификат гарантирует, что сервер, на который вы отправляете свои учетные данные, является сервером (или шлюзом, или брокерской службой), к которому вы подключились в первую очередь (судя по его имени [CN] в сертификате).

Это небезопасно. Вот почему Microsoft создала Remote Credential Guard и Restricted Admin Mode. Это также один из недостатков использования аутентификации на уровне сети.

https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

Если целевая система или объект MITM скомпрометированы, вы просто предоставили им хэш своих учетных данных.