Re: Network security manager

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 19 Nov 2014 06:43:39 +0100 Toke Høiland-Jørgensen <toke@toke.dk> wrote: 

TH> Ted Zlatanov <tzz@lifelogs.com> writes:
>> * uses SSH-style gnutls_store_pubkey() and gnutls_verify_stored_pubkey()
>> to DTRT and pins the public key rather than the certificate
>> fingerprint. The pub keys are stored by default in a way that lets the
>> user look them up by hostname, but we can customize that. And it's
>> mostly handled by GnuTLS internals as far as pubkey extraction and
>> verification.

TH> AFAICT this is functionally equivalent to what is currently in NSM;
TH> except it stores the public key rather than the fingerprint. I am not
TH> sure if there area any security implications to storing just the
TH> fingerprint...

See
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#What_Should_Be_Pinned.3F

Briefly, they say pinning the public key is better in most cases but is
not subject to expiration like a certificate.

Furthermore, see https://www.imperialviolet.org/2011/05/04/pinning.html
section "Why public key hashes, not certificate hashes?" on Google's
implementation and a stronger opinion.

Excerpt:

"In general, hashing certificates is the obvious solution, but the wrong
one. The problem is that CA certificates are often reissued: there are
multiple certificates with the same public key, subject name etc but
different extensions or expiry dates. Browsers build certificates chains
from a pool of certificates, bottom up, and an alternative version of a
certificate might be substituted for the one that you expect.

...

Conversely, public key hashes must be correct:

Browsers assume that the leaf certificate is fixed: it's always the
starting point of the chain. The leaf certificate contains a signature
which must be a valid signature, from its parent, for that certificate.
That implies that the public key of the parent is fixed by the leaf
certificate. So, inductively, the chain of public keys is fixed, modulo
truncation.

The only sharp edge is that you mustn't pin to a cross-certifying root.
For example, GoDaddy's root is signed by Valicert so that older clients,
which don't recognise GoDaddy as a root, still trust those certificates.
However, you wouldn't want to pin to Valicert because newer clients will
stop their chain at GoDaddy.

Also, we're hashing the SubjectPublicKeyInfo not the public key bit
string. The SPKI includes the type of the public key and some parameters
along with the public key itself. This is important because just hashing
the public key leaves one open to misinterpretation attacks. Consider a
Diffie-Hellman public key: if one only hashes the public key, not the
full SPKI, then an attacker can use the same public key but make the
client interpret it in a different group. Likewise one could force an
RSA key to be interpreted as a DSA key etc."

I am not a cryptographer so I hope some of those step in and suggest
what's best. To me from what I know and based on the cited references,
it seems it could be a choice but pinning the public key is better for
most people. They won't have to accept again every time the certificate
is reissued.

>> * does DANE auth (although I don't know the details on DANE, the
>> client implementation looks reasonable and Toke suggested it)

TH> I think the right thing to do would probably be to check DANE and use
TH> that as an additional input to the NSM dialog. I'd suggest the
TH> following:

TH> - Supply the DANE status as part of the 'certificate information' blurb
TH>   when popping up a prompt. For many (most?) setups this will be
TH>   'unknown' either because no DANE info is published in DNS or DNSSEC
TH>   validation fails (or both).

TH> - If valid DANE info is available *and* this doesn't match the shown
TH>   certificate, treat it as a reason to consider the certificate
TH>   insecure.

TH> I.e. treat a positive DANE verification as information to present to the
TH> user, and a verified failure as a cause for alarm. This corresponds to
TH> the current DANE RFC recommendations AFAICT...

Works for me. If we implement it in ELisp as Lars suggested it might
even be easy. Could you please open the feature request in the bug
tracker with your plan of action so we can keep it in mind?

>> * checks OCSP for revocations using cert_verify_ocsp() in the same
>> cli.c

TH> This would probably be a good idea to implement in any case.

I think Lars agrees, also with the "in ELisp if possible" caveat.  Can
you create a separate feature in the bug tracker?

On Wed, 19 Nov 2014 09:44:49 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> DANE and especially revocation checking is kinda slow though?  Which is
LMI> why Chrome doesn't do it.

It's definitely in the high-to-paranoid level, but if the level can be
enabled per site or per subnet, it would be ideal.

On Wed, 19 Nov 2014 09:55:00 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Unfortunately, this seems to have been introduced in a later version of
LMI> the library than what I have on my development machine, so I haven't
LMI> been able to test.

We can make such GnuTLS features optional or explicitly require the
latest if the feature is very appealing.  This one isn't to me :)  I
hate the "random art" and always disable it with SSH.

Ted