А внутри у ней неонка и думатель
Микрософт лапочки. Читаешь про Azure Files и про безопасность трафика в SMB 3.0 - шифрование, цифровые подписи, все дела - и восхищаешься: вот здорово! А потом думаешь - а как, ёлы-палы, ты вообще знаешь, что подключаешься к настоящему серверу \\mydearfiles.file.core.windows.net, а не к липовому? И тут понимаешь, что никак.
Сертификата, как в HTTPS нету. Да, SMB работает с Kerberos, который аутентификацию обеих сторон умеет, но какой тебе Керберос при обращении к Azure Files через Интернет? А что есть? А есть древний NTLM, который умеет лишь серверу юзерскую личность доказать, а наоборот нет.
А потом думаешь - а тогда на основе чего, граждане, вы ключи для своего замечательного шифрования вырабатываете, о котором с гордостью рассказываете, что оно на самых модных алгоритмах из лучших домов Парижа, от самого месье Галуа? А на основе того самого NTLM, про который сами же честно пишете, что:
NTLM is a challenge response protocol and its session key is based on password hashing that relies on weak cryptography.
NTLM does not support any modern cryptographic methods, such as AES or SHA-256. Its key derivation from the password is based on MD4 [RFC1320], DES [FIPS46-2], HMAC_MD5, and RC4.
NTLM does not use any salt. It is possible to observe a network packet trace and produce the same key if the attacker knows password, as shown in the appendix by an example of NTLMv2 session key calculation.
NTLM does not offer mutual authentication between client and server. The is no so such flag in the protocol.
The password length and complexity should be chosen carefully to mitigate brute force attacks.
At a minimum, NTLMv2 should be used, and auditing should be in place.
Ну и чего ж тогда эти ваши AES-128-CMAC, AES-128-GCM и HMAC-SHA256 стоят?
То есть реально полагаться на шифрование в SMBv3 можно там, где оно особо и не нужно: в контролируемых корпоративных средах, где есть Active Directory и можно через политики отключить использование NTLM, чтобы избежать вражеских хитростей типа downgrade.
А вот атаки man-in-the-middle на Azure Files по SMB ничто не предотвращает. Даже если "настоящий" пароль (access key) расшифровать не получится - это нафиг не надо: ничто не мешает запросить у настоящего сервера челлендж, передать клиенту, получить шифрованный пароль, передать серверу, получить доступ. Причём полный - иного варианта по SMB через Интернет просто не предусмотрено.
Update: последний абзац неверен, кота занесло. SMB Signing таки предотвращает MiTM, хотя я долго не мог понять, как. Ответ узнал из этой блестящей презентации - любителям криптопорна всячески её советую. Очень грубо говоря: NTLM использует третью производную от юзерского пароля, а для того, чтобы создавать подписи на пакетах, надо знать первую. Если атакующий перехватывает-подменяет полностью весь обмен между клиентом и сервером, он увидит эту самую третью производную (параметр NTProofStr), но он будет не в состоянии использовать первую (NT Hash), чтобы вычислить общий с сервером сессионный ключ, который затем используется для подписей и для шифрования. То есть аутентификацию от имени клиента атакующий пройдёт, но затем всё - ни расшифровывать трафик, ни подделывать трафик не выйдет. Возможно, какие-то replay attacks и выгорят.
Таким образом, общий сессионный ключ и его производные (ключи для подписей и шифрования) доказывают серверу, что клиент знает правильный пароль - и одновременно доказывает клиенту, что сервер знает его пароль (иначе он был бы не в состоянии посылать правильно зашифрованный и подписанный трафик). Хитро придумано, уважаю.
Тем не менее: эта схема доказывает клиенту, что сервер знает его пароль - но не доказывает, что он подключился именно к тому серверу, к какому хотел: поскольку адрес сервера ко всем этим шифроприключениям никакого отношения не имеет. Таким образом, проблема существенно меньше, чем я думал, но место для вражеских манипуляций таки оставляет.
Но поскольку в случае Azure Files пароль уникален для каждого "сервера" (access key для storage account), генерируется самим облаком и не может быть назначен клиентом, то и это не беда. В общем, мой наезд был не по делу, моё поведение недостойно советского офицера, я был нетрезв.
Сертификата, как в HTTPS нету. Да, SMB работает с Kerberos, который аутентификацию обеих сторон умеет, но какой тебе Керберос при обращении к Azure Files через Интернет? А что есть? А есть древний NTLM, который умеет лишь серверу юзерскую личность доказать, а наоборот нет.
А потом думаешь - а тогда на основе чего, граждане, вы ключи для своего замечательного шифрования вырабатываете, о котором с гордостью рассказываете, что оно на самых модных алгоритмах из лучших домов Парижа, от самого месье Галуа? А на основе того самого NTLM, про который сами же честно пишете, что:
Ну и чего ж тогда эти ваши AES-128-CMAC, AES-128-GCM и HMAC-SHA256 стоят?
То есть реально полагаться на шифрование в SMBv3 можно там, где оно особо и не нужно: в контролируемых корпоративных средах, где есть Active Directory и можно через политики отключить использование NTLM, чтобы избежать вражеских хитростей типа downgrade.
А вот атаки man-in-the-middle на Azure Files по SMB ничто не предотвращает. Даже если "настоящий" пароль (access key) расшифровать не получится - это нафиг не надо: ничто не мешает запросить у настоящего сервера челлендж, передать клиенту, получить шифрованный пароль, передать серверу, получить доступ. Причём полный - иного варианта по SMB через Интернет просто не предусмотрено.
Update: последний абзац неверен, кота занесло. SMB Signing таки предотвращает MiTM, хотя я долго не мог понять, как. Ответ узнал из этой блестящей презентации - любителям криптопорна всячески её советую. Очень грубо говоря: NTLM использует третью производную от юзерского пароля, а для того, чтобы создавать подписи на пакетах, надо знать первую. Если атакующий перехватывает-подменяет полностью весь обмен между клиентом и сервером, он увидит эту самую третью производную (параметр NTProofStr), но он будет не в состоянии использовать первую (NT Hash), чтобы вычислить общий с сервером сессионный ключ, который затем используется для подписей и для шифрования. То есть аутентификацию от имени клиента атакующий пройдёт, но затем всё - ни расшифровывать трафик, ни подделывать трафик не выйдет. Возможно, какие-то replay attacks и выгорят.
Таким образом, общий сессионный ключ и его производные (ключи для подписей и шифрования) доказывают серверу, что клиент знает правильный пароль - и одновременно доказывает клиенту, что сервер знает его пароль (иначе он был бы не в состоянии посылать правильно зашифрованный и подписанный трафик). Хитро придумано, уважаю.
Тем не менее: эта схема доказывает клиенту, что сервер знает его пароль - но не доказывает, что он подключился именно к тому серверу, к какому хотел: поскольку адрес сервера ко всем этим шифроприключениям никакого отношения не имеет. Таким образом, проблема существенно меньше, чем я думал, но место для вражеских манипуляций таки оставляет.
Но поскольку в случае Azure Files пароль уникален для каждого "сервера" (access key для storage account), генерируется самим облаком и не может быть назначен клиентом, то и это не беда. В общем, мой наезд был не по делу, моё поведение недостойно советского офицера, я был нетрезв.