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

RESOLVED WORKSFORME

Status

()

Core
Security: PSM
RESOLVED WORKSFORME
8 years ago
2 years ago

People

(Reporter: kaie, Unassigned)

Tracking

({sec-want})

Trunk
sec-want
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want] [psm-ca-domains])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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
(Reporter)

Comment 1

8 years ago
Created attachment 435598 [details] [diff] [review]
Patch v1
(Reporter)

Comment 2

8 years ago
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

8 years ago
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.
Whiteboard: [sg:want]
(Reporter)

Updated

8 years ago
Whiteboard: [sg:want] → [sg:want] [psm-ca-domains]
(Reporter)

Comment 4

6 years ago
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
We have the ability to enforce name constraints on root certificates, so I don't think there's anything more to do here.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.