comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Gabor Toth]

>>>>> On Thu, 14 Feb 2013 23:33:19 +0100, Stef Walter <stefw at redhat.com> said:

> The main problem we're trying to solve is that the current situation
> with absolutely no sharing of trust policy between applications and
> crypto libraries on Linux is untenable. It's something we need to solve.
> We can solve it in two ways:

>  * An incremental approach, such as using stapled certificate
>    extensions.
>  * A rewrite all the verification algorithms approach.

> I'm unable to embark on the latter. The perfect is the enemy of the
> good. What we have is so *bad* that we can't wait for perfect to
> magically appear. It hasn't in the last decade and a half, although
> there have been some attempts

Can you point me to such attempts? Where did they fail?

> In addition I'm not trying to provide stop energy for you and/or others
> (listening or not) to go ahead and implement a perfect solution, with
> shared verification X.509 implementation, and so on. Please do go ahead.
> In fact I would be overjoyed if you were to pull it off, even if it
> means this (or other) work would be superseded or discarded.

> FWIW, much (most?) of Apple's security code is open source and could be
> ported. In fact I looked at doing that a while back when thinking about
> the problems of the multiple crypto libraries on Linux. But I got scared
> away by the nearly million lines of code involved. Others may be bolder
> than I.

I really want to see pinning functionality available to all applications, which
requires modifying the verification process, and can't be done with just stapled
extensions.

I've started working on a library which implements local/TOFU pinning (PoC code
is at git://git.tgbit.net/libcertpatrol)

This could also support other pinning protocols, providing storage and
verification functionality for them, and a higher-level
verify(chain, host, proto, port) function that checks all available pinning
protocols would be desirable as well.

Such a solution needs to be integrated with existing certificate verification
functionality, which also includes handling certificate overrides, so that
certain error codes of the verification function could be ignored on a per-peer
basis.

Performing verification could be done with functionality provided by an existing
implementation, with trust anchors supplied either by a pinning protocol or
otherwise by the shared system trust store. In both cases first all certificates
from the chain would be checked against a blacklist from the shared trust
store. When the verification returns with error flags, the override database is
consulted to determine which error conditions can be ignored.

>>> But the main problem with using this approach essentially necessitates a
>>> complete rewrite of all certificate validation logic, and is not easy to
>>> retrofit on existing crypto libraries. Likely this would be done in the
>>> context of combining all the X.509 certificate logic into a single
>>> implementation and having the libraries call into it.

This is what libpkix tries to do already as I see, or do you see any problems
with that approach? Perhaps integrating pinning functionality there would make
sense, if it can be used as a general X.509 validation library available to all
applications. GnuTLS also implements validation functionality that could be
used, but not sure how complete it is and how it compares with other
implementations. Using a separate validation library together with existing TLS
libraries would not be a problem, it's just the matter of converting the
certificate chain data structure used by the TLS library to the format used by
the validation library. In this case integration could happen at the application
level, or at the TLS abstraction layers provided by Qt or glib-networking.

>>> On 14.02.2013 00:46, Ryan Sleevi wrote:
>> For trust anchor management, yes. But you've introduced the notions of
>> pinning leafs as part of a TOFU (eg: Mozilla's "remember exception"),
>> and I'm trying to highlight that the problem space is not the same as
>> the TAMP setup - unless you're explicitly marking the leaf as a TAMP,
>> which throws out the rest of the verification model entirely (because
>> you don't verify attributes on anchors).

>> Regardless of the idealism, I think you will find, even with NSS, that
>> this would require rewriting many applications, and from what I
>> understand of the proposal (which may be mistaken), is not something
>> that will likely prove to be 'easy' to retrofit onto libpkix (or the
>> 'legacy' verification, which is still what Firefox uses). For trust
>> anchor inputs, yes, but if the notion is to add overrides for
>> intermediates, that's further messier (especially when layered with
>> multiple sources for attribute overrides).

If we want to make it really precise, ignored error codes would be associated
with a specific certificate in the chain, and a specific peer. This allows for
overriding problems with intermediaries as well.

Thinking about it more, pinning the end entity certificate for this purpose
would not be that appropriate, as later changes in trust anchors could alter the
verification result, making an overridden certificate invalid for a different reason.
Storing allowed error conditions would be a better solution that can also be
used together with pinning, as I described above.

-tg