On 04/11/2016 15:42, Hanno Böck wrote:
On Fri, 4 Nov 2016 14:09:55 +0100
Jakob Bohm <[email protected]> wrote:
* How do we allow organization internal non-public CAs to not reveal
their secret membership/server lists to public CT systems or
otherwise run the (administratively and technically) expensive
processes required of public CAs. For example many medium or large
companies have in-house CAs issuing certificates for communicating
with their internal servers, VPNs, extranets etc. Such internal CAs
may very from primitive off-line CAs (no online active components
such as OCSP responders or CT loggers) to off-the-shelf enterprise CA
packages such as Microsoft Windows Server Certificate Services, xca
or EJBCA.
* How do we prevent public CAs from misusing the exceptions for
private CAs?
Isn't that already solved?
Browsers already treat manually installed roots differently, e.g.
bypassing key pinning. Chrome's CT requirements don't apply to locally
installed roots.
This seems to be the obvious solution. CT is there to have transparency
of certificates by the browser-accepted CAs. If you have your own CA
that souldn't be touched by that at all.
Sometimes the people designing implementations forget about this use
case and do things that are bad in that context. For example it is
routine (actually required) for public CAs to have working OCSP servers
and report revoked certificates to services such as Mozilla OneCRL.
But it is very difficult for a small scale in-house offline CA to do
either, while trivial to publish a short regular CRL on an existing
internal HTTP server next to the document listing this weeks lunch menu
and the employee handbook.
(By the way I always found the "secret server name" idea wrong and I
would generally recommend against local CAs in almost all cases. It
adds a lot of complexity and I assume it often creates more problems
than it solves.)
Think of it this way:
90%+ of all the worlds computers are not public servers, they are
workstations, file servers, printers, firewalls, databases, phones etc.
etc. Many of those may have certificate protected interfaces such as
management web pages, encrypted mail/news services, certificate based
IPsec etc. etc.
Many general computer management and/or server suites contain the logic
to fully or almost fully automate the handling of certificate issuance
and use for those servers. Microsoft Windows Server is one such
"suite" that has the whole thing built in and can use it to secure
internal network traffic.
The very name/existence of a server may reveal confidential information
(besides being a target of outside network attacks). Imagine if
someone had spotted the name "development.webbrowser.google.com" in a
CT log before Chrome was publicly announced.
While keeping the existence of something secret is no substitute for
actually protecting it, it is often a reasonable first layer of
defense, leaving much less work for the actual defensive measures to
handle. It can mean the difference between getting hit by 200 script
kiddies / day and 10 script kiddies / day, making it easier to spot
serious attacks, and requiring less CPU and bandwidth resources to
deflect and log that background noise.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
