Additional network security

Additional network security

[Lars Magne Ingebrigtsen]

It kinda looks like the world didn't end when the NSM was switched on,
so perhaps it's time to discuss whether we should add additional
security, and if so, what and how.

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.

Users also gets frustrated by this endless variety.  I've seen people
say "oh, Emacs is so awful.  I have a 70K big .emacs, and then I
switched to Sublime Text, and I'm so much happier".  (Because they have
to take it or leave it.)

How about a new policy: Unless it really obviously should be
configurable, nothing get to be configurable until at least 100 users
have asked for it?  :-)

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

Re: Additional network security

[Stefan Monnier]

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

I don't see much need for it.

Emacs should mostly follow the default choices of the GnuTLS library.


        Stefan

Re: Additional network security

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Perhaps it might make sense to allow users to specify high-grained
>> security policies?
>
> I don't see much need for it.
>
> Emacs should mostly follow the default choices of the GnuTLS library.

I'm not quite sure what you mean.  GnuTLS is fine with using RC4, SSL1
and low prime bits, but these are things that security-conscious people
think are unsafe to use (if you need a high-security network connection
for something).

GnuTLS doesn't really set policy here; that's up to the application.

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

Re: Additional network security

[Stefan Monnier]

> GnuTLS doesn't really set policy here; that's up to the application.

Damn!


        Stefan

Re: Additional network security

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > GnuTLS doesn't really set policy here; that's up to the application.
 > 
 > Damn!

Welcome to the wild world of security.  Can't if you do, damned if you
don't.

Re: Additional network security

[Ted Zlatanov]

On Sun, 07 Dec 2014 14:35:30 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Stefan Monnier writes:
>> > GnuTLS doesn't really set policy here; that's up to the application.
>> 
>> Damn!

SJT> Welcome to the wild world of security.  Can't if you do, damned if you
SJT> don't.

Fortunately, it's not up to the application either. The user can choose
their policy:

gnutls-algorithm-priority is a variable defined in `gnutls.el'.
Its value is nil

Documentation:
If non-nil, this should be a TLS priority string.
For instance, if you want to skip the "dhe-rsa" algorithm,
set this variable to "normal:-dhe-rsa".

Given this precedent, I think it would make sense to offer some
fine-grained control over NSM checks as well, similar to
`gnutls-verify-error' as I mentioned.  We've gone Lispy with the NSM
configuration, but if we were consistent with the GnuTLS approach, the
NSM tuning would be simply a string like "paranoid:-crazy" (paranoid but
not crazy, heh heh).  This is still possible:

* map a symbol to its symbol-name
* parse NSM security levels like GnuTLS priority strings
* allow setting these strings per host regex
* PROFIT

WDYT?

Ted

Re: Additional network security

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Given this precedent, I think it would make sense to offer some
> fine-grained control over NSM checks as well, similar to
> `gnutls-verify-error' as I mentioned.  We've gone Lispy with the NSM
> configuration, but if we were consistent with the GnuTLS approach, the
> NSM tuning would be simply a string like "paranoid:-crazy" (paranoid but
> not crazy, heh heh).  This is still possible:
>
> * map a symbol to its symbol-name
> * parse NSM security levels like GnuTLS priority strings
> * allow setting these strings per host regex
> * PROFIT
>
> WDYT?

I think we should require 100 users demanding this before we implement
it.  :-)

But as for the defaults, do you agree with putting RC4, SSL<TLS1.0 and
low bits on `high'?  

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

Re: Additional network security

[Ted Zlatanov]

On Sun, 07 Dec 2014 17:41:06 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Given this precedent, I think it would make sense to offer some
>> fine-grained control over NSM checks as well, similar to
>> `gnutls-verify-error' as I mentioned.  We've gone Lispy with the NSM
>> configuration, but if we were consistent with the GnuTLS approach, the
>> NSM tuning would be simply a string like "paranoid:-crazy" (paranoid but
>> not crazy, heh heh).  This is still possible:
>> 
>> * map a symbol to its symbol-name
>> * parse NSM security levels like GnuTLS priority strings
>> * allow setting these strings per host regex
>> * PROFIT
>> 
>> WDYT?

LMI> I think we should require 100 users demanding this before we implement
LMI> it.  :-)

I am basing it on the way GnuTLS allows users to control things, not
inventing something new.  Asking for 100 Emacs users to agree on
anything will result in:

* 3 frameworks and 5 new one-letter packages
* 200+ posts arguing about obscure details
* at least 8 new bugs filed

so I really hope you lower the threshold to "would we use it?".

How about extending the GnuTLS priority string to also specify the NSM
level, DH bits, etc? So the user would say "NORMAL:NSM(medium,dh=1024)"
and we'd cut out all the NSM bits before passing it on to GnuTLS. If
there's nothing in the priority string, we'd look at
`network-security-level', that would be the out-of-the-box use case.

LMI> But as for the defaults, do you agree with putting RC4, SSL<TLS1.0 and
LMI> low bits on `high'?  

RC4 should be disallowed on medium IMO. I *think* it already is
disallowed in the default GnuTLS priority string.

I would disallow SSL 1, 2 on medium and 3 on high. The GnuTLS default
for priority string NORMAL is (in preference order) TLS protocols TLS
1.2, TLS1.1, TLS1.0, SSL3.0 according to
http://gnutls.org/manual/html_node/Priority-Strings.html so regardless
of the NSM level SSL 1 and 2 are dropped by default.

Ted

Re: Additional network security

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> How about extending the GnuTLS priority string to also specify the NSM
> level, DH bits, etc? So the user would say "NORMAL:NSM(medium,dh=1024)"
> and we'd cut out all the NSM bits before passing it on to GnuTLS. If
> there's nothing in the priority string, we'd look at
> `network-security-level', that would be the out-of-the-box use case.

I'm not sure we need to allow this to be customised at this fine-grained
level.  Does Firefox allow that, for instance?

> RC4 should be disallowed on medium IMO. I *think* it already is
> disallowed in the default GnuTLS priority string.

There are prominent web sites that only offer RC4, most famously the
video streams from Youtube.  (Because Google.)  

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

Re: Additional network security

[Ted Zlatanov]

On Sun, 07 Dec 2014 18:45:25 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> How about extending the GnuTLS priority string to also specify the NSM
>> level, DH bits, etc? So the user would say "NORMAL:NSM(medium,dh=1024)"
>> and we'd cut out all the NSM bits before passing it on to GnuTLS. If
>> there's nothing in the priority string, we'd look at
>> `network-security-level', that would be the out-of-the-box use case.

LMI> I'm not sure we need to allow this to be customised at this fine-grained
LMI> level.  Does Firefox allow that, for instance?

No.

>> RC4 should be disallowed on medium IMO. I *think* it already is
>> disallowed in the default GnuTLS priority string.

LMI> There are prominent web sites that only offer RC4, most famously the
LMI> video streams from Youtube.  (Because Google.)  

OK, I see.

Ted

Re: Additional network security

[chad]

On 07 Dec 2014, at 09:45, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> 
>> RC4 should be disallowed on medium IMO. I *think* it already is
>> disallowed in the default GnuTLS priority string.
> 
> There are prominent web sites that only offer RC4, most famously the
> video streams from Youtube.  (Because Google.)  


The internet suggests that there are non-RC4 options for YouTube
now. They're not yet supported in Firefox or IE, but that isn't
necessarily a problem here.

	https://securitypitfalls.wordpress.com/2014/06/24/youtube-now-with-less-rc4/

~Chad

Re: Additional network security

[Reiner Steib]

Lars Magne Ingebrigtsen wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> How about extending the GnuTLS priority string to also specify the NSM
>> level, DH bits, etc? So the user would say "NORMAL:NSM(medium,dh=1024)"
>> and we'd cut out all the NSM bits before passing it on to GnuTLS. If
>> there's nothing in the priority string, we'd look at
>> `network-security-level', that would be the out-of-the-box use case.
>
> I'm not sure we need to allow this to be customised at this fine-grained
> level.  Does Firefox allow that, for instance?

At least there's security.tls.version.min,
security.ssl3.ecdhe_ecdsa_rc4_128_sha, and several other security.*
prefs.  Dunno how these relate to Ted's suggestion.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Additional network security

[Ted Zlatanov]

On Thu, 18 Dec 2014 22:54:24 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> Lars Magne Ingebrigtsen wrote:
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> How about extending the GnuTLS priority string to also specify the NSM
>>> level, DH bits, etc? So the user would say "NORMAL:NSM(medium,dh=1024)"
>>> and we'd cut out all the NSM bits before passing it on to GnuTLS. If
>>> there's nothing in the priority string, we'd look at
>>> `network-security-level', that would be the out-of-the-box use case.
>> 
>> I'm not sure we need to allow this to be customised at this fine-grained
>> level.  Does Firefox allow that, for instance?

RS> At least there's security.tls.version.min,
RS> security.ssl3.ecdhe_ecdsa_rc4_128_sha, and several other security.*
RS> prefs.  Dunno how these relate to Ted's suggestion.

I think most of those can be specified with the GnuTLS priority string,
but it's somewhat obscure how to do it. The GnuTLS guys suggested we
link the `network-security-level' or another variable to some default
priority string combinations, following at least the pattern of
https://github.com/nmav/fedora-crypto-policies/tree/master/profiles

Thread reference:
http://thread.gmane.org/gmane.network.gnutls.general/3695/focus=3696

If anyone is interested in providing a patch, feel free.  My suggestion
would be to provide some customize defaults for `gnutls-priority-string'
that are tagged helpfully and maybe even make them symbols (so the
translation to actual priority string happens under the covers).

Ted

Re: Additional network security

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Sun, 07 Dec 2014 14:35:30 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 
 > 
 > SJT> Stefan Monnier writes:
 > >> > GnuTLS doesn't really set policy here; that's up to the application.
 > >> 
 > >> Damn!
 > 
 > SJT> Welcome to the wild world of security.  Can't if you do, damned if you
 > SJT> don't.
 > 
 > Fortunately, it's not up to the application either. The user can choose
 > their policy:

That's merely an even more virulent version of the problem that
bothers Stefan: folks who are not security specialists are making this
very complex decisions.

I don't think there's anything that can be done about it; it's just
hard.

Re: Additional network security

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Welcome to the wild world of security.  Can't if you do, damned if you
  > don't.

I suggest asking our experts, such as Simon Josefsson <simon@josefsson.org>
(maintainer of GNUtls), to advise us on what Emacs should do here.
-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Additional network security

[Ted Zlatanov]

On Sun, 07 Dec 2014 19:24:08 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS> I suggest asking our experts, such as Simon Josefsson <simon@josefsson.org>
RS> (maintainer of GNUtls), to advise us on what Emacs should do here.

Lars, could you repost the first message on this thread on the GnuTLS
users mailing list?  I can do it if you prefer.

Ted

Re: Additional network security

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Lars, could you repost the first message on this thread on the GnuTLS
> users mailing list?  I can do it if you prefer.

Please go ahead.

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

Re: Additional network security

[Lars Magne Ingebrigtsen]

Hm...  how does one ask GnuTLS whether the connection is SSL3?  And the
key exchange/encryption/MAC tuples actually used?

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

Re: Additional network security

[Lars Magne Ingebrigtsen]

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

> Hm...  how does one ask GnuTLS whether the connection is SSL3?  And the
> key exchange/encryption/MAC tuples actually used?

Never mind.  I found them in the gnutls source by grepping around for
likely _get_ functions.

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

Re: Additional network security

[Lars Magne Ingebrigtsen]

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

> Never mind.  I found them in the gnutls source by grepping around for
> likely _get_ functions.

Please let me know if today's gnutls.c changes break compilation on any
platforms.

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

Re: Additional network security

[Jens Lechtenboerger]

On 2014-12-05, Lars Magne Ingebrigtsen wrote:

> It kinda looks like the world didn't end when the NSM was switched on,

Quite to the contrary.  Many thanks!

> so perhaps it's time to discuss whether we should add additional
> security, and if so, what and how.

When a previously unknown certificate is presented to the user, the
DANE verification result could be shown as well.

Best wishes
Jens

Re: Additional network security

[Lars Magne Ingebrigtsen]

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

> When a previously unknown certificate is presented to the user, the
> DANE verification result could be shown as well.

Yes.  Somebody was talking about implementing DANE, but I'm not sure
what the status is...

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

Re: Additional network security

[Ted Zlatanov]

On Sat, 06 Dec 2014 18:33:04 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:
>> When a previously unknown certificate is presented to the user, the
>> DANE verification result could be shown as well.

LMI> Yes.  Somebody was talking about implementing DANE, but I'm not sure
LMI> what the status is...

We said it's not mature enough.  The latest GnuTLS definitely has some
functions for it, so it would make a fun project if anyone is
interested, but definitely not for general use.

Ted

Re: Additional network security

[Ted Zlatanov]

On Fri, 05 Dec 2014 16:10:19 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> There's a temptation in Emacs to make everything configurable, and
LMI> I think that's a mistake.

True.  That kind of madness belongs in Gnus. :P

Ted

Re: Additional network security

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> There's a temptation in Emacs to make everything configurable, and
> LMI> I think that's a mistake.
>
> True.  That kind of madness belongs in Gnus. :P

We learn from our mistakes.  :-)

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