CMPWG Jun-20-2013:

Agreed. Test cases have been revised. Test-scripts will follow.

Reading section 6.7.6 of part 6 of the spec, I cannot find any passage that says that Bad_SecurityChecksFailed would be the only error code that should be returned by OpenSecureChannel in case of certificate errors. This part is very unclear regarding to the order of the verification steps and should be clarified.

For me, the sentence 'The receiver shall report the appropriate error if Certificate validation fails.' tells me (as a server) to return the appropriate error code to the client if verification fails - not the general Bad_SecurityChecksFailed.

Also, in case the spec should be interpreted this way, table 8 of part 4 would contradict part 6, as there are specific error codes like Bad_CertificateHostNameInvalid or Bad_CertificateTimeInvalid shown as service result codes specifically for OpenSecureChannel. If these should not be used, all specific error codes have to be removed from this table.

From my point of view, the steps are as follows:

• Verifiying that the SenderCertificate is a proper X509 certificate
  -> if not, Bad_CertificateInvalid

• Decrypting the message
  -> if not, Bad_SecurityChecksFailed

• Verifying the signature
  -> if not, Bad_SignatureInvalid

• Check if the certificate is trusted at all
  -> if not, Bad_CertificateUntrusted

• Check URI, Hostname, Expiration, Revocation etc.
  -> if not, specific error code

The argument for not returning any specific error codes is that a hacker would be helped creating a valid certificate to connect to the server which he is not supposed to do.

But if a hacker gets as far as having the server trust his certificate (either by having his certificate signed by a CA that is trusted by the server, or by putting his certificate to the server's trust list), I think he would be clever enough to get the expiration date of his certificate right, even if the server just returns a general error code.

Thus, this would just be security by obscurity, adding no additional security at all. Also, this hides helpful error messages from clients that could use these messages to help a user decide what to do in case of a problem.

All other applications using X509 certificates return specific errors, hence the "obscurity" pushes UA in the same direction like DCOM, where unclear error messages lead to misconfiguration and frustration, without adding any additional security at all. All information in a public certificate is public, hence reporting errors about its content is no security hole.

The issue that we need to protect against are errors that would allow an attacker to use trial and error to discover keys by changing the message slightly and look for a change in error codes (an HTTPS exploit based on using error codes exists).

It is hypothetically possible for an attacker to create specially formed certificates to find holes. For that reason I not comfortable returning different errors that could occur when an hacker is probing the server with different constructed certificates.

The one exception I would make is once the Server knows the certificate is trusted (i.e. it cannot be constructed by a hacker) then error codes can be returned as normal. If we could require that trust be checked before the other certificate checks then the other errors can be returned but that not the way the stacks work now.

I would agree with Hannes comments from 6/25/2013.

Should we punish the end-user with an error that's the equivalent to "an error has occurred". The end-user will be using the system 99.9999999% (or more) of time? My vote would be "no".

However, Part 6 does state the behavior that Randy describes and that's the reason why we (CMPWG) have reluctantly revised the test-cases.

We definitely should be mindful of security, but this behavior (in part 6) will very likely turn out to create a LOT of headache as end-users complain to their vendors when products don't talk and the user can't figure out why because of an overly generic error code.

This issue should be moved to Part 6 where the UA WG can talk about changing the spec to specifically require certificate related errors.

There already are servers on the market (using the AnsiC stack) that have the behaviour described:

1. Check for structurally valid certificate
2. Check if certificate is trusted
3. Check expiration, URI, hostname etc.

This is why the CTT tests should at least allow a server to return the more specific error codes instead of Bad_SecurityChecksFailed, as security is given by the order of processing the certificate validation.

Recommended change:

1) No change for symmetric keys
2) For asymmetric keys require that trust be checked first
3) Develop a CTT test that verifies that trust is checked first.
4) Return BadSecurityChecksFailed for trust error, a error that prevents trust from being checked or any other problem decrypting or verifying the message.
5) Return other certificate error codes when appropriate (expired).

BadCertificateRevoked is returned if the certificate would otherwise be trusted.
BadCertificateInvalid is not returned because it prevents trust from being checked.

Fixed, awaiting release. Will close issue once officially released.