Re: [TLS] Verifying X.509 Certificate Chains out of order

[[e-mail] (Peter Gutmann)]

Nelson B Bolyard <[e-mail]> writes:

>This change caused a LOT of users to begin to have a very different user
>experience with their browsers and MUAs.  Requests for client certs were
>apparently MUCH more common and wide spread than we had previously known.

Actually I should provide some $0.02 on that: I agree that requests for client
certs are more common than you'd think, however many sites will request a
client cert whether they need it or not.  I ran into this problem some time
ago, since client cert requests were expected to be fairly rare I'd made them
an exception condition, which caused lots of user complaints when they started
encountering sites that always asked for client certs.  A (very brief) survey
of some admins at some of the known sites that did this yielded the equivalent
of a giant shoulder-shrug from the site admins, they didn't even know that
their servers were doing this and had no idea what to do with the certs even
if they'd been sent them.  They were also (in most cases) unaware of how to
disable the behaviour in the servers.  So I changed my code to just reply with
a no-op no-cert response and the user complaints went away.

Sorry, I'd forgotten about this bit of history trivia, but your comment just
brought it to mind.  Here's the code comment covering handling of server cert
requests:

  We don't really care what's in the cert request since the contents are
  irrelevant, in a number of cases servers have been known to send out
  superfluous cert requests without the admins even knowning that they're
  doing it, in other cases servers send out requests for every CA they know of
  (150-160 CAs) which is pretty much meaningless since they can't possibly
  trust all of those CAs to authorise access to their site.  Because of this,
  all we do here is perform a basic sanity check and remember that we may need
  to submit a cert later on.

  Although the spec says that at least one CA name entry must be present, some
  implementations send a zero-length list, so we allow this as well.  The spec
  was changed in late TLS 1.1 drafts to reflect this practice.

So that provides some more insight into why I treat cert requests the way I
do.

>- Client certs are requested in EVERY handshake.
>[...]
>- If the server receives a client certificate that it does not recognize
>  as being authorized to authenticate any user, instead of ignoring the
>  cert, and going on to request authentication using one of the other
>  methods (e.g. user name and password), it drops the connection, usually
>  without sending any alert.

Hmm, that's new, the behaviour I saw was that the servers always asked for
certs but when sent a no-cert response they continued as normal.  What you're
seeing could just be a variant of the same broken behaviour, only now the
server does a bit more checking and fails on the cert it doesn't know it's
asked for rather than just ignoring it.

>The MTA administrators are generally unaware of client authentication. They
>are unaware that they have the ability to associate a certificate with each
>user account, thereby allowing the cert to be used in lieu of name and
>password Identification and authentication.  They have no way to change the
>behavior of their MTA server product.  Therefore, they perceive the
>unfortunate MUA user experience to be an MUA bug, not an MTA server bug.

Been there, done that.  This situation is a real mess, there's such a random
jumble of broken behaviour around client certs that you can't really rely on
anything working the way it should.  The reason I mostly turned the client
cert request into a no-op was based on a quick user survey, they didn't want
to be bothered with noise from the server, and just sending the cert if there
was one present was deemed acceptable.  So my code currently does:

if( cert request from server )
  ignore CA name list but record that a cert was requested;

[...]

if( cert was requested by server )
  if( user cert present )
    send cert, etc;
  else
    send no-cert response;

This dropped the negative user responses back almost to nothing, so that's
what I've stuck with so far.

Peter.
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls