PKI Hierarchy Question

[Tom Ritter]

Hi all,

I have a path validation/hierarchy question - specifically wondering
about the path validation problems incurred on various clients.  (I
realize there's no definite answer besides "test it on all the clients
you care about".)

Imagine a four-cert hierarchy R -> A -> B -> L  (Root, Leaf, and two
Intermediates A & B).  R's Issuer and Subject will match, A's Issuer
will be R; B's Issuer will be A; and L's Issuer will be B.  R is a
root because of the dual combination of i) being installed in the
trust store and ii) matching the Subject/Issuer.  I send a chain of
A->B->L and clients are happy.

Now what happens when I decide that I want to trust A, but not
everything else off of R?

I tested it out, and installing A into the trust store on Firefox and
on my MacBook doesn't cause any problems with
Firefox/Chrome/Safari/curl. It seems the issuer/subject mismatch was
not an issue.  IS this technique recommended/not
recommended/documented or otherwise known to work or not work under
any circumstances?



The reverse question I have is in the event of Cross Certification.
Imagine a simpler hierarchy R -> A -> L.  However in this model, R is
cross-signed by other CA, C - and some clients only have C in their
trust store (while others have C and R).

In order for this to actually work, there would need to be two R's: R
(self-signed, where Issuer=Subject for a proper root) and R' (signed
by C, with Issuer=C).  Which works fine if you know under what
circumstances to send R and R', but poor L doesn't know when to send
which - right?

I'm also confused by all the extensions:
- AKI and SKI: Both R and R' would have the same SKI.  R's AKI points
to it's own SKI; R''s AKI would point to C's SKI.
- What will A's AIA point to?  Presumably R and not R'; correct?
Won't this cause problems?

Is there an elegant solution to this Cross Certification problem?  It
seems like Let's Encrypt is going to deal with this (albeit one level
removed), so what's the plan there?

-tom
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SSLKEYLOGFILE always enabled

[Tom Ritter]

(CC-ing DD as I found this bug he reported asking about the same
thing: https://bugzilla.mozilla.org/show_bug.cgi?id=908046)

On 17 July 2014 07:33, Patrick McManus  wrote:
> If there would be a reduced risk by scoping the feature to debug builds I
> would agree with you that it should be scoped. But Ryan suggests there
> isn't. My much less informed opinion tends to agree with him.

I agree that the level of access needed to exploit this feature is
identical to a level of access that could subvert the system in other
ways.  My concern is about the level of persistence needed to subvert
the system via this method or another. Even if an attacker needs the
same level of access, I don't believe that things that make an
attacker do more work, or be more noisy about their compromise, are
useless.

With the feature available, an attacker could ship SSL key information
off the system without binary modifications, filesystem modifications,
additional running processes, libraries loaded into memory. There's
not a lot of indicators of compromise, especially from a disk image
scenario - which is the usual forensics situation.

> I do want to point out that there is considerable value in the current
> arrangement - "developing" turns out to have layers. I'm a core firefox
> developer - Nick and I write the http/2 code and indeed we generally do it
> with debug builds. So its not relevant to my day to day coding.
>
> But a huge part of protocol development happens in the next layer - interop
> testing between different servers and on networks with different gear than
> is covered by the initial tests. That just takes lots of diversity and some
> time. The tail of this pretty much goes on forever - its not just new
> protocols.
>
> When a problem shows up on bugzilla a pcap is often the sensible course of
> action. These bug reporters are part of development too - hopefully they're
> running pre-release channels but sometimes they are not. They "dogfood" the
> product day to day and can't be using debug builds for that because its
> just too slow. Asking them to download a debug build to file a bug report
> will often result in no bug report. So that's the value of the current
> setup on the client side - it increases the debugability of the product.
> That's a big deal.

I understand, and I can certainly appreciate the convenience of this
as a debugging tool.  A search for Bugzilla for 'SSLKEYLOGFILE' in the
comments did not lead me to any results, although I did find the bugs
where it was changed[0] - it seems it may have been done more to
support Chrome than Firefox.

-tom

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=536474 and
https://bugzilla.mozilla.org/show_bug.cgi?id=762763
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SSLKEYLOGFILE always enabled

[Tom Ritter]

Is having it in by default useful enough to outweigh the risk?

When the Dual_EC_DRBG news stories were blowing it, it was revealed
that you could switch to it by just changing the Windows Registry.
It's a Windows-supported backdoor - no malicious code needs to stay
running on your system - just flip that bit, and delete yourself.
After that, you're all set.

Similarly, having this feature provided by default seems like it
provides a very easy, supported way to extract sensitive key data to
the filesystem or some other covert channel - without invalidating
package signatures, hashes of libraries or binaries, etc.

Don't get me wrong, it's invaluable to be able to use it for
debugging, but I question to need to have it enabled by default...

-tom

On 13 July 2014 19:23, Patrick McManus  wrote:
> I looked into this once, and iirc the change was made intentionally and I
> guess the documentation not updated. I just updated the wikis. Thanks.
>
>
> On Sun, Jul 13, 2014 at 10:30 AM, Роман Донченко  wrote:
>
>> Hello,
>>
>> > Projects/NSS/Key_Log_Format> states that:
>>
>> "Obviously this is only a debugging measure and is only enabled if NSS is
>> built with DEBUG and TRACE defined."
>>
>> Analogously, > Projects/NSS/Reference/NSS_environment_variables> says:
>>
>> "SSLKEYLOGFILE: [...] Note: The code must be built with TRACE defined to
>> use this functionality."
>>
>> However, the actual responsible code (> projects/nss/file/65605e800fd1/lib/ssl/sslsock.c#l2840>) doesn't seem to
>> be protected by any compile-time conditions (except for NSS_HAVE_GETENV).
>> And I've checked with a stock Ubuntu NSS package that SSLKEYLOGFILE works,
>> even though SSLDEBUGFILE doesn't.
>>
>> So who's in the wrong here? Is it a bug in the code, or in the
>> documentation?
>>
>> Roman.
>>
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Tom Ritter]

On 20 August 2013 14:26, Gervase Markham  wrote:
> On 19/08/13 04:07, Brian Smith wrote:
>>> When risk is there to a user of having a network eavesdropper able to
>>> tell that they are using a particular browser? If I had an exploit for a
>>> particular browser, I'd just try it anyway and see if it worked. That
>>> seems to be the normal pattern.
>>
>> One example is Tor: it tries to look like "a normal browser" so that it is
>> hard to detect that you are using Tor. And, if Tor is properly configured
>> then the network attacker will never see any non-TLS traffic.
>
> But if Tor Browser is based on Firefox, then it'll have the same TLS
> signature as Firefox anyway?

Not Tor Browser, but the Tor protocol itself.  For more information,
the spec document that deals with this is:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/198-restore-clienthello-semantics.txt

-tom
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Tom Ritter]

Thoughts, as a random passerby:

Of course I quite like the prioritization of (EC)DHE.

I think standardizing on a ciphersuite preference order with the aims
of reducing fingerprinting is a worthwhile (although wildly difficult)
goal for SSL _libraries_, but less so for browsers - to the point of
probably not being a fight worth fighting.  A web browser is so
incredibly complex it is next to impossible to browse with _soley_
over TLS, and the first HTTP request leaks the User Agent.  Even with
soley-over-TLS, requests for malware protection, the dynamic favorites
RSS feeds Firefox bundles (which I quite hate), and the auto-update
checks will leak the browser anyway.  Trying to avoid leaking the
preference to the network is admirable, and worthwhile in a library I
think, but the browser is a mighty beast to tackle.  There are lower
hanging fruit than the TLS handshake right now.

Weak DHE keys are a lurking problem.  Someone needs to survey the
internet.  (Unless there's a paper I'm not aware of...)

The Ephemeral ECDH certs is clever... but I feel like that's an awful
amount of engineering for the relatively few organizations who their
own Intermediate cert.  Unless this is a strategic push to encourage
Name Constraints.  In which case: Hmm.

"Future work: A comprehensive profile for browsers' use of TLS." - In
theory, this would be the domain of the relatively-new IETF PKI
Operations Working Group, which is being driven by a few browser folks
and many CA folks.

I would suggest another item for "Future Work" and that is trying to
work in protections against TLS downgrades.  This has been batted
around a few times in the past [0][1] but has never gained much
traction or agreement.

-tom

[0] https://www.ietf.org/mail-archive/web/tls/current/msg08861.html
[1] I'm failing to find a link, but Yoav had a trick he added to Opera
to prevent downgrade if the server supported secure renegotiation.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto