Are there really any CAs which issue sub-CA for "deep packet inspection" aka
doing MitM and issue certs on the fly for everything going through them:
gmail, hotmail, online banking etc.
I saw Ondrej Mikle also mentions this concept in his referenced link from
recent post:
https://mail1.eff.org/pipermail/observatory/2011-November/000484.html
- SSL inspection/MitM boxes sometimes show up before being configured
(Blue Coat, SonicWall, Watchguard Fireware)
How do they know you're going to put the cert in a blue coat box and inflict
that only to your employees vs steal banking passwords and money of users in
an airport?
Do blue coat and other MitM proxies mentioned on this list recently actually
support on the fly cert generation and putting a CA cert in there?
I was presuming that to do so they user would have to self-sign a CA cert
and "upgrade" their browsers on their corporate installs by adding their
self-signed MitM cert to the trusted CA set in their standard image/install
set. (Which is obnoxious but fair enough).
But for a CA to intentionally issue an unrestricted sub-CA cert for
installing in MitM boxes - that sounds outright lethal. How much do you
trust the box security, the operators of the box. Do they sell such sub-CAs
to Iran, Syria via shady intermediaries?
What do these sub-CA certs cost? What do I have to say or sign to get one?
Will they sell it to me to monitor my kids? Employees of a small startup?
Adam
On Wed, Nov 30, 2011 at 01:30:40PM -0600, Marsh Ray wrote:
On 11/30/2011 12:01 PM, Ben Laurie wrote:
On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray<ma...@extendedsubset.com> wrote:
Perhaps you define this category of "publicly visible certs" as "certs
which display without warnings on default-configured browsers when
presented by the correct site".
...
On the other hand, one could interpret this category of "publicly
visible certs" as "certs visible to the public", i.e., "certs served by
legitimate servers on routable IPs located via public DNS". But this
interpretation would be much weaker (and I don't think that's what you
mean).
Although I rather like your first definition, this one seems closer to
the truth: it may be that some sites which currently validate
correctly in default-configured browsers would choose not to in our
system.
The certs I am worried about though are the certs that were issued in
secret (e.g. Comodo and friends) and are never "publicly visible"
until they are used in an attack.
If the attack is sufficiently targeted, it may be the case that no
one other than the victim ever sees the cert at all. In the event of
a mass MitM attack (e.g. *.ir), the attacker would likely have free
use of his previously-hidden cert for at least as long as the
combined reporting, reaction, and revocation latency.
It's not clear how this proposal is actually an improvement on the
current system in this regard.
On the other hand, if you *did* engage the CAs and get their buy-in,
they could pledge to update the log promptly with every cert they
issued. Specific CA certs could be configured with this flag in the
browser's trusted store. This would allow a missing audit proof to be
treated as a hard stop and would seem to be a more meaningful
distinction among CAs than the current EV scheme. (The few CAs I've
spoken were really grasping for ways with which the 'better' CAs
could distinguish themselves in the industry.)
Additionally, such a flag could be added to HSTS. Rather than pinning
to a specific CA ("I will only use this one CA ever"), a site could
pin itself to the use of a CA that promised to participate in the
auditing. This would reduce some of the DoS potential inherent in CA
pinning yet still allow browsers to catch that critical transition
from "provably logged cert" to "non-logged cert".
But the proposal does nothing _directly_ to prevent a CA from issuing a
cert, right? And since browsers aren't logging the certs as they find
them, this doesn't inform the owner of the domain either.
Instead it seems to be a hoped-for effect of "default-configured
browsers will raise hell if they are presented with a non-logged cert
and CAs will feel compelled to go along with the audit logging".
CAs do not have to go along with anything, the log will accept a cert
from anyone - which obviously includes the owner of the cert.
There would need to be a way for end-users to report new certs via
their browser, much like they report browser crashes today. Wouldn't
some users want it? I think it would be good to involve the users in
this process as much as is practical.
they'll have to put the certs they
issue in the logs too, right?
Someone will, yes.
Wouldn't they have to put the certs they sign in the public log? They
don't have to do this today.
No, but their certs are already publicly visible today.
I don't believe this is the case. It's one of the big problems with
the system we have today.
Consider a sub-CA which is issed for the purpose of a company's
deep-inspecting firewall (e.g., a BlueCoat). The device will use the
sub-CA to issue new certs on-the-fly for each new website that the
internal network clients browse to. The rest of the world (hopefully)
never sees those certs.
Yet this log of the certs that it has generated is highly
confidential. It contains info about the browsing history of the
entire company, e.g., parts suppliers, financial institutions, use
your imagination.
The current crop of "trusted" CAs refuse to give the names or even
the count of the sub-CAs they've sold. They only require that the
party to which they sell them agree in a contract to use them
accordingly.
I'm all for saying that these sub-CAs need to be put on the boat to
the island of lost toys like the toxic plastic that they are. But I
wouldn't expect the parties that currently enjoy this privilege to go
quietly. :-)
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
