[gnutls-help] User-level visibility of GnuTLS security and tuning

Ted Zlatanov tzz at lifelogs.com
Mon Dec 8 19:49:42 CET 2014


I am posting this question, originally from Lars Magne Ingebrigtsen,
about how much control Emacs should give its users.  RMS suggested we
ask experts like Simon Josefsson but I think it's even better to ask
here on the GnuTLS users mailing list.

FWIW my suggestion was to augment the GnuTLS priority strings. So the
user would say "NORMAL:NSM(medium,warn-rc4)" or something like that, but
we'd strip off the Emacs-specific things out before passing it to
GnuTLS.  But we're definitely open to suggestions.

Thanks!
Ted

----

Some other browsers are discussing switching off "weak" encryption in
one form or another.  I don't think that's a good idea, because
sometimes you want to visit web sites and don't care whether they use
"good" encryption or not.

But it might make sense to warn users that this is happening.  Perhaps
by default, perhaps only if they have switched to `high' security.

Candidates for these warnings would be

* low prime-bits used in the Diffie-Hellman handshake
* SSL1, SSL2 and SSL3
* usage of RC4 anywhere

Can anybody think of anything else that's considered "weak" these days?

Perhaps it might make sense to allow users to specify high-grained
security policies?  That is

(setq network-security-level '(starttls-downgrade ssl3 rc4))

or something?  Where `medium' would just be an alias for the default
things we check for...

On the other hand, perhaps not.  There's a temptation in Emacs to make
everything configurable, and I think that's a mistake.  Instead of
implementing a feature, we end up implementing a framework for creating
the feature, so the user ends up having to do all the work to get things
into a reasonable state.

And allowing users to configure stuff means that we don't have to be as
thorough in getting things just right, because "they can always switch
it off" or something, which is a cop-out.  And making stuff configurable
inevitably means that it's more prone to bugs, because there are code
paths almost never taken.




More information about the Gnutls-help mailing list