Kann die Verwendung selbstsignierter Zertifikate mit WCF sicher sein?

Question

Stellen Sie sich vor, wir verwenden klassische asymmetrische Beschreibung mit WCF (private/public key pairs). Offensichtlich ist es sicher, bis private Schlüssel nicht gestohlen werden. Wir brauchen keine Vertrauensketten zwischen Schlüsseln, richtig? Der Client muss nur den öffentlichen Schlüssel seines Servers kennen und umgekehrt.

Ein Problem tritt nur auf, wenn der Client den öffentlichen Schlüssel des Servers nicht im Voraus kennt und ihn beim ersten Zugriff erhält. Hier besteht die Gefahr, dass der eigentliche Server ein "Man-in-the-Middle" anstelle des realen Servers ist. Hier brauchen wir Zertifikate. Der Client greift auf einen Server zu, erhält sein Zertifikat (das den öffentlichen Schlüssel enthält) und validiert es.

Für die Validierung muss der Client sicherstellen, dass das Serverzertifikat für diesen bestimmten Server ausgestellt wurde. Und hier brauchen wir Vertrauensketten. Recht?

Wenn ein Client über WCF mit MessageSecurity.Mode = Zertifikat auf das Serverzertifikat (seinen öffentlichen Schlüssel) zugreift, können wir sagen, dass die Kommunikation sicher ist, selbst wenn das Zertifikat selbstsigniert ist?

Normalerweise wird angenommen, dass die Verwendung von selbstsignierten Zertifikaten nicht sicher ist und in der Produktion immer vermieden werden sollte.
Aber warum? Wenn der Client den erwarteten öffentlichen Schlüssel kennt, erhält er ein Zertifikat, behandelt es als vertrauenswürdig (indem es seinen öffentlichen Schlüssel mit dem erwarteten übereinstimmt) und bricht dann nicht die Tatsache ab, dass der Server Nutzlast mit seinem privaten Schlüssel verschlüsseln muss. Und die Chiffre kann mit pulbic key genau dann entschlüsselt werden, wenn der private Schlüssel und der öffentliche Schlüssel zusammen erstellt wurden.

Können Sie irgendwelche Fehler in meiner Argumentation sehen?

Wenn es korrekt ist dann kann ich sicher sein, dass mit einem benutzerdefinierten X509CertifacateValidator und ClientCredentials.ServiceCertificate.DefaultCertificate des Client-Proxys zu einigen festen (auf dem Client) X509Certificate sicher?

Individueller X509CertifacateValidator ist so etwas wie diese:

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"); 
    } 
} 

Answer 1

Ja, Ihr Verständnis ist richtig, aber es fehlt eine Sache - die Dinge im Laufe der Zeit ändern. Wenn der private Schlüssel des Servers offengelegt wird oder das Zertifikat des Servers auf andere Weise ungültig wird (was auch immer), bietet PKI den Mechanismus für die Sperrung und Sperrung von Zertifikaten an. Mit selbstsignierten Zertifikaten ist dies nicht möglich (zumindest ohne Erstellung einer benutzerdefinierten PKI-Infrastruktur).

Eine Möglichkeit, dieses Problem zu beheben, besteht darin, ein benutzerdefiniertes selbstsigniertes Zertifikat zu erstellen, das als CA-Zertifikat verwendet wird. Verwenden Sie dieses Zertifikat, um das Serverzertifikat zu signieren und Sperrinformationen in das Zertifizierungsstellenzertifikat einzugeben. Fügen Sie dann das Zertifizierungsstellenzertifikat als vertrauenswürdig auf der Clientseite hinzu und führen Sie eine Überprüfung des Serverzertifikats für dieses Zertifizierungsstellenzertifikat durch und überprüfen Sie außerdem die Sperrung. Dies bedeutet, dass Sie CRLs entweder auf einem (möglicherweise privaten) Webserver veröffentlichen oder den OCSP-Responder ausführen müssen.