Certificate Validation

In order to ensure that a Digital Certificate is safe to use, it is validated. This validation involves one of the following methods:

• Checking that the certificate is not in a Certificate Revocation List ( CRL).
• Querying the validity of the certificate using the Online Certificate Status Protocol ( OCSP).

Although either of these methods should give a Yes or No answer to whether the certificate is valid or not, the reality is that for a significant number of these validations, the answer is Maybe.

If you want to understand how validation works, a very readable account of what happens when you use SSL for a secure web page in your browser, click here. If you want to understand what happens when these validations fail, read Adam Langley's account here. Hint: The browser most likely ignores the validation failure. If you want to understand how your browser deals with validation, see the SpiderLabs web page here.

So, the key point is that certificate validation (which can be quite strict if you use a tool to analyse the certificate chain) adopts the lowest common denominator (LCD) approach for general use, such as shopping on a secure web site. Part of the reason for this is that if it were strictly enforced, many E-Commerce transactions would fail making both customers and web sites unhappy, and there is no economic motivation to change things.

One of the roots of this problem is that of reconciling machine generated information with the Trust that you can place in a person or organization on the basis of evidence, and allowing sensible interaction between the user and browser when things fail. For example, if there is a validation failure that the person using the browser knows about (the relying party) and this is communicated to the person responsible for the web site, what subsequently happens? If the problem is fixed quickly and communicated back to the relying party, then that person has evidence to gauge trust, and that fix only affects one person. If the problem persists, it might affect many people.

If you cannot rely on a user response to a browser notification (as outlined above), then the machine generated information probably has to make use of short lived digital certificates (see this link for more detail). Usually what happens is trust by proxy. For example, if the Root certificate is on the PC, and by implication trusted, then the remote person or organization can be trusted as well (in the absence of evidence) and if the validation fails, follow a programmed path rather than asking what to do. So the people responsible for the web site probably have little idea that problems are happening unless server logs are regularly scrutinized.

Your secure link to the web site is currently more likely to be protected from compromise (but cannot be guaranteed from, for example, a Man in the Middle attack) because of:

• The Blizzard of browser to web site connections on the Internet. Just like one fish in a school in the ocean is almost invisible to a predator.
• The physical ADSL connection between your PC and your ISP is reasonably secure against un-authorized scrutiny. However, this does depend on the qulaity of staff and the severity of penalty by the appropriate regulator when things go wrong.
• If your secure link to a web site is opened, used, and closed quickly, it is less likely to be noticed.

The last item is important. Don't keep a secure link open for longer than necessary and then close your browser session by closing the browser window. Of course, if your PC is compromised in some way, then all bets are off.