Subject: Re: [certid] Bad certificate handling

From: =JeffH <[email-masked]>
Date: Fri, 24 Sep 2010 12:32:52 -0700

[email-masked] said:
 > On Wed, 2010-09-22 at 09:59 -0600, Peter Saint-Andre wrote:
 > > The part of the text that you have not quoted does say that this
 > > practice is typically offered only to advanced users (and I don't think
 > > that Barry's mother counts as an advanced user). However, we've
 > > provisionally made the text even more scary, as follows:
 > >
 > >       Security Note: Some existing interactive user agents give advanced
 > >       users the option of proceeding despite an identity mismatch.
 > >       Although this behavior can be appropriate in certain specialized
 > >       circumstances, in general it needs to be exposed only to advanced
 > >       users and even then needs to be handled with extreme caution, for
 > >       example by first encouraging even an advanced user to terminate
 > >       the connection and, if the advanced user chooses to proceed
 > >       anyway, by forcing the user to view the entire certification path
 > >       and only then allowing the user to accept the certificate on a
 > >       temporary basis (i.e., for this connection attempt and all
 > >       subsequent connection attempts for the life of the application
 > >       session, but not for connection attempts during future application
 > >       sessions).
 > >
 > > Jeff still needs to review that text before we finalize it.
 >
 > There is a trade-off in making the acceptance temporary.  ...
 >
 > The current remark about temporary acceptance might suggest to readers
 > that it is better than permanent acceptance, which is at best an
 > oversimplification and possibly untrue.  Thus, I propose that the remark
 > be removed.

agreed. Jhutz also suggested such.

 > Separately, I wonder if it makes sense for server-id-check to
 > specifically discuss the handling of certificates that don't match a
 > reference identifier when the considerations are essentially the same
 > for certificates with other problems (most commonly, expired or
 > untrusted issuer) and, indeed, modern browsers tend to provide a single
 > UI for these three most common problems.  I'm not sure where would be
 > the right place to standardize handling of bad certificates in general.
 > There is a W3C document, but it only applies to interactive user agents:
 >
 > http://www.w3.org/TR/wsc-ui/    [WSC-UI]

Which is entitled: "Web Security Context: User Interface Guidelines"

Note that we already cite this doc (tho we need to update our cite because it 
is now a Recommendation).

In any case, this is a good catch, thanks. In reading WSC-UI, it appears to 
overall address our needs for more full explanation of interactive user agent 
behavior in error condition cases (although it doesn't differentiate between 
"pinning" a cert temporarily vs permanently).

Given all this, I suggest we change the last part of the last sentence of the 
"Security Note" quoted above to something like..

        ..., by forcing the user to view the entire certification path
        and only then allowing the user to choose whether to accept the
        certificate on a temporary or permanent basis. See [WSC-UI] for
        further guidance.

..and leave it at that in -tls-server-id-check. We should also consider making 
[WSC-UI] a normative reference now that it is at Recommendation maturity level.

=JeffH

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 24 Sep 2010 17:46:11 -0400

> [WSC-UI] a normative reference now that it is at Recommendation maturity level.

OK.  I suggest s/to choose whether //; the point is that the user
accepts the certificate.

Another issue with WSC-UI that I neglected to point out earlier: it only
discusses pinning of certificates with untrusted issuers, so we should
make explicit that we are recommending that the WSC-UI treatment of
untrusted issuers be applied to name mismatches.  And it's awkward to do
that if the omission of pinning for name mismatches from WSC-UI was
intentional (i.e., the authors thought it was a bad idea).  Does anyone
know if this is case?

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Sat, 25 Sep 2010 02:22:50 +0200 (MEST)

> Which is entitled: "Web Security Context: User Interface Guidelines"

Thanks for providing this link !!

Section 5.1.4 here:

    http://www.w3.org/TR/wsc-ui/#selfsignedcerts

is much closer what I this would be useful and sensible.

"Pinning" of certs is useful for both, certs that validate fine
and certs that do not validate for the two reasons "not trusted"
and "server-id-mismatch".

>         certificate on a temporary or permanent basis. See [WSC-UI] for

What is the idea behind visualizing the full chain?

I've seen the same in 5.1.4 of the WSC-UI document but there's
no rationale given and I can not think of one.  If the purpose is
memorizing and "pinning" a server cert, there is no point in
visualizing the certificate chain.

Either there is no trust, then the chain can be crafted to look
like anything, or it is trusted, then -- well it is trusted and
there is no point (for Joe Average User) in looking at the chain,
because this chain has passed certificate path validation.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 26 Sep 2010 11:21:08 -0400

> and "server-id-mismatch".

Once again
(http://www.ietf.org/mail-archive/web/certid/current/msg00338.html), the
purpose of pinning is to make it possible to connect to servers with
unverifiable certificates, not to replace the public-CA trust model,
which is much more difficult to do properly.  The definition of
"strongly TLS-protected" (http://www.w3.org/TR/wsc-ui/#def-strong-tls)
includes validated certificates regardless of whether there is a pinned
certificate.

> like anything,

Not necessarily.  There are some CAs I don't want to enable
unconditionally as trust anchors, but whose certificates I am willing to
accept after additional manual verification.  In that case, I would
check the fingerprint of the top certificate of the presented chain
against the one I expect.  But you're right that "forcing the user to
view the entire certification path" may have no real security benefit in
general, though it sounds impressive.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Mon, 27 Sep 2010 15:48:26 +0200 (MEST)

> includes validated certificates regardless of whether there is a pinned

"Pinning" Certs is extremely sensible, especially for TOR exit nodes.
Getting a server cert issued from any one of the ~100 pre-trusted CAs
without being rightful owner of a domain is an effort to which you
can likely attach an average price tag.  Find out the procedures
of the CA and determine which is the most cost effective mix of
deceiving about real owner ship and bribe that will achieve the
objective.  Governmental agencies might have additional means of
persuaions to get server certs issued for domains that they do not
own.  Think about wikileaks.

Therefore having server-id-check unconditionally and silently override
"pinned" server certs with server-certs that chain to one of the ~100
trust anchors preconfigured by the software supplier is a significant
security problem.

-Martin

---

From: ArkanoiD <[email-masked]>
Date: Mon, 27 Sep 2010 17:54:19 +0400

I strongly agree and i address this problem in my software (and i guess so should everyone)