Comments 7
Раньше утечка хэша пароля, например, из бэкапа, не была проблемой — для аутентификации на сервере этого недостаточно, а вмешаться в аутентификацию было нельзя, так как зашифрованное соединение устанавливалось до нее. Теперь, если злоумышленник заполучил хэш, он может предъявить клиенту свой сертификат, посчитать SHA2(хэш пароля + scramble + fingerprint сертификата злоумышленника) и успешно притвориться сервером.
С точки зрения эксплуатации в новой схеме нельзя поставить TLS reverse proxy перед не знающим про TLS сервером СУБД.
Хороший аргумент (для этого и пишу на хаб:).
И да и нет. Раньше вмешаться в аутентификацию было нельзя, так как зашифрованное соединение устанавливалось до нее, факт. Но раньше сертификат не проверялся, так что вмешаться было всё-таки можно. Если же сертификат был правильно подписан, то вмешаться было действительно нельзя. Но тогда и сейчас нельзя, если сертификат не само-подписаный или если юзер указал --ssl-ca, то новый протокол не применяется, а работает указанный CA. Фактически новый метод проверки сертификатов работает только в тех случаях, когда старый бы не работал. Утечка хэша — проблема, но не более, чем раньше.
TLS reverse proxy — да вроде как раньше, то же самое. Прокси же SHA2() подпись клиенту не пошлёт. Так что клиент вылетит по self-signed certificate ровно в тех же случаях, что и раньше вылетал. И не вылетит, если не вылетал.
Утечка хэша — проблема, но не более, чем раньше.
Раньше красть хэш с сервера было бесполезно. Я не знаю точного протокола аутентификации в MariaDB, но наверняка сделано по уму, и хранимого на сервере хэша недостаточно для аутентификации. Злоумышленник с хэшом не мог ни зайти на сервер, не причинить каких-либо новых проблем клиенту. Если же клиент использует новую схему, теперь злоумышленник может представиться для него сервером. Да, он мог это сделать, если TLS не использовалось вообще. Но ведь клиент считает, что если новый режим включен и пароль не скомпрометирован, то подлинность сервера надежно проверяется.
На практике утечка хэша выглядит более вероятной, чем утечка приватного ключа сервера или CA по организационным причинам. Через саму базу есть доступ к хэшам, а к файлу приватного ключа нет. Само хранение хэша и его соление придумано, чтобы утечка хэша не была проблемой — и вдруг это нарушается. Что приватный ключ-то нужно беречь, все знают.
Когда утечка произойдет, придется менять пароли всем пользователям. С одной стороны, они об этом сразу узнают без всяких CRL. С другой стороны, это нарушит их работу.
TLS reverse proxy — да вроде как раньше, то же самое. Прокси же SHA2() подпись клиенту не пошлёт.
Прокси предъявляет клиенту "подозрительный" сертификат с некоторым отпечатком и соединятеся с сервером без TLS. Откуда сервер узнает отпечаток, который известен только прокси и клиенту, чтобы отправить клиенту SHA2? Естественно, если сертификат прокси честный, то проблем не будет.
Да, хранимого на сервере хэша, конечно, недостаточно для аутентификации. Подробности, если интересно, в https://habr.com/ru/articles/323670/
Согласен, если хэши утекли, можно прикинуться сервером. Да, формально, это как утечка приватного ключа сервера или CA, но может при каких-то условиях и проще.
А про TLS reverse proxy всё равно не понимаю. Клиент коннектится с прокси, прокси — сервером без SSL. Прокси предъявляет клиенту подозрительный сертификат. Как его клиент проверит? Если никак — он разорвёт соединение.
Пусть клиент работает в новом режиме. Он получает подозрительный сертификат от прокси, у этого сертификата некий отпечаток. Далее клиент ждет от сервера SHA2(... + отпечаток сертификата). Прокси соединяется с сервером без TLS, поэтому у сервера никакого сертификата и его отпечатка логически нет, не из чего слать SHA2(...). Итого новая схема не заработает через TLS reverse proxy.
Итого при включении нового режима:
Прежде безопасная конфигурация, когда хэши были доступны и не прятались, стала небезопасной.
При компрометации секретов всем клиентам нужна перенастройка.
Прежде работавшая функциональность TLS reverse proxy для клиентов в новом режиме работать не будет.
У клиентов появляется ложное чувство безопасности, так как они включили "хоть какой-то" TLS, и теперь еще меньше шансов, что сделают нормальный. Но на самом деле гарантий, которые дает полноценная PKI, у них не появилось.
ИМХО, вредная фича.
Новая схема не заработает через TLS reverse proxy, да. Поэтому TLS reverse прокси с подозрительным сертификатом как раньше не работал, так и не заработает — в этом же вся суть схемы, не пропускать подозрительные сертификаты.
Если хэши доступны — это всегда плохо. Хэш + сниффер протокола дают достаточно информации, чтоб залогинится (с самой всё ещё распространённой "double SHA1" аутентификацией). Ну и их можно просто брутфорсить. Теперь появилась возможность играть в MitM под SSL, но ровно в тех же условиях, что и раньше. Только раньше клиент знал, что сертификат не проверяется, а теперь думает, что проверяется. Утекшие хэши открывают новый вектор, это да.
Как и раньше. Если утекли ключи — нужен новый сертификат. Всем. Если утёк хэш пароля — только тому юзеру надо менять пароль. Но это как всегда.
Почему? То что работало с TLS reverse proxy, то и будет работать. Что не работало — не заработает. Тут ничего не поменялось, никто ничего не заметит.
Это да. До какой-то степени. Чувство безопасности не ложное и пока хэши не утекли, всё прикрыто. Гарантии не такие, как у PKI, другие. Если утечёт root CA то на эту схему оно не повлияет. Если утекут хэши — повлияет на эту, но не на PKI.
Во-первых, если утек ключ сервера — только заменить сертификат на сервере и записать старый в CRL. Клиенты должны этот CRL обновить, но это по крайней мере стандартная процедура, раз уж PKI используется. Возможность подключиться никто не потеряет. Это можно считать лучше или хуже; замена пароля точно сложнее, так как требует ручных действий от двух сторон. Если утек ключ CA, да, всем все менять, но это очень маловерятно. Во-вторых, сменить пароль одному пользователю достаточно — да, но как на практике понять, что только его хэш утек? Вероятно, кто получил доступ к таблице, взял из нее все. Причем, даже если другие пользователи новую схему не применяли, у нас нет гарантий, что они не начнут, поэтому им тоже стоит сменить.
Допустим, у меня была схема с TLS reverse proxy и самоподписанным сертификатом. Клиент страдал, устанавливая сертификаты на каждую новую машину. После обновления он не сможет перестать страдать и запускать новые машины с новым режимом. В остальном мы, кажется, согласны.
SSL для всех (пользователей MariaDB), даром, и пусть никто не уйдёт обиженный