Re: Network security manager

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But here's the feedback I need:

Haven't tested the code, but feel like I can weigh in on some of this:

>   if (verification & GNUTLS_CERT_INVALID)
>     warnings = Fcons (list2 (intern (":invalid"),

As far as I can tell from the GnuTLS example code, this is a flag that
GnuTLS sets when a cert is not trusted, rather than when it's malformed
(as I would have guessed from the name)? I.e. it doesn't ever appear on
its own?

>   if (verification & GNUTLS_CERT_REVOKED)
>     warnings = Fcons (list2 (intern (":revoked"),

This should probably be treated as fairly suspicious; since if the cert
has been explicitly revoked, there's probably a reason (not sure how
GnuTLS determines this second one; does it do OCSP revocation checks?).
SO carrying on would probably be... ill-advised. Perhaps by default fail
this completely (rather than ask), and optionally have a variable option
to override it?

>   if (verification & GNUTLS_CERT_SIGNER_NOT_FOUND)
>     warnings = Fcons (list2 (intern (":signer-not-found"),
>   if (verification & GNUTLS_CERT_SIGNER_NOT_CA)
>     warnings = Fcons (list2 (intern (":self-signed"),

Not sure which of these would indicate the common self-signed case?
Could probably be both...


>   if (verification & GNUTLS_CERT_INSECURE_ALGORITHM)
>     warnings = Fcons (list2 (intern (":insecure"),

I'd default to failing here as well; incidentally, does Emacs check the
cipher mode of the connection itself (I'm assuming this warning pertains
to the certificate itself, not the connection encryption). I have (setq
gnutls-algorithm-priority "PFS") in my .emacs, but AFAIK that is not the
default (and it does fail in some cases). For instance, in light of
POODLE, turning off SSLv3 completely would probably be a good idea, at
least as a default?

>   if (verification & GNUTLS_CERT_NOT_ACTIVATED)
>     warnings = Fcons (list2 (intern (":not-activated"),

This would probably be an issue with the clock?

>   if (verification & GNUTLS_CERT_EXPIRED)
>     warnings = Fcons (list2 (intern (":expired"),

I would expect this to be mostly benign (someone forgot to replace a
cert), but can also indicate someone stole an old cert and is using it
to MITM...

> Which one is the real "self-signed" message? It's an important
> distinction between a self-signed certificate and a forged
> certificate...

An important distinction, yes, but not one that can be made in general.
The main indicator of a forged certificate is if the presented
certificate does not match the one that is stored for the connection.
If it does, it's a possible forgery, if not, it's (probably) fine.
In the presence of rogue CAs, there's not really a better distinction to
be made, in the worst case.

However, in terms of UI we might be able to do a bit better. I'd advise
taking a look at the Certificate Patrol firefox extension
(http://patrol.psyced.org/), which does some heuristics to determine if
a changed certificate is benign or not. The main thing it does is to
look at the expiration date of the stored certificate; if that is
expired (or close to being), and the new certificate has the same CA as
the old one, it pops up a notice and continues. Otherwise, it interrupts
the connection and pops up a warning dialog with the changes highlighted
(including certificate fingerprint, CA chain etc). The common case
should be that an expired certificate is simply renewed with the same
CA, and this probably shouldn't be cause for alarm. The trouble is that
some popular sites use multiple certificates simultaneously
(corresponding to different endpoints in a server farm, I assume), which
can give some spurious popups from this algorithm.

Distinguishing these types of errors requires storing more than just the
certificate fingerprint, of course, so don't know if it's worth it. If
not, I'd treat any deviation from the stored value as suspicious.

There's also the issue of ports and addresses: If I connect to a mail
server on port 993 and get a certificate, there's a chance the same
certificate is also used for submitting mail on port 587. If so, warning
again could be avoided. On the other hand, folding the stored
certificate into just being stored per hostname would fail if it is
*not* the same certificate being used. So maybe treating ports as
completely separate (as I think you're doing now?) is best.

Finally, doing DANE verification (and trusting that more than the CA)
would be nice; but not sure how viably it is presently.


Sorry if that got a bit long; there seems to be quite a lot of cases to
consider here.

Will give the code a spin when I have chance :)

-Toke