Using Trusted Public Keys in SSL Connections

摘要

In The Microsoft .NET Framework, it's possible for unauthorized third parties to gather information about SSL connections that your client code makes to remote secure servers. Among other things, the public key of the remote server can be examined. It is commonplace in non-Windows environments for the identity of remote servers to be determined not by an arbitrary certificate chain rooted at any one of dozens of trusted root Certifying Authorities (CA) who can issue trusted certificates, but based instead on a particular public key that is known to belong to a remote server. Any change of public key, even with the same or similar certificate chain, represents a severe security risk because the only symptom of a well-executed man-in-the-middle (MITM) or spoofing attack against an SSL-based system will be a change of public key offered by the server, along with the certificate chain that allegedly proves the trustworthiness of the server's identity. There are any number of ways for an attacker to gain control over a certificate chain and key pair that will validate against the assortment of root CA certificates trusted by default in Windows. Only by fixing trust on a particular known-good public key can important SSL-based communications safely authenticate the identity of a trusted remote server. This article shows how to add this critically important security countermea-sure to your client-side SSL code so that an attacker will be unable to mount an MITM or spoofing attack at the server side unless the attacker can steal the authentic server's key pair, succeed in the difficult task of breaking SSL cryptographic algorithms through cryptanalysis, or exploit a software bug that compromises the entire process.