Совместимость SSPI разных CSP

[basid]

Насколько я понимаю, для добавления поддержки ГОСТ-шифров системным TLS используется S(ecurity)S(upport)P(rovider)I(nterface).

Возможно ли (чисто технически) обеспечить совместимость двух разных CSP, каждый из которых добавляет в SSPI один и тот же набор алгоритмов?

Пример.
Если не требуется авторизация по клиентскому сертификату, то выбирается "умалчиваемый" CSP.
Если требуется авторизация клиента по сертификату, то выбирается CSP, который "умеет" работать с закрытыми ключами соответствующего контейнера.

?

[R.Sheyn]

Когда-то давно эта тема поднималась на форуме крипто-про, что-то там даже понаотвечали и вроде даже у кого-то получилось подружить криптопровайдеры.

У Инфотекса позиция крайне строгая, с microsoft cryptoapi может работать только один криптопровайдер.

[basid]

"Поддержка MS CryptoAPI для электронной подписи" это другое.

Про позицию - в курсе, но интересует именно техническая возможность. Без оглядки на регулятора и "нет, делать не будем".

[kelz]

On 8/5/2018 at 1:09 AM, basid said:

Пример.
Если не требуется авторизация по клиентскому сертификату, то выбирается "умалчиваемый" CSP.
Если требуется авторизация клиента по сертификату, то выбирается CSP, который "умеет" работать с закрытыми ключами соответствующего контейнера.

Речь именно про TLS или про авторизацию через SSP/AP в принципе? Во втором случае всё уже именно так и сделано - lsasrv на основании имени провайдера перенаправляет запрос на соответствующий SSP/AP провайдер (не путать с CSP провайдером). Если речь именно про системный TLS, то им занимается Schannel SSP, а вызывающий код должен указать имя провайдера UNISP_NAME. Казалось бы можно зарегистрировать свой провайдер с новым именем и поднять на нём гостовый TLS, но работать он будет только с софтом специально написанным для этого SSP/AP, а во всяких IE и Edge (а именно это и нужно) в недрах wininet.dll уже захардкожен этот UNISP_NAME. И это только первая проблема. Нужно либо заменять schannel своим ssp/ap, либо заменять динамически UNISP_NAME на что-то своё. И там и там без хуков не обойтись, и здесь всплывает вторая проблема - допустим каким-то образом получилось выстроить цепочку перехватов - cryptopro->vipnet->schannel или vipnet->cryptopro->schannel, как понять кто из первых двух должен обрабатывать гостовые шиферсьюты? Они же одинаковые. И алгоритмы в них одинаковые, и называются они одинаково. Т.е. TLS соединение должен строить кто-то один, а кто именно? До того как мы не получим первый ответ от сервера, мы не знаем что будет односторонка или двусторонка, следовательно мы не можем предугадать будет использован сертификат или нет. А может вообще будет не ГОСТ, а RSA. Что потом делать с этим незакончившимся хэндшейком? Просто отдать его schannel не получится, контент всех сообщений хэшируется и хэш не сойдется (алгоритмы хэширования вообще разные). Фейлить соединение? Тогда надо заставить клиентскую часть прокрутить хэндшейк заново, она то не знает какая там кухня за SSPI происходит, для неё это просто фейл. И это до самих CSP провайдеров дело ещё не дошло, ну только хэш. Кто из двух провайдеров должен его считать?

Здесь сам факт работы гостового TLS в качестве системного напару с schannel уже можно считать победой. Технически, конечно, можно их заставить работать вместе, но это огромная работа, которой должен заниматься не кто-то один, а обе компании вместе (плюс если еще и третьи и четвёрные захотят). И эту работу должен кто-то оплачивать и координировать. Здесь уже не технические сложности, а должно решаться на уровне бизнеса. А на уровне бизнеса, имхо, полезность этой всей работы сомнительна.