Thursday
Feb102005
.NET HTTPS Security
Thursday, February 10, 2005 at 9:29PM
Did you ever get this exception when using HTTPS?
System.Net.WebException: The underlying connection was closed: Could not establish trust relationship with remote server.
This usually happens on a client calling a secure web service with a custom user generated certificate. Did you write this code to solve the problem?
So now you’ve made this HTTPS transport security insecure and susceptible to a man-in-the-middle attack. If you compare this with an Internet Explorer dialog box, it’s basically clicking yes to every security alert. If you search for ICertificatePolicy on the web, you’ll find many results showing the same insecure code (including Microsoft support). Two popular options to maintain HTTPS security are to either import the web server’s certificate or root certificate to the client machine’s trusted certificates store, or verify the public key byte[] returned from the certificate.GetPublicKey() method. If you verify the issuer name, you’re wasting CPU cycles.
To demonstrate how easy it is for someone to view your HTTPS conversation between your client and server, download Cain. With this software, you target your client's IP Address with ARP poisoning, and essentially become the man-in-the-middle. So Cain’s pretty cool in the sense it will download the public key from the real server and create another public/private key that looks just like the real one (other than the fact that it has a different public key). After it does this, your client establishes a HTTPS connection with Cain – and it has no idea. The DNS, the IP Address; everything looks great. Cain has a HTTPS connection with the real server – and the fun begins. All that’s required are a couple of clicks in Cain. If this wasn't a security issue it would be really funny since you've established a secure connection with the hacker! Did you realize these tools are so sophisticated?
Click here for an example (at the bottom of the post) that shows how to securely verify a server's certificate.
System.Net.WebException: The underlying connection was closed: Could not establish trust relationship with remote server.
This usually happens on a client calling a secure web service with a custom user generated certificate. Did you write this code to solve the problem?
public class TerribleCertificatePolicy : System.Net.ICertificatePolicy {
public bool CheckValidationResult(ServicePoint sp, X509Certificate cert, WebRequest req, int problem) {
return true;
}
}
...
System.Net.ServicePointManager.CertificatePolicy = new TerribleCertificatePolicy();So now you’ve made this HTTPS transport security insecure and susceptible to a man-in-the-middle attack. If you compare this with an Internet Explorer dialog box, it’s basically clicking yes to every security alert. If you search for ICertificatePolicy on the web, you’ll find many results showing the same insecure code (including Microsoft support). Two popular options to maintain HTTPS security are to either import the web server’s certificate or root certificate to the client machine’s trusted certificates store, or verify the public key byte[] returned from the certificate.GetPublicKey() method. If you verify the issuer name, you’re wasting CPU cycles.
To demonstrate how easy it is for someone to view your HTTPS conversation between your client and server, download Cain. With this software, you target your client's IP Address with ARP poisoning, and essentially become the man-in-the-middle. So Cain’s pretty cool in the sense it will download the public key from the real server and create another public/private key that looks just like the real one (other than the fact that it has a different public key). After it does this, your client establishes a HTTPS connection with Cain – and it has no idea. The DNS, the IP Address; everything looks great. Cain has a HTTPS connection with the real server – and the fun begins. All that’s required are a couple of clicks in Cain. If this wasn't a security issue it would be really funny since you've established a secure connection with the hacker! Did you realize these tools are so sophisticated?
Click here for an example (at the bottom of the post) that shows how to securely verify a server's certificate.
Reader Comments (1)
Cain is a very interesting tool. Just imagine if you got this going and started to capture all the packets with ethereal, you could get some very interesting data.