2010-12-01 2 views
4

Представьте себе, что мы используем классическую асимметричную подписку с WCF (пары частных/открытых ключей). Очевидно, что это безопасно, пока закрытые ключи не будут украдены. Нам не нужны цепи доверия между ключами, не так ли? Клиент должен знать только открытый ключ своего сервера и наоборот.Можно ли использовать самозаверяющие сертификаты с WCF?

Проблема возникает только в том случае, если клиент не знает открытого ключа сервера заранее и получает его при первом доступе. Здесь мы рискуем, что фактический сервер - это «человек в середине», а не реальный сервер. Здесь нам нужны сертификаты. Клиент обращается к серверу, получает его сертификат (который содержит открытый ключ) и проверяет.

Для проверки клиенту необходимо убедиться, что сертификат сервера был выпущен для данного конкретного сервера. И здесь нужны цепи доверия. Правильно?

Если клиент, обращающийся к серверу через WCF с MessageSecurity.Mode = Certificate, заранее известен сертификат сервера (его открытый ключ), можем ли мы сказать, что связь защищена, даже если сертификат самоподписан?

Обычно считается, что использование самоподписанного сертификата не является безопасным и его всегда следует избегать при производстве.
Но почему? Если клиент знает, что ожидаемый открытый ключ затем получает сертификат, он воспринимает его как доверенный (путем сопоставления его открытого ключа с ожидаемым), то он не отменяет того факта, что сервер должен кодировать полезную нагрузку своим закрытым ключом. И шифр может быть успешно расшифрован с помощью кнопочного ключа, если и только если закрытый ключ и открытый ключ были созданы вместе.

Вы видите какие-то недостатки в моих рассуждениях?

Если это правильно, могу ли я быть уверенным, что с помощью пользовательского X509CertifacateValidator и установки ClientCredentials.ServiceCertificate.DefaultCertificate клиентского прокси-сервера для определенного фиксированного (на клиенте) сертификата X509Certificate?

Пользовательские X509CertifacateValidator что-то вроде этого:

public class CustomCertificateValidator : X509CertificateValidator 
{ 
    private readonly X509Certificate2 m_expectedCertificate; 

    public CustomCertificateValidatorBase(X509Certificate2 expectedCertificate) 
    { 
     m_expectedCertificate = expectedCertificate; 
    } 

    public override void Validate(X509Certificate2 certificate) 
    { 
     ArgumentValidator.EnsureArgumentNotNull(certificate, "certificate"); 

     if (certificate.Thumbprint != m_expectedCertificate.Thumbprint) 
      throw new SecurityTokenValidationException("Certificated was not issued by trusted issuer"); 
    } 
} 
+0

Я думаю, что это больше связано с доверием, а не с безопасностью. Сертификатам из центра сертификации (CA) доверяют, например, если FF или IE браузер покажет зеленую полосу, если они доверяют CA, который подписал ваш сертификат. (Geotrust или Verisign) Создавая собственный сертификат и сохраняя секретный ключ, он должен быть в порядке, но может ли 256-битный сертификат VeriSign быть более безопасным, чем собственный 256-битный сертификат? Полезными вещами, которые может сделать CA, является отзыв сертификатов. В этом случае клиент может проверить с помощью ЦС, чтобы убедиться, что сертификат по-прежнему действителен. – 2010-12-01 17:58:36

ответ

6

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

Один из способов решения этой проблемы - создать собственный самозаверяющий сертификат, который будет использоваться в качестве сертификата ЦС. Используйте этот сертификат, чтобы подписать сертификат сервера и поместить информацию об отзыве в сертификат ЦС. Затем добавьте сертификат CA как доверенный на стороне клиента и выполните проверку сертификата сервера на этот сертификат ЦС, а также проверьте отзыв. Это означает, что вам придется либо публиковать CRL на каком-то (возможно, частном) веб-сервере, либо запустить ответчик OCSP.

+0

+1 - Я думал то же самое, но не на 100% уверен.Также я думаю, что некоторые алгоритмы генерации сертификатов лучше других? Также увеличение размера ключа может привести к тому, что некоторые сертификаты станут более безопасными. под этим я подразумеваю, что уходит гораздо дольше, чтобы угадать ключ. – 2010-12-01 18:04:22

Смежные вопросы