[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network security manager

From: Lars Magne Ingebrigtsen
Subject: Re: Network security manager
Date: Wed, 19 Nov 2014 09:44:49 +0100
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Toke Høiland-Jørgensen <address@hidden> writes:

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

You'd hope not.  If there is, that's not a good fingerprint.  >"?

>> * does DANE auth (although I don't know the details on DANE, the
>>   client implementation looks reasonable and Toke suggested it)
> I think the right thing to do would probably be to check DANE and use
> that as an additional input to the NSM dialog. I'd suggest the
> following:
> - Supply the DANE status as part of the 'certificate information' blurb
>   when popping up a prompt. For many (most?) setups this will be
>   'unknown' either because no DANE info is published in DNS or DNSSEC
>   validation fails (or both).
> - If valid DANE info is available *and* this doesn't match the shown
>   certificate, treat it as a reason to consider the certificate
>   insecure.
> I.e. treat a positive DANE verification as information to present to the
> user, and a verified failure as a cause for alarm. This corresponds to
> the current DANE RFC recommendations AFAICT...
>> * checks OCSP for revocations using cert_verify_ocsp() in the same
>> cli.c

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

(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

reply via email to

[Prev in Thread] Current Thread [Next in Thread]