Client certificate auth - моментально 403 Forbidden

[shadow7256]

Еще больше пронюхал.. вижу запрос от сервера, где он просит клиента предоставить клиентский сертификат.

HTTP/2 standard has no implementation for client certificate authentication.

верно, и поэтому мы видим в пакетах, кто сервер просит клиента переключится на HTTP 1.1 и клиент переключается на HTTP 1.1

[shadow7256]

Ну вот и разобрались что проблема на стороне клиента

проблема на стороне клиента, это 100 процентов.

[shadow7256]

Чего то Вы запутали совсем. Насколько я понял у Вас была проблема с С# клиентом а теперь Вы говорите про браузер. В браузере окошко выбора сертификатов может не появляется по причине security settings на самом браузере. В C# скорее всего другая проблема и я давно посоветовал Вам SSL логи включить.

я сам сильно зае..ся решать эту проблема, потому как в этом гребаном банке никто ни за что толком не отвечает, но хотят иметь 100% bullet proof решение.

Я сделаю простое клиентское приложение на С# и посмотрю что мне сервер выдаст.

С браузером согласен, что это скорее всего настройки браузера.

[kostik78]

Чего то Вы запутали совсем. Насколько я понял у Вас была проблема с С# клиентом а теперь Вы говорите про браузер. В браузере окошко выбора сертификатов может не появляется по причине security settings на самом браузере. В C# скорее всего другая проблема и я давно посоветовал Вам SSL логи включить.

я сам сильно зае..ся решать эту проблема, потому как в этом гребаном банке никто ни за что толком не отвечает, но хотят иметь 100% bullet proof решение.

Я сделаю простое клиентское приложение на С# и посмотрю что мне сервер выдаст.

С браузером согласен, что это скорее всего настройки браузера.

С клиентом обычно все просто: даёшь клиентский сертификат и приватный ключ. Если обе стороны знают сертификаты то все должно работать. Правда я тут порылся в инете и выглядит так, что в винде какой то дополнительный уровень секьюрити накрутили. Нашёл что народ утверждает что инсталлированный self-signed cert в store может быть виндой помещённый в black list и не давать его использовать. Насколько это правда не знаю - с виндой не работал давно (по моему последняя была Windows XP)

[shadow7256]

С клиентом обычно все просто: даёшь клиентский сертификат и приватный ключ. Если обе стороны знают сертификаты то все должно работать.

у нормальных людей да, все работает. Но только не в этом гребаном банке.

Правда я тут порылся в инете и выглядит так, что в винде какой то дополнительный уровень секьюрити накрутили. Нашёл что народ утверждает что инсталлированный self-signed cert в store может быть виндой помещённый в black list и не давать его использовать. Насколько это правда не знаю - с виндой не работал давно (по моему последняя была Windows XP)

с self signed сертификатами да, могут быть проблемы. Но мы используем нормальный сертификат, правда подписанный самим банком. У них политика такая, все сертификаты выпускают только они сами.

[Palych]

Когда всё это заработает, решится кто-нибудь подставить неправильный сертификат, чтобы убедиться что система защищена от несанкционированного доступа?

[kostik78]

Когда всё это заработает, решится кто-нибудь подставить неправильный сертификат, чтобы убедиться что система защищена от несанкционированного доступа?

Не понятен Ваш скептицизм. Я построил не одну систему где сервисы (как шас принято называть микросервисами) использовали mutual cert auth и авторизация привелегий определялась самим конечным сертификатом через extension. Данные системы работают и довольно безопасны если сделаны верно

[VovaK98]

Тут мне не особо понятно, кто виноват-клиент или сервер. Или вообще версия фреймворка.
На опыте- либо надо поднять клиента до TLS 1.2, тогда в исходнике где-нить наверху надо добавить вот это:

Code: Select all

const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12;

или если клиент некомпиляемый, тогда в app.config клиента вписать вот это:

Code: Select all

<configuration> 
<startup> <supportedRuntime version="v4.0"/> </startup> 
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/> </runtime> 
</configuration>

[shadow7256]

Тут мне не особо понятно, кто виноват-клиент или сервер. Или вообще версия фреймворка.
На опыте- либо надо поднять клиента до TLS 1.2, тогда в исходнике где-нить наверху надо добавить вот это:

Code: Select all

const SslProtocols _Tls12 = (SslProtocols)0x00000C00;
const SecurityProtocolType Tls12 = (SecurityProtocolType)_Tls12;
ServicePointManager.SecurityProtocol = Tls12;

или если клиент некомпиляемый, тогда в app.config клиента вписать вот это:

Code: Select all

<configuration> 
<startup> <supportedRuntime version="v4.0"/> </startup> 
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/> </runtime> 
</configuration>

Обмен данными происходит через TLS 1.2. Написал простой код:

Code: Select all

X509Certificate2 certificate = GetX509Certificate (certThumbprint);

 HttpClientHandler handler = new HttpClientHandler
 {
        ClientCertificateOptions = ClientCertificateOption.Manual,
        SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls11 | SslProtocols.Tls
 }; 

 handler.ClientCertificates.Add(certificate);

 HttpClient request = new HttpClient(handler);

 try
 {
         var result = request.GetAsync(url).Result;
         string resultContent = result.Content.ReadAsStringAsync().Result;

         Console.WriteLine($"Response: {resultContent}");
  }
  catch (Exception ex)
  {
        Console.WriteLine($"Exception while calling: {url}. Error: {ex.GetaAllMessages()}");
 }

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

Exception while calling: {url}. Error: One or more errors occurred while sending the request

[Palych]

Когда всё это заработает, решится кто-нибудь подставить неправильный сертификат, чтобы убедиться что система защищена от несанкционированного доступа?

Не понятен Ваш скептицизм. Я построил не одну систему где сервисы (как шас принято называть микросервисами) использовали mutual cert auth и авторизация привелегий определялась самим конечным сертификатом через extension. Данные системы работают и довольно безопасны если сделаны верно

То что системы работают - понятно.
А как Вы определяете что они довольно безопасны?

По поводу моего скепцитизма.
Давайте посмотрим правде в глаза:
Имеется инженер, достаточно грамотный вроде бы.
Он пытается решить элементарную проблему: почему система не пускает того, кто имеет право ей пользоваться.
Для этого он нюхает пакеты, взывает к помощи клуба...
И это не потому что он тупой. Система не предоставляет адекватных средств диагностики.
Имеем классический случай слишком сложного замка: рано или поздно дверь подопрут табуреткой.

К тому же упоминание "нормальных, не самоподписанных сертификатов" делает меня думать что в системе уже проделана дырка, и любой сертификат подписанный CA этого банка предоставит доступ к системе.

[Palych]

Случай из жизни:
Подключались мы к такому сервису. Сервис был в процессе разработки.
Как обычно, тестировали без всяких изотопов, а mutual authentication нашлепнули за неделю до релиза.
У нас заработало, у другого клиента - нет.
Главный инженер проекта покумекал немного, и принял соломоново решение:
Поскольку server authentication работает - система достаточно безопасна. Клиентов аутентифицировать не будем.

[kostik78]

Когда всё это заработает, решится кто-нибудь подставить неправильный сертификат, чтобы убедиться что система защищена от несанкционированного доступа?

Не понятен Ваш скептицизм. Я построил не одну систему где сервисы (как шас принято называть микросервисами) использовали mutual cert auth и авторизация привелегий определялась самим конечным сертификатом через extension. Данные системы работают и довольно безопасны если сделаны верно

То что системы работают - понятно.
А как Вы определяете что они довольно безопасны?

Определяю не я а время (то бишь хакеры) и penetration testing который требуется каждый год для прохождения разных аудитов.

Про допуск любого сертификата подписанного банка это как сделать authorization part. Да все сертификаты определенного chain будут проходить authentication но будут ли все сертификаты данной цепочки проходить authorization это уже вопрос дизайна сервера(сервиса)

[kostik78]

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

Exception while calling: {url}. Error: One or more errors occurred while sending the request

Включили бы Вы уже логи и давно бы разобрались

[Мальчик-Одуванчик]

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

А у этих двух машин полные доменные имена сильно отличаются?

[shadow7256]

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

Exception while calling: {url}. Error: One or more errors occurred while sending the request

Включили бы Вы уже логи и давно бы разобрались

Так где эти логи включить то.

[shadow7256]

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

А у этих двух машин полные доменные имена сильно отличаются?

У каких "двух" машин?

"Проблемный" клиент и сервер находятся в одной подсети, между ними нет никакого firewall. На клиенте запускаю tracert до сервера и выдает сразу первый же hop это hop сервера.

Повторюсь, как только я отключаю на сервере клиентскую аутентификацию, то все работает без проблем. Как только включаю ее, то начинается эта проблема. Вот код запуска сервера (self hosted API):

Code: Select all

 var config = new HttpsSelfHostConfiguration(uri);
 
config.Formatters.XmlFormatter.UseXmlSerializer = true;
 
config.MaxReceivedMessageSize = int.MaxValue;
 
config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
                
config.ClientCredentialType = HttpClientCredentialType.Certificate; // вот тут вкл/выкл требование клиентского сертификата

var server = new HttpSelfHostServer(config);
server.OpenAsync().Wait();

[shadow7256]

Про допуск любого сертификата подписанного банка это как сделать authorization part. Да все сертификаты определенного chain будут проходить authentication но будут ли все сертификаты данной цепочки проходить authorization это уже вопрос дизайна сервера(сервиса)

все абсолютно верно, но дело даже не в авторизации, сейчас хер с ней.

Судя по всему, раз сервер пускает запросы с одной машины и не пускает с другой, то наверное проблема где то на машине, с которой не пускает. А вот что за проблема непонятно.

[kostik78]

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

Exception while calling: {url}. Error: One or more errors occurred while sending the request

Включили бы Вы уже логи и давно бы разобрались

Так где эти логи включить то.

Это видели ? https://stackoverflow.com/questions/597 ... webrequest

Взглянул быстро вроде бы как раз логи включает

[shadow7256]

запускаю на одной машине - все ОК. Запускаю на другой - проваливаемся в catch и видим

Exception while calling: {url}. Error: One or more errors occurred while sending the request

Включили бы Вы уже логи и давно бы разобрались

Так где эти логи включить то.

Это видели ? https://stackoverflow.com/questions/597 ... webrequest

Взглянул быстро вроде бы как раз логи включает

ух ты, спасибо, подключил лог этот. В понедельник отдам индусу новую версию, пусть запускает с логами. Буду надеятся что покажет проблему.

[Мальчик-Одуванчик]

У каких "двух" машин?

У проблемного и беспроблемного клиентов.

[shadow7256]

У каких "двух" машин?

У проблемного и беспроблемного клиентов.

В понедельник узнаю.

[Palych]

Про допуск любого сертификата подписанного банка это как сделать authorization part. Да все сертификаты определенного chain будут проходить authentication но будут ли все сертификаты данной цепочки проходить authorization это уже вопрос дизайна сервера(сервиса)

Что-то мне подсказывает что авторизация там сделана через добавление/удаление сертификатов в trust store.

[Oleg-NY]

ИМХО, вам надо бы разобраться что именно верифицируется сервером в отношении клиента на основе предоставленного сертификата.
Обычно HTTPS сервера не проверяют host name клиента, но технически это возможно.
Как известно, если этого не делать, что MITM аттака вполне осуществима.

[shadow7256]

ИМХО, вам надо бы разобраться что именно верифицируется сервером в отношении клиента на основе предоставленного сертификата.
Обычно HTTPS сервера не проверяют host name клиента, но технически это возможно.
Как известно, если этого не делать, что MITM аттака вполне осуществима.

Мне сейчас важно понять почему один и тот же сервер работает по разному с двумя разными клиентами. Сертификат везде стоит один и тот же, и на сервере и на клиентах. Сертификат валидный и не просроченный.
В одном случае сервер возвращает ответ в другом случае возвращает 403. В понедельник включу трейсинг и посмотрю что происходит.

[kostik78]

ИМХО, вам надо бы разобраться что именно верифицируется сервером в отношении клиента на основе предоставленного сертификата.
Обычно HTTPS сервера не проверяют host name клиента, но технически это возможно.
Как известно, если этого не делать, что MITM аттака вполне осуществима.

При mutual auth когда сертификаты сверяются с обоих сторон MITM не возможен в принципе ибо для этого потребуется знать приватные ключи и сервера и клиента