Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Benjamin Kreuter]

On Tue, 6 Dec 2011 12:34:37 +0100
Adam Back  wrote:
> Kids figure this stuff out getting through site restrictions on
> school wifi also.  Some schools try to block popular web games.. eg
> runescape.

Let us not discourage either the children or the schools!  This sounds
like an excellent way for children to pick up some technical skills
and to learn about computer security.  If we must condition our
children to think that censorship is the norm, at least we can also
provide them with some decent education in the process.

-- Ben
 


-- 
Benjamin R Kreuter
UVA Computer Science
brk...@virginia.edu

--

"If large numbers of people are interested in freedom of speech, there
will be freedom of speech, even if the law forbids it; if public
opinion is sluggish, inconvenient minorities will be persecuted, even
if laws exist to protect them." - George Orwell


signature.asc
Description: PGP signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

 writes:
> > This is already standard practice for malware-laden sites, to
> > the extent that it's severely affecting things like Google Safe
> > Browsing and Facebook's link scanner, because Google and Facebook
> > always get to see benign content and only the end user gets the
> > malware.
>
>This is the single greatest side effect of a personalized web -- what you see
>depends on who you are.  Like that is good or something.

It's always interesting to see how the bad guys adopt some technologies much
faster than the good guys.  Another example beyond this one is intelligent
agents for interacting with online services, which exist mostly as research
papers and projects.  And banking trojans.

Peter.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[dan]

 > This is already standard practice for malware-laden sites, to
 > the extent that it's severely affecting things like Google Safe
 > Browsing and Facebook's link scanner, because Google and Facebook
 > always get to see benign content and only the end user gets the
 > malware.

This is the single greatest side effect of a personalized
web -- what you see depends on who you are.  Like that is
good or something.

--dan

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Jon Callas]

On 6 Dec, 2011, at 3:43 AM, ianG wrote:

> The promise of PKI in secure browsing is that it addresses the MITM.  That's 
> it, in a nutshell.  If that promise is not true, then we might as well use 
> something else.

Is it?

I thought that the purpose of a certificate was to authenticate the server to 
the client. This is a small, but important difference. If you properly 
authenticate the server, then (one hopes) that we've tacitly eliminated both an 
impersonation attack and a MiTM (an MiTM is merely a real-time, two-way 
impersonation).

The problem is that we're authenticating the server by naming, and there are 
many entities with a reason to lie about names. There are legitimate and 
illegitimate reasons to lie about names, and while we know that it's going on, 
we don't have a characterization of what reality even *is*.

We're seeing this in this very discussion. I also want to see proof that this 
is going on. I know it is, but I want to see it. These bogus certs are a lot 
like dark matter -- we know they're there, but we have little direct 
observation of them.

Jon

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Adam Back]

Yes, Peter said the same, BUT do you think they have a valid cert chain?  Or
is it signed by a self-signed company internal CA, and the company internal
CA added to the corporate install that you mentioned...  Thats the cut off
of acceptability for me - full public valid cert chain on other peoples
domains for MitM thats very bad.  Internal cert chain via adding cert to
browser - corporate can go for it, its their network, their equipment to
install software on!

(Bearing in mind its the corporate intention to keep other people off their
network with firewalls, network auth etc).  One claim by Lucky if I recall
is that the new trend in bring your own device (iphone, android, ipad etc)
starts to cause a conflict - becomes complicated for the corporate to expect
to install certs into all those browsers.  They no longer control the OS/app
install.

I think thats true - but in effect if your environment is that security
conscious, you probably should not be allowing BYOD anyway - who knows what
malware is on it, bypassing your egress is completely _trivial_ with
software, or even just config of software.  And anyway since when does your
minor inconvenience of installing certs authorize you or CAs to subverting
the SSL guarantee and other people's security.  Even people who have
internal CAs for certification SHOULD NOT be abusing them for MitM.

Adam

On Tue, Dec 06, 2011 at 10:52:43AM +, Florian Weimer wrote:

* Adam Back:


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.


Such CAs do exist, but to my knowledge, they are enterprise-internal CAs
which are installed on corporate devices, presumably along with other
security software.  Even from a vendor point of view, this additional
installation step is desirable because it fits well with a per-client
licensing scheme, so I'm not sure what the benefit would be to get a
certificate leading to one of the public roots.

--
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[ianG]

On 6/12/11 21:52 PM, Florian Weimer wrote:

* Adam Back:


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.

Such CAs do exist, but to my knowledge, they are enterprise-internal CAs
which are installed on corporate devices, presumably along with other
security software.  Even from a vendor point of view, this additional
installation step is desirable because it fits well with a per-client
licensing scheme, so I'm not sure what the benefit would be to get a
certificate leading to one of the public roots.



The promise of PKI in secure browsing is that it addresses the MITM.  
That's it, in a nutshell.  If that promise is not true, then we might as 
well use something else.


If the reality is that it simply makes the MITM a sellable feature, 
that's a breach of the promise.  If the situation is "we'll protect you 
from some MITMs and we'll sell other MITMs over you ..." it's a breach 
of the original terms that were foisted on browsing in the first place...


Now, this doesn't necessarily mean that some MITMs can't be justified.  
It's more that the original promise is what the users believe.  And 
exceptions like this aren't really tolerated in the beliefs of users.


So, we need that debate:  what's an exception?  what's tolerable?  
what's the point?


We need to see those MITM certs.  So we can understand what the nature 
of the breach is.




iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Adam Back]

Someone should re-test that Three 3g data + bluecoat content-filtering
-as-a-service with SSL and give us the cert if the answer is "interesting"
:)

Most of the parental control and site blocking things are trivially
breakable.  For example my router can block domains ..  but its mechanism is
idiotic - it blocks based on the Host: header of HTTP so just going to the
SSL site completely bypasses its block.  My kid figured that out in 5mins
flat (facebook competing with homework for attention :)

Kids figure this stuff out getting through site restrictions on school wifi
also.  Some schools try to block popular web games.. eg runescape.

Adam

On Tue, Dec 06, 2011 at 10:45:26PM +1300, Peter Gutmann wrote:

Note that while they're [three.co.uk 3g data] using Bluecoat hardware to do
it, there's no mention of SSL MITM'ing.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Florian Weimer]

* Adam Back:

> 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.

Such CAs do exist, but to my knowledge, they are enterprise-internal CAs
which are installed on corporate devices, presumably along with other
security software.  Even from a vendor point of view, this additional
installation step is desirable because it fits well with a per-client
licensing scheme, so I'm not sure what the benefit would be to get a
certificate leading to one of the public roots.

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Earlier in the discussion there were questions about why a service provider
would want to MITM their customers.  This has now been answered by a service
provider: It's to protect the children.  From
http://patrick.seurre.com/?p=42

  Three's policy with regards to filtering is intended to ensure that children
  are protected from inappropriate content when using the internet on their
  phones [...] This is not about intercepting customer communications but is
  about the safety of children who use our network.

Note that while they're using Bluecoat hardware to do it, there's no mention
of SSL MITM'ing.

Another interesting point in the post:

  In addition I asked Three why they were wasting money on Bluecoat's services
  when any webmaster worth his salt knows how to tailor the webpage provided
  based on the IP address of the PC making the request. They could produce a
  page full of innocent images for Bluecoat when they come calling, but save
  all the unsavoury material for the .real. visitor.

This is already standard practice for malware-laden sites, to the extent that
it's severely affecting things like Google Safe Browsing and Facebook's link
scanner, because Google and Facebook always get to see benign content and only
the end user gets the malware.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[cgp 3cg]

> In general it looks like it's a mixture of "it's configurable" and "it depends
> on the vendor" (the above only tells you what Bluecoat do).  Interesting to
> note that the Bluecoat hardware has problems MITM-ing Windows Update, because
> Microsoft apply the quite sensible measure of only allowing something signed
> by a known Windows Update cert (or at least on a Microsoft-supplied trust
> list), rather than any old cert that turns up as long as it's signed by some
> CA somewhere.  I've heard of a similar approach proposed for smartphone mobile
> banking apps, you hardcode in a cert that's used to verify a whitelist of
> known-good certs for banks (more or less like Microsoft's CTLs), and then it
> doesn't matter what certs the CAs sign because if it's not on the CTL then it
> doesn't get trusted.

Sounds similar to the mechanism which allowed detection of the
DigiNotar breach by Chrome:

http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html

Two major players using certificate pinning to provide additional
security where CAs let us down. There may just be a lesson in there
...

-C
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Ondrej Mikle  writes:

>Matches my observations, especially when looking at CRLs of some small CAs
>(company internal). I had a hunch some of those revocations could be due to
>CA compromise, but from my point of view it is be only a speculation. I
>appreciate sharing your experience working with CAs, it gives me a bit more
>understanding in my guesswork how they operate internally :-)

So I'm going to invoke the Carl Ellison "if you think that's bad" rule (stated
approximately as "whenever someone tells a horror story about PKI, someone
else will come along with 'if you think that's bad...'") and mention a trusted
root CA that went out of business (I tracked its root key through three
resales but I have no idea who has it now) where not only did no-one who was
left know how to put reason codes in CRLs, there was no-one who actually knew
how to issue a CRL.  So if you had a cert from them you could pretty much do
whatever you wanted with it (until it expired naturally) because there was no
way to revoke it.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ondrej Mikle]

On 12/05/2011 04:21 AM, Lucky Green wrote:

On 2011-12-04 12:09, Ondrej Mikle wrote:
[...]

I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason,
about month after Peter Eckersley did. Result was the same (counting "trusted"
CAs). Plus few others (some seemed to be internal company CAs; but did not chain
to a "trusted root").


Ondrej,
Most (but not all) of the CAs that I worked with over the years did not
have anybody on the operations side full time that would know how to
place a revocation reason into the CRL. Which is why the majority of CRL
entries include an unspecified reason code or the ever popular reason
code "NULL".


Matches my observations, especially when looking at CRLs of some small 
CAs (company internal). I had a hunch some of those revocations could be 
due to CA compromise, but from my point of view it is be only a 
speculation. I appreciate sharing your experience working with CAs, it 
gives me a bit more understanding in my guesswork how they operate 
internally :-)



Without taking anything away from the work of the folks at the EFF (I
appreciate their effort and have been a long-time financial supporter of
the EFF), determining the number of CA compromises from looking at "CA
Compromise" in reason codes is like determining car theft statistics
from the number of car thieves that turn themselves in at the police
station.


Of course, those marked 'CA compromise' are just the detected and 
admitted cases (a lower bound). However should I claim any other 
revocations were due to CA compromise I'd have to back that claim with 
some evidence.



It does not require disclosing of any confidential information to come
to the conclusion that more certificates have been revoked due to CA
compromise than certs were issued due to CA compromise. Indeed, you only
need to look through the database for certs that very publicly have been
revoked due to CA compromise to find a some that lack that reason code
in the CRL.


Can you elaborate on the part of "coming to the conclusion that 
revocation was due to CA compromise"? In the first sentence, should the 
last part say "...than certs were revoked citing CA compromise as the 
reason"? (I'm having trouble parsing it)
My first idea would be to look for a batch of certs revoked in a short 
time period when looking for CA compromise.


The hunch I wrote above is based on my short period (about 7 years ago) 
working part-time for a company that did a lot of IT projects for 
government institutions. One of the projects was a pilot application for 
eGovernment (which included PKI and CA-ish stuff). Before that project I 
was tasked with penetration testing for said company, so I had pretty 
good idea how a hacker could obtain access. There was lot of bad blood 
between management and developers, experienced people left, 
inexperienced developers were responsible for gaping security holes. The 
company's use of bribes to secure government contracts was an open 
secret (company has gone bankrupt since then).


Did some of the CAs you worked for exhibit similar atmosphere like the 
company above? I'm asking because in such environment people simply 
wouldn't be motivated enough to really care about breaches and competent 
people wouldn't stay there for long.



Also, a friend once mentioned he had direct access to RA/CA interface at 
a telco operator issuing certs that chained to Verisign for some project 
(him being project manager from another company). That gave me 
impression that such interfaces are probably more common than an 
"uninitiated outsider" might think. Is that guess correct?




Lastly, I am not trying to insinuate that having your CA compromised is
or should ever become a crime.


I agree here. Also CA claiming to have no compromise just might be the 
case of not being able to detect one or be lying (which is way worse). 
That's why I did not name CAs from the CRLs (wouldn't be a good 
motivation to keep them honest about revocation reasons).


Ondrej
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[James A. Donald]

On 2011-12-05 14:58, Sandy Harris wrote:

Peter Gutmann  wrote:


You have to be inside the captive portal to see these blue-pill certs.  This
is why various people have asked for samples, because only a select lucky few
will be able to experience them in the wild.


I am in China. How could I test whether the Great Firewall's packet
sniffers have such a cert.?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography


If you are in China, you probably have a vpn through the great firewall 
into a tax haven.  If you have software that detects change in certs, 
login with and without your vpn.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Sandy Harris  writes:

>I am in China. How could I test whether the Great Firewall's packet sniffers
>have such a cert.?

I'd be kinda surprised if they did that because it's meant to be surreptitious
and the Great Firewall isn't exactly a state secret.  I'd just use the
Perspectives extension to warn me about odd things.

Oh heck, just run Perspectives anyway no matter what.  It's great for
overriding Firefox' pointless browser warnings.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Sandy Harris]

Peter Gutmann  wrote:

> You have to be inside the captive portal to see these blue-pill certs.  This
> is why various people have asked for samples, because only a select lucky few
> will be able to experience them in the wild.

I am in China. How could I test whether the Great Firewall's packet
sniffers have such a cert.?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Ondrej Mikle  writes:

>Sorry, my bad. Mismatch in my thinking<->editing coordination. Originally I
>wanted to ask whether you encountered a breach that was not over all the
>news, but a rather localized incident at the places you and Lucky described.
>Or heard about one from colleagues in the field (then I oversimplified the
>question's formulation too much).
>
>Basically I was curious what portion of similar breaches got buried from
>"outside world".

So it's a bit of a "how many undetected security compromises have you had"
question :-).  As such it's impossible to answer, although in general I would
say that I doubt some of the parties involved would actually be capable of
detecting a breach.  So it's not a case of "would they cover it up", it's "how
would they even know"?

At best you could reason by analogy, consider the typical IT-using company and
their security measures, would you trust them to detect and identify an
intrusion (say an SQL injection attack on their server) and notify the media
and their customers so that they could take corrective action?  You're now
dealing with standard organisations (not even computer companies but just
J.Random organisation somewhere), and this is IT Job #427, alongside more
important stuff like how do your remote staff get to the Exchange server from
their hotel in Bratislava and how do you get iTunes traffic through the
firewall [0].

Peter.

[0] Whoever coupled OS updates and whatnot with a mechanism as firewall-
hostile as iTunes needs to be killed and eaten to prevent them from 
passing on the genes.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Lucky Green]

On 2011-12-04 12:09, Ondrej Mikle wrote:
[...]
> I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason,
> about month after Peter Eckersley did. Result was the same (counting "trusted"
> CAs). Plus few others (some seemed to be internal company CAs; but did not 
> chain
> to a "trusted root").

Ondrej,
Most (but not all) of the CAs that I worked with over the years did not
have anybody on the operations side full time that would know how to
place a revocation reason into the CRL. Which is why the majority of CRL
entries include an unspecified reason code or the ever popular reason
code "NULL".

Without taking anything away from the work of the folks at the EFF (I
appreciate their effort and have been a long-time financial supporter of
the EFF), determining the number of CA compromises from looking at "CA
Compromise" in reason codes is like determining car theft statistics
from the number of car thieves that turn themselves in at the police
station.

Sure, once in a while a fellow that has not been suspected of any crime
will walk into a police station and decide to turn himself in. Every cop
will have a story or two along those lines. But the number of crimes
(and criminals) far exceed the number of criminals that choose to turn
themselves in to the police.

It does not require disclosing of any confidential information to come
to the conclusion that more certificates have been revoked due to CA
compromise than certs were issued due to CA compromise. Indeed, you only
need to look through the database for certs that very publicly have been
revoked due to CA compromise to find a some that lack that reason code
in the CRL.

Lastly, I am not trying to insinuate that having your CA compromised is
or should ever become a crime.

--Lucky Green
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ondrej Mikle]

On 12/04/11 13:08, Peter Gutmann wrote:
> Ondrej Mikle  writes:
> 
>> How do MitM boxes react when they MitM connection to a server with self-
>> signed cert (or cert issued by an obsure CA not trusted by MitM box)? 
> 
> For one example, see
> http://wikileaks.org/spyfiles/docs/bluecoat/219_blue-coat-systems-reference-guide-ssl-proxy.html
> and 
> http://wikileaks.org/spyfiles/docs/bluecoat/246_blue-coat-systems-deployment-guide-deploying-the-ssl-proxy.html.

Thanks.

>> Given the state of security/auditing of "private sub-CAs" as described, was
>> there ever a report of a breach (e.g. stolen key, fraudulently issued certs)?
> 
> You're joking, right?

Sorry, my bad. Mismatch in my thinking<->editing coordination. Originally I
wanted to ask whether you encountered a breach that was not over all the news,
but a rather localized incident at the places you and Lucky described. Or heard
about one from colleagues in the field (then I oversimplified the question's
formulation too much).

Basically I was curious what portion of similar breaches got buried from
"outside world".

I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason,
about month after Peter Eckersley did. Result was the same (counting "trusted"
CAs). Plus few others (some seemed to be internal company CAs; but did not chain
to a "trusted root").

I found your observations about PKI often spot on and I thought they were
hyperbolically witty. I guess then you were actually not joking at all.

Ondrej
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[James A. Donald]

On 2011-12-04 18:18, Ondrej Mikle wrote:

Hypothetical question: assume enough people get educated how to spot the MitM
box at work/airport/hotel. Let's say few of them post the MitM chains publicly
which point to a big issuing CA. It was said (by Peter I think) that nothing
would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing
sub-CAs take the fall? (lose license and invested funds)


You think too small.  We should be trying to replace PKI, not particular 
badly behaved bits of the PKI infrastructure.


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Lucky Green  writes:

>If the concern is that employees receive security warnings when accessing in-
>house websites, the standard solution is to push out a corporate root via AD,
>which is transparent and works quite well.

And once they get AD and/or WSUS ported to OS X and Linux it'll be even more
useful :-).

Another reason I've seen for in-house sub-CAs is that even if you're an all-
Windows environment it may be too hard to push a private root out to everyone
if there's no centralised control over everything (due to
compartmentalisation/chinese walls/geographic distribution/whatever).

>No root CA that I have encountered requires that you operate the HSM in FIPS
>mode or mandates that you shall not back up the private key in the clear to a
>USB flash drive.

I think the reason for the former is that almost no-one ever operates their
hardware in FIPS mode, period.  A few years ago someone who works for $global-
hardware-vendor mentioned at a conference that when you buy their FIPS 140-
certified hardware you need to get an optional add-on, available free for the
asking, to run it in FIPS 140 mode.  In the product's entire lifetime the
number of requests they've had could be counted on the fingers of one hand.

Another global security product vendor shipped one of their flagship products
with a bug that caused it to crash when FIPS 140 mode was enabled.  It took
several years before anyone noticed.

>Every professional services team that I have worked with over the years
>recommended to the customers of such sub-CAs to make a backup of the private
>keys and store them in a safe somewhere. 

PKCS #12 is very popular for this.  Some HSMs, quite reasonably (in the
vendors' view) and quite unreasonably (in the customers' view) don't allow
easy key export except via vendor-supplied mechanisms (e.g. cloning into
another $10,000 HSM or storing key portions in vendor-supplied smart
cards/datakeys/whatever), but if you generate the key in software and load it
into the HSM via a PKCS #12 then you can back it up and share it around
without the HSM getting in the way.

>Sometimes encrypted, sometimes in the clear, but always with the necessary
>decryption information (smartcards and/or PINs) in the same safe.

This is what makes buying crypto gear on eBay so much fun, if you buy PKI-
oriented HSMs then there'll typically be a note stuck to the crypto gear with
the PIN(s) on it.  You end up with all sorts of interesting signing keys that
way (things like Luna CA3's aren't cheap, so only relatively high-value keys
tend to get stored in them, e.g. CA keys for government departments).  As with
disposing of hard drives in PCs and servers, the crypto hardware lifecycle
seems to stop at "we unplugged it".

>The standard sub-CA contracts contain a right to audit the number of certs
>issued, like any enterprise-wide software license agreement does include a
>right to audit used seats. Not once in over 30 years have I seen such an
>audit performed.

Yup, that's what I've found as well, it's just a variation on the per-seat
software licensing model, except that there's no BSA.

>The smart purchasing manager will pay less than USD 50k.

Oh, maybe I've been talking to less smart managers :-), the figures I heard
started at $50K and quickly went up into six digits.  Or maybe the inevitable
race to the bottom has made things cheaper in the last few years.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ralph Holz]

Hi,

>> We're actually about to release a little tool that does exactly that,
>> report the encountered MitM for further scrutiny.
> 
> Great! I had some ideas how to implement and spread it, awesome to hear that
> that you beat me to it :-)

:) It was actually Kai Engert who made the initial suggestion, and we've
just followed up on it. We've proposed a talk at berlinsides, let's see
if that works out. :-)

Ralph

-- 
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/



signature.asc
Description: OpenPGP digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Ondrej Mikle  writes:

>How do MitM boxes react when they MitM connection to a server with self-
>signed cert (or cert issued by an obsure CA not trusted by MitM box)? 

For one example, see
http://wikileaks.org/spyfiles/docs/bluecoat/219_blue-coat-systems-reference-guide-ssl-proxy.html
and 
http://wikileaks.org/spyfiles/docs/bluecoat/246_blue-coat-systems-deployment-guide-deploying-the-ssl-proxy.html.

In general it looks like it's a mixture of "it's configurable" and "it depends
on the vendor" (the above only tells you what Bluecoat do).  Interesting to
note that the Bluecoat hardware has problems MITM-ing Windows Update, because
Microsoft apply the quite sensible measure of only allowing something signed
by a known Windows Update cert (or at least on a Microsoft-supplied trust
list), rather than any old cert that turns up as long as it's signed by some
CA somewhere.  I've heard of a similar approach proposed for smartphone mobile
banking apps, you hardcode in a cert that's used to verify a whitelist of
known-good certs for banks (more or less like Microsoft's CTLs), and then it
doesn't matter what certs the CAs sign because if it's not on the CTL then it
doesn't get trusted.

>Given the state of security/auditing of "private sub-CAs" as described, was
>there ever a report of a breach (e.g. stolen key, fraudulently issued certs)?

You're joking, right?

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ondrej Mikle]

On 12/04/11 12:21, Ralph Holz wrote:
> Hi,
> 
>> Hypothetical question: assume enough people get educated how to spot the MitM
>> box at work/airport/hotel. Let's say few of them post the MitM chains 
>> publicly
>> which point to a big issuing CA. It was said (by Peter I think) that nothing
>> would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing
>> sub-CAs take the fall? (lose license and invested funds)
> 
> We're actually about to release a little tool that does exactly that,
> report the encountered MitM for further scrutiny.

Great! I had some ideas how to implement and spread it, awesome to hear that
that you beat me to it :-)

Ondrej
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ralph Holz]

Hi,

> Hypothetical question: assume enough people get educated how to spot the MitM
> box at work/airport/hotel. Let's say few of them post the MitM chains publicly
> which point to a big issuing CA. It was said (by Peter I think) that nothing
> would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing
> sub-CAs take the fall? (lose license and invested funds)

We're actually about to release a little tool that does exactly that,
report the encountered MitM for further scrutiny.

Ralph

-- 
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/



signature.asc
Description: OpenPGP digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ondrej Mikle]

This thread is amazing. I've known just a fractions/hints of the practices
described here. Few comments/questions inline/below.

On 12/04/11 07:37, Lucky Green wrote:
> Concur. The standard sub-CA contracts contain a right to audit the
> number of certs issued, like any enterprise-wide software license
> agreement does include a right to audit used seats. Not once in over 30
> years have I seen such an audit performed. There is no reason to audit:
> when you buy a sub-CA, the public CA's rep will work out a contract that
> gives you the right to use as many certs and more as you conceivably
> could use given the application to which you plan to put the sub-CAs.
> Keeping count of actual certs issued would only add cost to both the
> sub-CA customer and the root CA provider. There is simply no business
> case for auditing the number of certs issued.

On 12/02/11 11:02, Peter Gutmann wrote:
> It's not just a claim, I've seen them too.  For example I have a cert issued
> for google.com from such a MITM proxy.  I was asked by the contributor not to
> reveal any details on it because it contains the name and other info on the
> intermediate CA that issued it, but it's a cert for google.com used for deep
> packet inspection on a MITM proxy.  I also have a bunch of certs from private-
> label CAs that chain directly up to big-name public CAs, there's no technical
> measure I can see in them anywhere that would prevent them from issuing certs
> under any name.

How do MitM boxes react when they MitM connection to a server with self-signed
cert (or cert issued by an obsure CA not trusted by MitM box)? Do the boxes send
to client also an auto-generated self-signed cert that generates warning or
"re-sign" it so that client sees valid chain?

MitM-re-signing an unverifiable chain of server to a chain that's trusted at the
MitM-ed client would be hilarious, allowing to MitM a MitM box (though this
would be an easily avoidable mistake to make).

Given the state of security/auditing of "private sub-CAs" as described, was
there ever a report of a breach (e.g. stolen key, fraudulently issued certs)?


While chasing data from my scans around, I checked history of few CAs. Most
oddly hilarious "trusted" CA is probably SAIC (Science Applications
International Corporation). Reason: SAIC led the development of Trailblazer
Project for NSA (in my book this tops much-too-obvious CAs of other TLA 
agencies).
Also, Network Solutions, L.L.C (also a CA) was owned by SAIC at some time.
Later, Network Solutions did not acquire exactly "good guy" reputation.
Don't get me wrong: I'm not claiming either of the mentioned CAs did anything
egregious subverting CA-trust placed in them. I have no intention to single them
out as "shady", additional search would turn up many more CAs.



Hypothetical question: assume enough people get educated how to spot the MitM
box at work/airport/hotel. Let's say few of them post the MitM chains publicly
which point to a big issuing CA. It was said (by Peter I think) that nothing
would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing
sub-CAs take the fall? (lose license and invested funds)


Ondrej
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Lucky Green]

On 2011-12-03 10:44, Kevin W. Wall wrote:
> On Fri, Dec 2, 2011 at 1:07 AM, Peter Gutmann  
> wrote:
> [snip]
>> OK, so it does appear that people seem genuinely unaware of both the fact 
>> that
>> this goes on, and the scale at which it happens.  Here's how it works:
>>
>> 1. Your company or organisation is concerned about the fact that when people
>> go to their site (even if it's an internal, company-only one), they get scary
>> warnings.

Partially correct. More commonly, the reason why enterprises buy sub-CAs
from public CAs is to be able to create certs that will be seen by
non-employees, such as for example S/MIME signing certs.

If your employees use S/MIME to sign outgoing emails, you don't want
those emails to trigger a security alert in your business partner's or
customers email client.

(In practice, it will rarely be your employee that signs an outgoing
email with S/MIME, but rather the signature will be performed by the
corporate encryption gateway. Note that end-to-end encryption, such as
S/MIME, breaks content inspection and fails to comply with cleartext
archival and retrieval regulatory requirements).

>> 2. Your IT people go to a commercial CA and say "we would like to buy the
>> ability to issue padlocks ourselves rather than having to buy them all off
>> you".
> 
> When it is *only* company-only, I think it's much more common for companies
> to set up their internal CAs and just do something like an SMS or WSUS push
> to get their internal root CA certs into all the trusted keystores of all the
> company computers. I've only seen the latter case used when it involves
> residential customers. We can't take that the approach to force them to
> add our internal CA cert chain to their trust stores, and even if we could it
> would likely result in so many calls to the help desk to make it infeasible.
> However, we have occasionally used that approach with business partners.

Agreed. If the concern is that employees receive security warnings when
accessing in-house websites, the standard solution is to push out a
corporate root via AD, which is transparent and works quite well.
Enterprise environments typically purchase a sub-CA only when the certs
will be seen by third parties.

>> 3. The CA goes through an extensive consulting exercise (billed to the
>> company), after which they sell the company a padlock-issuing license, also
>> billed to the company.  The company is expected to keep records for how many
>> padlocks they issue, and pay the CA a further fee based on this.

Sure, the sub-CA contract does include a maximum number of certs that
you are allowed to issue, but I have never seen such a contract
determining pricing based on an exact count. Instead, the pricing is
based on base + anticipated number of certs.

>> 4. Security is done via the honour system, the CA assumes the company won't 
>> do
>> anything bad with their padlock-issuing capability (or at least I've never
>> seen any evidence of a CA doing any checking apart from for the fact that
>> they're not getting short-changed).
>
> Through the honor system? Does that mean that we can use a pair
> of dice rolled two or three times for our "hardware key generation"? ;-)

Most public CAs that ship with MSIE/Mozilla/Chrome that sell sub-CAs
will contractually require that your in-house sub-CA stores its private
keys on a FIPS 140-2 certified HSM. No root CA that I have encountered
requires that you operate the HSM in FIPS mode or mandates that you
shall not back up the private key in the clear to a USB flash drive.

Every professional services team that I have worked with over the years
recommended to the customers of such sub-CAs to make a backup of the
private keys and store them in a safe somewhere. Sometimes encrypted,
sometimes in the clear, but always with the necessary decryption
information (smartcards and/or PINs) in the same safe.

With the major brands of root CAs you will need to show that you have a
CP/CPS in place. The root CA's professional services team will provide
you with a CP/CPS template. That CP/CPS will allow you to issue any kind
of cert that doesn't interfere with the root CA's core business or is
overtly criminal.

> Actually, more surprisingly, I've been told by those who manage
> something like this for our company, that even the reported
> number of padlocks that they issue and are expected to
> compensate the CA for is kept on the honor systemm--at least
> for the CA with whom we interact. (Or course, I'm assuming that
> the this CA retains the right to periodically do audits, etc.)

Concur. The standard sub-CA contracts contain a right to audit the
number of certs issued, like any enterprise-wide software license
agreement does include a right to audit used seats. Not once in over 30
years have I seen such an audit performed. There is no reason to audit:
when you buy a sub-CA, the public CA's rep will work out a contract that
gives you the right to use as many certs and more as you conceivably
cou

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Kevin W. Wall]

On Fri, Dec 2, 2011 at 1:07 AM, Peter Gutmann  wrote:
[snip]
> OK, so it does appear that people seem genuinely unaware of both the fact that
> this goes on, and the scale at which it happens.  Here's how it works:
>
> 1. Your company or organisation is concerned about the fact that when people
> go to their site (even if it's an internal, company-only one), they get scary
> warnings.
>
> 2. Your IT people go to a commercial CA and say "we would like to buy the
> ability to issue padlocks ourselves rather than having to buy them all off
> you".

When it is *only* company-only, I think it's much more common for companies
to set up their internal CAs and just do something like an SMS or WSUS push
to get their internal root CA certs into all the trusted keystores of all the
company computers. I've only seen the latter case used when it involves
residential customers. We can't take that the approach to force them to
add our internal CA cert chain to their trust stores, and even if we could it
would likely result in so many calls to the help desk to make it infeasible.
However, we have occasionally used that approach with business partners.

> 3. The CA goes through an extensive consulting exercise (billed to the
> company), after which they sell the company a padlock-issuing license, also
> billed to the company.  The company is expected to keep records for how many
> padlocks they issue, and pay the CA a further fee based on this.
>
> 4. Security is done via the honour system, the CA assumes the company won't do
> anything bad with their padlock-issuing capability (or at least I've never
> seen any evidence of a CA doing any checking apart from for the fact that
> they're not getting short-changed).

Through the honor system? Does that mean that we can use a pair
of dice rolled two or three times for our "hardware key generation"? ;-)

Actually, more surprisingly, I've been told by those who manage
something like this for our company, that even the reported
number of padlocks that they issue and are expected to
compensate the CA for is kept on the honor systemm--at least
for the CA with whom we interact. (Or course, I'm assuming that
the this CA retains the right to periodically do audits, etc.)

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[M.R.]

On 12/01/2011 07:45 AM, James A. Donald wrote:


... We have to reconstruct our institutions for third world trust
levels and southern European trust levels. Institutions characteristic
of Europe and the old North America are no longer capable of
functioning,...


as a "south European" I could offer some observations on WASP trust
levels and ethics in general. But it is

(a) not my style

and

(b) not really pertinent to the mission of this list

Mark R.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ben Laurie]

On Fri, Dec 2, 2011 at 10:02 AM, Peter Gutmann
 wrote:
> Adam Back  writes:
>
>>Start of the thread was that Greg and maybe others claim they've seen a cert
>>in the wild doing MitM on domains the definitionally do NOT own.
>
> It's not just a claim, I've seen them too.  For example I have a cert issued
> for google.com from such a MITM proxy.  I was asked by the contributor not to
> reveal any details on it because it contains the name and other info on the
> intermediate CA that issued it, but it's a cert for google.com used for deep
> packet inspection on a MITM proxy.  I also have a bunch of certs from private-
> label CAs that chain directly up to big-name public CAs, there's no technical
> measure I can see in them anywhere that would prevent them from issuing certs
> under any name.
>
> (An unfortunate effect of the private-label CAs is that they contain
> identifying information on the organisation that uses them, something I hadn't
> considered in my "post them to the list" request, and publishing them would
> publicly out your employer or organisation as doing this.  So I'll modify my
> "post to the list" to "email them to me in private" :-).

To what end? And, BTW, I'd like to see them too :-)

>>The real question again is can we catch a boingo or corp lan or government
>>using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing
>>it, and delist them.
>
> Given that some of the biggest CAs around sell private-label CA certs, you'd
> end up shutting down half the Internet if you did so.
>
> Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Adam Back  writes:

>Start of the thread was that Greg and maybe others claim they've seen a cert
>in the wild doing MitM on domains the definitionally do NOT own.

It's not just a claim, I've seen them too.  For example I have a cert issued
for google.com from such a MITM proxy.  I was asked by the contributor not to
reveal any details on it because it contains the name and other info on the
intermediate CA that issued it, but it's a cert for google.com used for deep
packet inspection on a MITM proxy.  I also have a bunch of certs from private-
label CAs that chain directly up to big-name public CAs, there's no technical
measure I can see in them anywhere that would prevent them from issuing certs
under any name.

(An unfortunate effect of the private-label CAs is that they contain
identifying information on the organisation that uses them, something I hadn't
considered in my "post them to the list" request, and publishing them would
publicly out your employer or organisation as doing this.  So I'll modify my
"post to the list" to "email them to me in private" :-).

>The real question again is can we catch a boingo or corp lan or government
>using a MitM sub-CA cert, and then we'll know which CA is complicit in issuing
>it, and delist them.

Given that some of the biggest CAs around sell private-label CA certs, you'd
end up shutting down half the Internet if you did so.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[James A. Donald]

On 2011-12-02 6:33 PM, Adam Back wrote:

To hand over a blank cheque sub-CA cert that could sign gmail.com is
somewhat dangerous. But you notice that geotrust require it to be in a
hardware token, and some audits blah blah, AND more importantly that you
agree not to create certs for domains you dont own.


And we have seen how effective audits have been since Sarbannes Oxley.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Adam Back]

Well I was aware of RA things where you do your own RA and on the CA side
they limit you to issuing certs belonging to you, if I recall thawte was
selling those.  (They pre-vet your ownership of some domains foocorp.com,
foocorpinc.com etc, and then you can issue www.foocorp.com, *.foocorp.com .. 
however you dont get a CA private key, you get web integration with the RA

so you dont have to do the email verification dance for each cert you
create).

Handing over a signed sub-CA is a much higher level of risk, unless perhaps
it has a constraint on the domain names of certs it can sign baked into it,
which is possible.

To hand over a blank cheque sub-CA cert that could sign gmail.com is
somewhat dangerous.  But you notice that geotrust require it to be in a
hardware token, and some audits blah blah, AND more importantly that you
agree not to create certs for domains you dont own.

Start of the thread was that Greg and maybe others claim they've seen a cert
in the wild doing MitM on domains the definitionally do NOT own.

(The windows 2k box sounds scary for sure, and you better hope that's not a
general unrestricted sub-CA cert, but even then you could admit its similar
to the security practices of diginotar.) 

Secure as the weakest link, and the weakest link just keeps getting lower. 
It would be interesting to know if there really are CAs lax enough to issue

a sub-CA cert to a windows box with no hardware container for the private
key.  (Not that it makes that much difference... hack the RA and the private
key doesnt matter so much).

The real question again is can we catch a boingo or corp lan or government
using a MitM sub-CA cert, and then we'll know which CA is complicit in
issuing it, and delist them.

Adam

On Fri, Dec 02, 2011 at 07:07:19PM +1300, Peter Gutmann wrote:

Ben Laurie  writes:


They appear to actually be selling sub-RA functionality, but very hard to
tell from the press release.


OK, so it does appear that people seem genuinely unaware of both the fact that
this goes on, and the scale at which it happens.  Here's how it works:

1. Your company or organisation is concerned about the fact that when people
go to their site (even if it's an internal, company-only one), they get scary
warnings.

2. Your IT people go to a commercial CA and say "we would like to buy the
ability to issue padlocks ourselves rather than having to buy them all off
you".

3. The CA goes through an extensive consulting exercise (billed to the
company), after which they sell the company a padlock-issuing license, also
billed to the company.  The company is expected to keep records for how many
padlocks they issue, and pay the CA a further fee based on this.

4. Security is done via the honour system, the CA assumes the company won't do
anything bad with their padlock-issuing capability (or at least I've never
seen any evidence of a CA doing any checking apart from for the fact that
they're not getting short-changed).

This is why in the past I've repeatedly referred to "unknown numbers of
unknown private-label CAs", we have absolutely no idea how many of these
private-label CAs are out there or who they are or who controls them, but
they're probably in the tens, if not hundreds, of thousands, and many are
little more than a Windows server on a corporate LAN somewhere (and I mean
that literally, it was odd to sit in front of a Windows 2000 box built from
spare parts located in what used to be some sort of supplies closet and think
"I can issue certs that chain to $famous_ca_name from this thing" :-).

Going through the process is like getting a BS 7799 FIPS 140 certification,
you pay the company doing the work to get you through the process, and you
keep paying them until eventually you pass.  The only difference is that while
I've heard of rare cases of companies failing BS 7799, I've never heard of
anyone failing to get a padlock-issuing license.

Are people really not aware of this?  I thought it was common knowledge.  If
it isn't, I'll have to adapt a writeup I've done on it, which assumes that
this is common knowledge.

Peter.

___
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

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Ben Laurie  writes:

>They appear to actually be selling sub-RA functionality, but very hard to
>tell from the press release.

OK, so it does appear that people seem genuinely unaware of both the fact that
this goes on, and the scale at which it happens.  Here's how it works:

1. Your company or organisation is concerned about the fact that when people
go to their site (even if it's an internal, company-only one), they get scary
warnings.

2. Your IT people go to a commercial CA and say "we would like to buy the
ability to issue padlocks ourselves rather than having to buy them all off
you".

3. The CA goes through an extensive consulting exercise (billed to the
company), after which they sell the company a padlock-issuing license, also
billed to the company.  The company is expected to keep records for how many
padlocks they issue, and pay the CA a further fee based on this.

4. Security is done via the honour system, the CA assumes the company won't do
anything bad with their padlock-issuing capability (or at least I've never
seen any evidence of a CA doing any checking apart from for the fact that
they're not getting short-changed).

This is why in the past I've repeatedly referred to "unknown numbers of
unknown private-label CAs", we have absolutely no idea how many of these
private-label CAs are out there or who they are or who controls them, but
they're probably in the tens, if not hundreds, of thousands, and many are
little more than a Windows server on a corporate LAN somewhere (and I mean
that literally, it was odd to sit in front of a Windows 2000 box built from
spare parts located in what used to be some sort of supplies closet and think
"I can issue certs that chain to $famous_ca_name from this thing" :-).

Going through the process is like getting a BS 7799 FIPS 140 certification,
you pay the company doing the work to get you through the process, and you
keep paying them until eventually you pass.  The only difference is that while
I've heard of rare cases of companies failing BS 7799, I've never heard of
anyone failing to get a padlock-issuing license.

Are people really not aware of this?  I thought it was common knowledge.  If
it isn't, I'll have to adapt a writeup I've done on it, which assumes that
this is common knowledge.

Peter.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Marsh Ray  writes:

> Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public
> Root
>
>[...]
>
> SAN FRANCISCO, RSA CONFERENCE, Feb. 14

February of which year?  If it's from this year then they're really late to
the party, commercial CAs have been doing this for more than a decade.  These
things are huge money-earners for them, they start at around $50K per sub-CA
cert and go from there, and because you have to do this to turn off the
browser warnings, large numbers of companies do it.  I don't know about actual
figures, but from stories I've heard it wouldn't surprise me if many CAs made
the majority of their income from selling padlocks [0] to companies rather
than selling them to web sites.

Or is GeoRoot some novel new thing that I'm not familiar with?

Peter.

[0] By "selling padlocks" I mean you give them money and people who come to
your site get to see a padlock picture.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Adam Back  writes:

>Surely the SSL Observatory has these MitM sub CA certs if they exist in the
>wild and are being used to create real time MitM certs for domains the issuer
>certainly doesnt own.

You have to be inside the captive portal to see these blue-pill certs.  This 
is why various people have asked for samples, because only a select lucky few 
will be able to experience them in the wild.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Nico Williams]

On Thu, Dec 1, 2011 at 5:11 PM, Adam Back  wrote:
> btw if client certs are being used or TLS-SRP ciphersuite these attacks
> would not work because SSL negotiation would fail.  Unless the MitM could
> create fake client certs on the fly also that would be acceptable to the
> server.

Right, because those involve a channel binding (internal to the channel itself).

OBC doesn't detect the MITM though if the MITM re-writes the cookies
in the requests and responses.  In particular, if passwords are POSTed
in forms, the MITM gets them, though if origin bound cookies are
already in use by that point then the MITM has to rewrite them.

Nico
--
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Adam Back]

It does at least say they need a certificate practice statement, and
hardware key generation and storage, AND "All domains must be owned by the
enterprise customer".  They can sell the ability to be a sub-CA if they want
to.  There standards seem probably as good as your average CA and precludes
MitM applications.

GeoRoot would seem to preclude what Greg thinks he saw Boingo do.

Surely the SSL Observatory has these MitM sub CA certs if they exist in the
wild and are being used to create real time MitM certs for domains the
issuer certainly doesnt own.

I'd like to know which CAs if any are issuing these sub CA certs (so I can
remove them).  It would be intereseting to see what label they put on the
certs also.


btw if client certs are being used or TLS-SRP ciphersuite these attacks
would not work because SSL negotiation would fail.  Unless the MitM could
create fake client certs on the fly also that would be acceptable to the
server.

Adam

On Thu, Dec 01, 2011 at 05:59:23PM +, Ben Laurie wrote:

http://www.trustico.com/material/DS_GeoRoot_0205.pdf

Well, we'll only break the dishonest ones :-)

On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray  wrote:

On 12/01/2011 11:09 AM, Ben Laurie wrote:


On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray
wrote:



http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html



They appear to actually be selling sub-RA functionality, but very
hard to tell from the press release.

Bottom line: I'm going to believe this one someone displays a cert
chain.




Translated:


GeoRoot is only available for internal use, and organizations must
meet certain eligibility requirements, [...]  compliance guidelines,
and hardware security specifications.


     



Organizations must maintain a list Certificate Revocation List (CRL)


 ^^



for all certificates issued by the company.


                      


But don't worry,  Mozilla has a "checklist" for sub-CAs!

https://wiki.mozilla.org/CA:SubordinateCA_checklist


Home » CA:SubordinateCA_checklist




Terminology

The following terminology will be used in this wiki page regarding
subordinate CAs.

Third-Party: The subordinate CA is operated by a third party external
to the root CA organization; and/or an external third party may
directly cause the issuance of a certificate within the CA
hierarchy.




Third-party private (or enterprise) subordinate CAs: This is the case
where a commercial CA has enterprise customers who want to operate
their own CAs for internal purposes, e.g., to issue SSL server
certificates to systems running intranet applications, to issue
individual SSL client certificates for employees or contractors for
use in authenticating to such applications, and so on.

* These sub-CAs are not functioning as public CAs, so typical Mozilla
users would not encounter certificates issued by these sub-CAs in



s/would/should/


their normal activities.
* For these sub-CAs we need assurance that
they are not going to start functioning as public CAs.



As Dan would say, security comes from this "absence of the potential" for
this type of surprise.

This is not security, this reliance.


Currently the
only assurances available for this case it to ensure that these third
parties are required to follow practices that satisfy the Mozilla CA
Certificate Policy, and that these third parties are under an
acceptable audit regime.



Promises, promises.


o In Bug #394919 NSS is being updated to
apply dNSName constraints to the CN, in addition to the SANs.
o We
plan to update our policy to require CAs to constrain third-party
private (or enterprise) subordinate CAs so they can only issue
certificates within a specified domain. See section 4.2.1.10 of RFC
5280.



Someday.

To be fair to Mozilla, at least they're the ones with an open policy about
it. I didn't find such a policy for the other popular web clients (I may not
have looked hard enough).

- Marsh

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ben Laurie]

http://www.trustico.com/material/DS_GeoRoot_0205.pdf

Well, we'll only break the dishonest ones :-)

On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray  wrote:
> On 12/01/2011 11:09 AM, Ben Laurie wrote:
>>
>> On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray
>> wrote:


 http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html
>>
>>
>> They appear to actually be selling sub-RA functionality, but very
>> hard to tell from the press release.
>>
>> Bottom line: I'm going to believe this one someone displays a cert
>> chain.
>
>
>
> Translated:
>
>> GeoRoot is only available for internal use, and organizations must
>> meet certain eligibility requirements, [...]  compliance guidelines,
>> and hardware security specifications.
>
>      
>
>
>> Organizations must maintain a list Certificate Revocation List (CRL)
>
>  ^^
>
>
>> for all certificates issued by the company.
>
>                       
>
>
> But don't worry,  Mozilla has a "checklist" for sub-CAs!
>
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>
>> Home » CA:SubordinateCA_checklist
>
>
>> Terminology
>>
>> The following terminology will be used in this wiki page regarding
>> subordinate CAs.
>>
>> Third-Party: The subordinate CA is operated by a third party external
>> to the root CA organization; and/or an external third party may
>> directly cause the issuance of a certificate within the CA
>> hierarchy.
>
>
>> Third-party private (or enterprise) subordinate CAs: This is the case
>> where a commercial CA has enterprise customers who want to operate
>> their own CAs for internal purposes, e.g., to issue SSL server
>> certificates to systems running intranet applications, to issue
>> individual SSL client certificates for employees or contractors for
>> use in authenticating to such applications, and so on.
>>
>> * These sub-CAs are not functioning as public CAs, so typical Mozilla
>> users would not encounter certificates issued by these sub-CAs in
>
>
> s/would/should/
>
>> their normal activities.
>> * For these sub-CAs we need assurance that
>> they are not going to start functioning as public CAs.
>
>
> As Dan would say, security comes from this "absence of the potential" for
> this type of surprise.
>
> This is not security, this reliance.
>
>> Currently the
>> only assurances available for this case it to ensure that these third
>> parties are required to follow practices that satisfy the Mozilla CA
>> Certificate Policy, and that these third parties are under an
>> acceptable audit regime.
>
>
> Promises, promises.
>
>> o In Bug #394919 NSS is being updated to
>> apply dNSName constraints to the CN, in addition to the SANs.
>> o We
>> plan to update our policy to require CAs to constrain third-party
>> private (or enterprise) subordinate CAs so they can only issue
>> certificates within a specified domain. See section 4.2.1.10 of RFC
>> 5280.
>
>
> Someday.
>
> To be fair to Mozilla, at least they're the ones with an open policy about
> it. I didn't find such a policy for the other popular web clients (I may not
> have looked hard enough).
>
> - Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Marsh Ray]

On 12/01/2011 11:09 AM, Ben Laurie wrote:

On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray
wrote:

http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html


They appear to actually be selling sub-RA functionality, but very
hard to tell from the press release.

Bottom line: I'm going to believe this one someone displays a cert
chain.



Translated:


GeoRoot is only available for internal use, and organizations must
meet certain eligibility requirements, [...]  compliance guidelines,
and hardware security specifications.

  


Organizations must maintain a list Certificate Revocation List (CRL)

  ^^


for all certificates issued by the company.

   


But don't worry,  Mozilla has a "checklist" for sub-CAs!

https://wiki.mozilla.org/CA:SubordinateCA_checklist


Home » CA:SubordinateCA_checklist



Terminology

The following terminology will be used in this wiki page regarding
subordinate CAs.

Third-Party: The subordinate CA is operated by a third party external
to the root CA organization; and/or an external third party may
directly cause the issuance of a certificate within the CA
hierarchy.



Third-party private (or enterprise) subordinate CAs: This is the case
where a commercial CA has enterprise customers who want to operate
their own CAs for internal purposes, e.g., to issue SSL server
certificates to systems running intranet applications, to issue
individual SSL client certificates for employees or contractors for
use in authenticating to such applications, and so on.

* These sub-CAs are not functioning as public CAs, so typical Mozilla
users would not encounter certificates issued by these sub-CAs in


s/would/should/


their normal activities.
* For these sub-CAs we need assurance that
they are not going to start functioning as public CAs.


As Dan would say, security comes from this "absence of the potential" 
for this type of surprise.


This is not security, this reliance.


Currently the
only assurances available for this case it to ensure that these third
parties are required to follow practices that satisfy the Mozilla CA
Certificate Policy, and that these third parties are under an
acceptable audit regime.


Promises, promises.


o In Bug #394919 NSS is being updated to
apply dNSName constraints to the CN, in addition to the SANs.
o We
plan to update our policy to require CAs to constrain third-party
private (or enterprise) subordinate CAs so they can only issue
certificates within a specified domain. See section 4.2.1.10 of RFC
5280.


Someday.

To be fair to Mozilla, at least they're the ones with an open policy 
about it. I didn't find such a policy for the other popular web clients 
(I may not have looked hard enough).


- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Paul Hoffman]

On Dec 1, 2011, at 9:09 AM, Ben Laurie wrote:

> Bottom line: I'm going to believe this one someone displays a cert chain.

Multiple cert chains from different environments, please. One from Boingo (I'm 
not traveling for a few months so I can't grab one sooner), one from a 
corporation using a SonicWALL or similar box, and so on. We should not assume 
that all chains will have the same properties.

--Paul Hoffman

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ben Laurie]

On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray  wrote:
> On 11/30/2011 06:44 PM, Adam Back wrote:
>>
>> 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.
>
>
>
>>
>> http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html

They appear to actually be selling sub-RA functionality, but very hard
to tell from the press release.

Bottom line: I'm going to believe this one someone displays a cert chain.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Marsh Ray]

On 11/30/2011 06:44 PM, Adam Back wrote:

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.




http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html


GeoTrust Launches GeoRoot; Allows Organizations with Their Own

Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public
Root> GeoTrust Launches GeoRoot; Allows Organizations with Their Own
Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public
Root

Economical Solution Complements Capabilities of Internal CAs, such as
the Microsoft Certificate Authority, Allowing Public Recognition of
SSL and Client Certificates

SAN FRANCISCO, RSA CONFERENCE, Feb. 14 /PRNewswire/ -- GeoTrust,
Inc., a leader in identity verification solutions for e-business and
 the world's second largest issuer of SSL (secure sockets layer)
certificates for web security, today announced the availability of
GeoRoot(TM), an enterprise solution that allows organizations to
chain their internally issued digital certificates to GeoTrust's
publicly recognized roots. GeoRoot allows organizations with their
own Public Key Infrastructure (PKI) to extend the use of SSL server
and client certificates by leveraging a highly ubiquitous GeoTrust
root, supported by over 99% of browsers. "Today, many large
organizations utilize Microsoft's free Certificate Authority to
create digital certificates for securing their servers, email and
employee remote access," stated Neal Creighton, CEO of GeoTrust.
"However, these 'self-signed' certificates are only recognized within
the issuing organization or other allied organizations that have
chosen to share trust. By chaining to our widely supported public
root, these organizations can easily enable trusted e-business
transactions outside of their organizations." "Server-based digital
certificates for SSL have become increasingly important to
organizations because they provide enhanced security," stated Vic
Wheatman, Managing Vice President, Gartner, Inc. "However, we
recognize that some organizations need to extend acceptance of their
own certificates beyond their enterprise. By chaining their
certificates to a widely recognized root, organizations can elevate
trust levels and SSL functionality while using their own internal PKI
system." GeoRoot is designed to complement the existing capabilities
of an in-house Certificate Authority, allowing organizations to
maintain full control over Registration Authority (RA) functions for
the issuance of SSL server certificates and client certificates
(x.509). By chaining to GeoTrust's public root, certificates gain
compatibility with virtually all browsers and digital certificate and
public key security applications, including commerce sites, intranet,
extranet, S/MIME and VPN hardware and clients. This ubiquitous
recognition allows certificates, whether for electronic documents,
secure email or other transactions, to be trusted globally.
Certificate lifecycle management is a key feature of GeoRoot,
allowing organizations to easily issue, renew and revoke
certificates. Other functions, such as authenticating individuals,
deploying and managing SSL server certificates and client
certificates, as well as managing the distribution of public keys to
 appropriate parties, are all handled by the organization. GeoRoot
also allows an enterprise to maintain its own brand identity when
issuing certificates, an attractive feature for certain applications
 such as email certificates. In addition to GeoRoot, GeoTrust offers
a full line of digital certificates for identity verification,
including client certificates for secure access, SSL certificates for
e-commerce and web services security, code signing certificates for
software developers and the recently announced certified signing
solution for Adobe(R) Acrobat(R). Its customers include the world's
largest hosting companies, Global 1000 companies, educational
institutions and government agencies worldwide.

Pricing and Availability GeoRoot is available today in several
configurations, with annual licenses to meet the needs of low volume
 to high volume users. GeoRoot is only available for internal use,
and organizations must meet certain eligibility requirements,
including financial net worth, insurance minimums, policy,
implementation and compliance guidelines, and hardware security
specifications. Complete details are available from GeoTrust sales
at 866-511- 4141 or sa...@geotrust.com.

About GeoTrust, Inc. GeoTrust is a leader in identity verification
and trust services for e- business. Its products include web security
services for secure e-commerce transactions, identity verification
services for secure access, digital signing and consumer
verification, managed security services and TrustWatc

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[ianG]

On 2/12/11 03:26 AM, Rose, Greg wrote:

On 2011 Nov 30, at 22:28 , Jon Callas wrote:


On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote:


I run a wonderful Firefox extension called Certificate Patrol. It keeps a local 
cache of certificates, and warns you if a certificate, CA, or public key 
changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my 
stockbroker's web site, the warnings started to appear. Then it was just 
checking IP addresses and stuff.

And I presume you didn't save the cert.

Of course, we just need to have people look for these and then save them.

Yes. I regret that I had much bigger issues at the time than saving the cert.


I'm just poking around, it seems that Certificate Patrol should keep the 
cert.


In Firefox

Tools / Add-ons / Certificate Patrol / Preferences / View Certificates / 
getting tired now / Certificate Patrol, maybe click around here coz it 
didn't show the certs first time / turn off Group by Root Key / click on 
Stored Since to order, maybe twice / check the date in the hotel / ... 
time for a stiff drink / click on the cert / View / Details / Export / :-o


It does store certs.  It just takes above & beyond to get at them.  
Unknown whether it stores certs that you reject.



iang, now about that drink...
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Rose, Greg]

On 2011 Nov 30, at 22:28 , Jon Callas wrote:

> On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote:
> 
>> I run a wonderful Firefox extension called Certificate Patrol. It keeps a 
>> local cache of certificates, and warns you if a certificate, CA, or public 
>> key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to 
>> my stockbroker's web site, the warnings started to appear. Then it was just 
>> checking IP addresses and stuff.
> 
> And I presume you didn't save the cert.
> 
> Of course, we just need to have people look for these and then save them.

Yes. I regret that I had much bigger issues at the time than saving the cert. 
But, honestly, this is just the most recent time I've seen it... usually when 
traveling. I'm sure it won't be long before someone with more time and 
inclination than me will see another one.

sorry about that,
Greg.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[James A. Donald]

On 2011-12-01 2:03 PM, ianG wrote:

If a CA is issuing sub-CAs for the purpose of MITMing, is this a reason
to reset the entire CA? Or is it ok to do MITMing under certain nice
circumstances?


It seems our CA system has come to resemble our audit system and our 
financial system.


In very white rural areas, you will see stuff for sale on an honor 
system.  Go in, help yourself, and put the money in the box.  Where I 
now live, people often leave their house without locking the door behind 
them.  That is how "rednecks" behave.


As the community becomes more vibrant and diverse the high level of 
trust required for western institutions makes those institutions non 
viable.  We have to reconstruct our institutions for third world trust 
levels and southern European trust levels.  Institutions characteristic 
of Europe and the old North America are no longer capable of 
functioning, have not been capable of functioning for some time.


On the other hand, a paranoid environment, where everything has to be 
locked, and every claim has to be provable, is good business for 
cryptographers.  One can create institutions that will function well in 
such an environment, it is just trickier.




___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Nico Williams]

If only we at least used passwords to derive secret keys for authentication
protocols that could do channel binding...  Sure, that'd still be weak, but
it would be much, much better than what we have now.

Nico
--
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Jon Callas  writes:

>And I presume you didn't save the cert.
>
>Of course, we just need to have people look for these and then save them.

Cert *chain*, not cert.  "Save as PKCS #7/Certificate Chain" from the browser
dialog.

Peter.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Jon Callas]

On Nov 30, 2011, at 9:32 PM, Rose, Greg wrote:

> I run a wonderful Firefox extension called Certificate Patrol. It keeps a 
> local cache of certificates, and warns you if a certificate, CA, or public 
> key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my 
> stockbroker's web site, the warnings started to appear. Then it was just 
> checking IP addresses and stuff.

And I presume you didn't save the cert.

Of course, we just need to have people look for these and then save them.

Jon

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Ben Laurie]

On Thu, Dec 1, 2011 at 5:32 AM, Rose, Greg  wrote:
>
> On 2011 Nov 30, at 17:18 , Lee wrote:
>
>> On 11/30/11, Rose, Greg  wrote:
>>>
>>> On 2011 Nov 30, at 16:44 , Adam Back wrote:
>>>
 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.
>>>
>>> Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a
>>> few weeks ago.
>>
>> How did you know there was a MITM if it gave out a valid cert?
>
> I run a wonderful Firefox extension called Certificate Patrol. It keeps a 
> local cache of certificates, and warns you if a certificate, CA, or public 
> key changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my 
> stockbroker's web site, the warnings started to appear. Then it was just 
> checking IP addresses and stuff.

So ... let's see the cert(s), then!
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Rose, Greg]

On 2011 Nov 30, at 17:18 , Lee wrote:

> On 11/30/11, Rose, Greg  wrote:
>> 
>> On 2011 Nov 30, at 16:44 , Adam Back wrote:
>> 
>>> 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.
>> 
>> Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a
>> few weeks ago.
> 
> How did you know there was a MITM if it gave out a valid cert?

I run a wonderful Firefox extension called Certificate Patrol. It keeps a local 
cache of certificates, and warns you if a certificate, CA, or public key 
changes unexpectedly. Sort of like SSH meets TLS. As soon as I went to my 
stockbroker's web site, the warnings started to appear. Then it was just 
checking IP addresses and stuff.

Greg.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

ianG  writes:
>On 1/12/11 15:10 PM, Peter Gutmann wrote:
>> ianG  writes:
>>> Is this in anyway a cause for action in contract?  Is this a caused for
>>> revocation?
>> And given that you have to ask the MITM for the revocation information, how
>> would you revoke such a cert?
>
>Wait!  Mallory has delivered Alice a valid CA-signed-sub-CA-signed cert.
>That is the valid information, right?  There was nothing wrong the cert that
>wasn't seen, it is the new one that is at fault.

I assumed you were asking whether it was cause for revocation of the MITM CA.
Since you have to go via the MITM to do the blacklist check, you're hosed.

In any case though since you own the MITM CA all you need to do is leave out
the authorityInfoAccess and the clients won't even try and check.  Or make it
a CRL, and many won't bother checking even if the AIA is present (that's a
nice way to get a cheap CA cert for a year, buy it from a commercial CA, make
sure the revocation is done via a CRL, say you changed your mind and want your
money back, and you've got your own nearly-free CA cert for a year when
nothing bothers checking the CRL, as users of such CA certs have discovered in
the past :-).

Those were reasons #528 and #309 in the series.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[ianG]

On 1/12/11 15:10 PM, Peter Gutmann wrote:

ianG  writes:


Is this in anyway a cause for action in contract?  Is this a caused for
revocation?

And given that you have to ask the MITM for the revocation information, how
would you revoke such a cert?


Wait!  Mallory has delivered Alice a valid CA-signed-sub-CA-signed 
cert.  That is the valid information, right?  There was nothing wrong 
the cert that wasn't seen, it is the new one that is at fault.


Or, am I missing something?

And that was "Why blacklists suck for validity checks, reason #872 in a series
of 10,000 or so".  Returning you now to Max Geldray and Orchestra...



Gnash 3rd time lucky ... the list reply behaviour has changed..

iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

ianG  writes:

>Is this in anyway a cause for action in contract?  Is this a caused for
>revocation?

And given that you have to ask the MITM for the revocation information, how
would you revoke such a cert?

And that was "Why blacklists suck for validity checks, reason #872 in a series
of 10,000 or so".  Returning you now to Max Geldray and Orchestra...

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[ianG]

On 1/12/11 11:50 AM, Nathan Loofbourrow wrote:
On Wed, Nov 30, 2011 at 4:47 PM, Rose, Greg > wrote:


On 2011 Nov 30, at 16:44 , Adam Back wrote:

> 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.

Yes, there are. I encountered one in a hotel at Charles de Gaulle
airport a few weeks ago.


Yup. Boingo does this. Also, many employers.



Do these sub-CAs do MITMs on the certs from other CAs?

Is this in anyway a cause for action in contract?  Is this a caused for 
revocation?


If a CA is issuing sub-CAs for the purpose of MITMing, is this a reason 
to reset the entire CA?  Or is it ok to do MITMing under certain nice 
circumstances?


iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Adam Back  writes:

>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.
>
>[...]
>
>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?

It's a documented feature of a number of products that support this, see e.g.
http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-SSL_Feature_Module.pdf:

  In the Client DPI-SSL scenario, the SonicWALL UTM appliance typically does
  not own the certificates and private keys for the content it is inspecting.
  After the appliance performs DPI-SSL inspection, it re-writes the
  certificate sent by the remote server and signs this newly generated
  certificate with the certificate specified in the Client DPI-SSL
  configuration. By default, this is the SonicWALL certificate authority (CA)
  certificate, or a different certificate can be specified.

See my earlier message about my interest in getting samples of these MITM cert
chains when they're signed by CAs that chain up to public roots.  With the
SonicWall boxes you don't get that (unless you install your own CA cert in
there), but possibly someone like Boingo does it.

(Oh, and this also answers my earlier question of how they get the cert
details for the remote system if they don't know the FQDN that was used to
access it, all they need to do is pull them out of the genuine cert).

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Peter Gutmann]

Nathan Loofbourrow  writes:
>On Wed, Nov 30, 2011 at 4:47 PM, Rose, Greg  wrote:
>> On 2011 Nov 30, at 16:44 , Adam Back wrote:
>>
>> > 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.
>>
>> Yes, there are. I encountered one in a hotel at Charles de Gaulle airport
>> a few weeks ago.
>
>Yup. Boingo does this. Also, many employers.

Can someone send me a couple of certs (Amazon, Google, whatever) generated by 
one of these MITMs, specifically the full cert chain ("Save as PKCS #7" in the 
cert dialog of most browsers)?  I've got e.g. SonicWall ones where you have to 
trust the SonicWall CA cert, but presumably these are chained to a public CA 
so users don't get warnings, which means the proxies would have to be set up 
with more or less Comodogate-by-design CA certs.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Lee]

On 11/30/11, Rose, Greg  wrote:
>
> On 2011 Nov 30, at 16:44 , Adam Back wrote:
>
>> 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.
>
> Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a
> few weeks ago.

How did you know there was a MITM if it gave out a valid cert?

Thanks,
Lee


>
> Greg.
>
>>
>> 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
 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

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Nathan Loofbourrow]

On Wed, Nov 30, 2011 at 4:47 PM, Rose, Greg  wrote:

> On 2011 Nov 30, at 16:44 , Adam Back wrote:
>
> > 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.
>
> Yes, there are. I encountered one in a hotel at Charles de Gaulle airport
> a few weeks ago.


Yup. Boingo does this. Also, many employers.

n
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

[Rose, Greg]

On 2011 Nov 30, at 16:44 , Adam Back wrote:

> 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.

Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a few 
weeks ago.

Greg.

> 
> 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  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