Testing Techniques to Find the Sin

Right now, there are several tools that will automate a man-in-the-middle attack against HTTPS, including dsniff and ethercap. These tools only work against HTTPS, though, so when theyre used against an HTTPS-compliant application, they should always throw up dialog boxes or otherwise signal an error, or else it represents a serious problem in the underlying infrastructure.

Unfortunately, the only robust tools for automating general-purpose MITM attacks against SSL applications exist in the hacker underground . If such a tool were available, you would start by giving it a valid certificate signed by a known CA, such as VeriSign, and seeing if the tool could decrypt protocol data. If it could, then full certificate validation isnt being performed.

To test for CRL checking and OSCP responders, you can simply observe all network traffic coming out of an application for an extended period of time, checking destination protocols and addresses against a list of known values. If OCSP is enabled, there should be one OCSP check for every authentication. If CRL checking is enabled and properly implemented, it will occur periodically, often once a week. So dont be surprised if your code performs a CRL check and you see no network traffic when performing the check, because the CRL may have already been fetched and cached, making a network hop unneeded.