Re: Как различить SSL сертификаты, выданные различными промежуточными ЦС собщим корневым ЦС?

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Mon, Aug 27, 2012 at 05:08:07PM -0400, Maximus43 wrote:

> Я все-таки повторюсь со своей проблемой.
> Пытался внимательно понять, как и что работает, пришел к следующим выводам:
> 1. Директива ssl_client_certificate определяет список доступных CA для
> клиента, сертификаты этих CA сервер готов рассматривать для авторизации по
> сертификату. Со стороны клиента выглядит как:
> ---
> Acceptable client certificate CA names
> /CN=SubCA1/O=Test JSC/L=Moscow/C=RU
> ---
> Браузер, получая такой сертификат смотрит все клиентские пары ключей и
> выбирает те, которые подписаны указанным сертификатом.
> 
> 2. Директива ssl_certificate содержит ссылку на файл с серверным SSL
> сертификатом. Причем если в сертификате верно прописаны AIA caIssuer и
> Authority Key Identifier, то клиент может самостоятельно построить цепочку
> до корневого сертификата. Возможно добавить промежуточные CA после
> серверного сертификата, однако корневой сертификат добавлять туда не стоит,
> в этом нет смысла. Корневые сертификаты должны присутствовать у клиента.
> 
> Вроде все должно работать предсказуемо, однако это не так.
> 
> Проблемы начинаются из-за того, что нет разделения механизма проверки
> клиентских сертификатов и предоставления клиенту списка принимаемых
> сертификатов. Это приводит к тому, что в директиве ssl_client_certificate
> ссылка должна указывать на файл, который помимо серверного сертификата
> должен ВСЕГДА содержать цепочку сертификатов, включая корневой, иначе
> проверка клиентского сертификата завершится неудачно с кодом 20:unable to
> get local issuer certificate для отсутствующих сертификатов и 27:certificate
> not trusted для всех остальных в цепочке.
> Проблема наличия корневого сертификата в списке доступных для клиента в том,
> что браузер предлагает использовать все сертификаты всех подчиненных CA,
> подписанных корневым сертификатом. Это является потенциальной проблемой
> безопасности. И пользователь с сертификатом, подписанным SubCA2, сможет
> получить доступ на сайт вместо пользователя с сертификатом, подписанным
> SubCA1.
> 
> Есть ли возможность реализовать передачу доступных CA клиенту директивой
> ssl_client_certificate в виде существующей функциональности, а вот механизм
> проверки клиентских сертификатов сделать независимым от данной директивы?
> Вероятно придется определить новый параметр типа
> ssl_verify_client_certificate, который будет указывать на файл с цепочками
> доверенных сертификатов, включая корневые.

Однако проблема безопасности при этом как была, так и остаётся: 
если вы доверяете корневой CA, и verify depth стоит 2 - то вы 
доверяете *всем* сертификатам, выпущенным этой CA, до 2-го уровня 
включительно, т.е. в том числе всем сертификатам выпущенным SubCA1 
и SubCA2.

Как именно клиент узнает, что вам там можно прислать 
сертификат, подписанный SubCA2 - не важно, но когда/если узнает - 
получить доступ сможет без проблем.  И даже промежуточных 
сертификатов при необходимости сможет прислать столько, сколько 
потребуется.

Как мне видится, проблема безопасности тут проистекает из неверной 
предпосылки, что доверяя CA, мы как-то можем оное доверие 
ограничить.  Это не так, точнее - не совсем так.  Если хочется 
что-то ограничить - надо следом за аутентификацией, которую 
собственно и обеспечивает проверка сертификата, делать ещё и 
авторизацию.  Сейчас в nginx'е это теоретически можно делать с 
помощью предоставляемых переменных $ssl_*.

Что касается передачи клиентам списка сертификатов, отличного от собстенно 
списка доверенных сертификатов, то сделать это безусловно можно.  
И для рассмотренного выше случая даже полезно - клиент будет лучше 
представлять, какой именно сертификат от него хотят (в терминах 
RFC 5246 - "to describe ... desired authorization space").

Первый патч вот тут:

http://nginx.org/patches/ocsp-stapling/

добавляет директиву ssl_trusted_certificate, которая 
позволяет расширить список сертификатов, используемых для 
проверки.  При этом клиенту по прежнему передаются имена только 
тех сертификатов, что указаны в ssl_client_certificate.

Но надо понимать, что к каким-либо проблемам безопасности это 
разделение никакого отношения не имеет, см. выше.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru