555701 - Implement domain restrictions for SSL at Mozilla level (not NSS)

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Kai Engert (:KaiE:)]

It has been discussed that application level trust of certificates could be individually restricted to top level domains (TLDs), for example, government roots could be restricted to issue certificates using the respective country TLDs.

I've worked on an initial proof-of-concept implementation, which I'll attach to this bug.

As a test, I've restricted CA "Equifax Secure CA" to the ".com" TLD.
With the patch applied, you can test using the following sites:
- allowed: https://www.geotrust.com/assets/images/geotrust_logo.gif
- forbidden: https://kuix.de/moz.gif

It reuses the existing error category "domain mismatch".
It uses domain restrictions embedded in source code.

Should we decide to add this functionality to core Mozilla, the following enhancements will be necessary on top of the initial patch:

- individualize the error messages, in order to distinguish
  the classic "domain mismatch" from a "CA domain restriction violation"

- make it possible for the user to edit the list of allowed/restricted
  TLDs (empty list = no restrictions).
  This could be done in the existing cert manager, by extending the
  "edit trust functionality".
  In addition to today's three trust bits, a list of TLDs could be shown,
  where entries could be added and removed.

- potentially enhance the performance, use hashtables for lookups
  instead of the current nested loops of quadratic complexity

Comment 1

[Kai Engert (:KaiE:)]

Attachment: Patch v1

Comment 2

[Kai Engert (:KaiE:)]

Note the implementation is not limited to TLDs, any level of domains could be specified, as a simple "search from right" test is being used to find successul matches. For example a CA could be restricted to issue certs for ".co.uk" etc.

Comment 3

[Matt McCutchen]

Hm, this sounds a lot like bug 501697.  Some comments:

- The right error would be SEC_ERROR_CERT_NOT_IN_NAME_SPACE, the same one returned by name constraints.

- It would be nice to reuse the DNS name constraint logic in NSS, which is slightly smarter than a suffix comparison: an allowed domain of "mozilla.org" matches "mozilla.org" and "bugzilla.mozilla.org" but not "foomozilla.org".  The constraint could be checked either against the hostname being used, as the existing patch does, or against all hostnames on the certificate, as a name constraint on the certification path would be.  The latter approach has the downside of returning more errors that are irrelevant to the connection at hand.

Comment 4

[Kai Engert (:KaiE:)]

reassign bug owner.
mass-update-kaie-20120918

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

We have the ability to enforce name constraints on root certificates, so I don't think there's anything more to do here.