NSM certificate prompt

NSM certificate prompt

[Eli Zaretskii]

If I use eww to connect to www.google.com and then click on the "Sign
in" link, I get the following buffer displayed to me by the NSM:

  Certificate information
  Issued by:          Google Internet Authority G2
  Issued to:          Google Inc
  Hostname:           accounts.google.com
  Public key:         RSA, signature: RSA-SHA1
  Protocol:           TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD
  Security level:     Medium
  Valid:              From 2014-12-03 to 2015-03-03


  The TLS connection to accounts.google.com:443 is insecure for the
  following reasons:

  certificate signer was not found (self-signed)
  certificate could not be verified

This is in Emacs 25.0.50 built with GnuTLS 3.3.11 on MS-Windows.
Other Web browsers on this system don't have any trouble displaying
that page.  Do others see this on other systems?  Is my system/Emacs
somehow misconfigured wrt certificates?

TIA

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>   Issued by:          Google Internet Authority G2
>   Issued to:          Google Inc
>   Hostname:           accounts.google.com

If I go to https://accounts.google.com, I do not get any warnings.
(This is on Debian.)  Is it possible that your CA bundle doesn't include
the Google Internet Authority G2 CA root certificate?

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

Re: NSM certificate prompt

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> If I use eww to connect to www.google.com and then click on the "Sign
> in" link, I get the following buffer displayed to me by the NSM:
>
>   Certificate information
>   Issued by:          Google Internet Authority G2
>   Issued to:          Google Inc
>   Hostname:           accounts.google.com
>   Public key:         RSA, signature: RSA-SHA1
>   Protocol:           TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD
>   Security level:     Medium
>   Valid:              From 2014-12-03 to 2015-03-03
>
>
>   The TLS connection to accounts.google.com:443 is insecure for the
>   following reasons:
>
>   certificate signer was not found (self-signed)
>   certificate could not be verified
>
> This is in Emacs 25.0.50 built with GnuTLS 3.3.11 on MS-Windows.
> Other Web browsers on this system don't have any trouble displaying
> that page.  Do others see this on other systems?  Is my system/Emacs
> somehow misconfigured wrt certificates?

"Other Web browsers" carry builtin certificates. For example if you use
Firefox, click on the lock icon heading the url. Click on "More
Information". Click on "View Certificate". In the "Details" tab, you'll
see that "Google Internet Authority G2" is signed by "GeoTrust Global
CA", which is signed by "Equifax Secure CA". The latter one is a builtin
certificate Firefox knows about, so it is a valid certificate chain.

> TIA

Best regards, Michael.

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> "Other Web browsers" carry builtin certificates.

We should do that too, I guess.  

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

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 16:12:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   Issued by:          Google Internet Authority G2
> >   Issued to:          Google Inc
> >   Hostname:           accounts.google.com
> 
> If I go to https://accounts.google.com, I do not get any warnings.
> (This is on Debian.)  Is it possible that your CA bundle doesn't include
> the Google Internet Authority G2 CA root certificate?

GnuTLS on Windows doesn't by default use the CA bundle, it uses the
Windows's own certificate store.  I don't know how to examine that
store, except by writing a program that accesses it.  If the
conclusion is that this is the source of the problem, I'll do that,
but I wonder how both MS IE and Firefox have no problems with that on
the same system.

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 16:27:32 +0100
> 
> "Other Web browsers" carry builtin certificates.

Does that include MS IE?  Because it, too, doesn't have any problems
with HTTPS URLs, on that very system.

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> GnuTLS on Windows doesn't by default use the CA bundle, it uses the
> Windows's own certificate store.  I don't know how to examine that
> store, except by writing a program that accesses it.  If the
> conclusion is that this is the source of the problem, I'll do that,
> but I wonder how both MS IE and Firefox have no problems with that on
> the same system.

Is Emacs/gnutls able to access the certificate store?  That is, is this
the only https site you get warnings?

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

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 13 Dec 2014 16:27:32 +0100
> Cc: emacs-devel@gnu.org
> 
> "Other Web browsers" carry builtin certificates. For example if you use
> Firefox, click on the lock icon heading the url. Click on "More
> Information". Click on "View Certificate". In the "Details" tab, you'll
> see that "Google Internet Authority G2" is signed by "GeoTrust Global
> CA", which is signed by "Equifax Secure CA". The latter one is a builtin
> certificate Firefox knows about, so it is a valid certificate chain.

If I do the same for savannah.gnu.org in IE, it shows the following
certification path:

   UTN-USERFirst-Hardware
    Gandi Standard SSL CA
     savannah.gnu.org

Emacs's eww prompts me about https://savannah.gnu.org and shows me
this information about its certificate:

  Certificate information
  Issued by:          Gandi Standard SSL CA
  Issued to:          Domain Control Validated
  Hostname:           savannah.gnu.org
  Public key:         RSA, signature: RSA-SHA1
  Protocol:           TLS1.0, key: RSA, cipher: AES-128-CBC, mac: SHA1
  Security level:     Medium
  Valid:              From 2014-03-05 to 2015-03-05


  The TLS connection to savannah.gnu.org:443 is insecure for the
  following reasons:

  certificate signer was not found (self-signed)
  certificate could not be verified

which also talks about Gandi Standard SSL CA.  So I wonder why GnuTLS
isn't happy with this, while MS IE is.  Am I missing something?

(Please be gentle: I know nothing about Internet security and
certificates.)

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 17:04:17 +0100
> 
> Is Emacs/gnutls able to access the certificate store?

How do I tell?

> That is, is this the only https site you get warnings?

I see the same for savannah.gnu.org, github.com, and
www.facebook.com/GitHub.  If you have other https sites you want me to
check, please tell.  But it looks like this happens for pretty much
any https URL.  And in each case, Emacs does show me the authority
that issued the certificate, but always claims that "certificate
signer was not found" and "certificate could not be verified".

Re: NSM certificate prompt

[Michael Albinus]

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

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> "Other Web browsers" carry builtin certificates.
>
> We should do that too, I guess.  

I don't think so. It will be an endless story, because this will require
permanent updates. Certificates have a limited life (see the Expires
attribute); new certificates must be added regularly, and even
established certificates must be revoked sometimes (if the CA has been
hacked, for example).

A better solution might be to use system-installed certificates. For
example, Debian offers the package ca-certificates. It installs known
certificates at /usr/share/ca-certificates, which could be used.
See also /usr/share/doc/ca-certificates/README.Debian.

Similar packages might exist for other systems. Don't know, whether
gnutls uses them already by default.

Best regards, Michael.

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 17:57:03 +0100
> 
> A better solution might be to use system-installed certificates. For
> example, Debian offers the package ca-certificates. It installs known
> certificates at /usr/share/ca-certificates, which could be used.
> See also /usr/share/doc/ca-certificates/README.Debian.
> 
> Similar packages might exist for other systems. Don't know, whether
> gnutls uses them already by default.

It does, and I do have the certificate bundle installed on the system
I'm experiencing this.  But I configured GnuTLS to use the Windows's
certificate store for now, so the bundle is not used in my build of
GnuTLS.  I can change that, but I don't yet have sufficient
information to claim that this is the root cause for the problem.  See
my other messages.  I'd like to understand the problem more before I
decide to dig into the code or ask GnuTLS developers a question.  I
still feel this is somehow a configuration issue, or maybe Emacs
doesn't use GnuTLS correctly, at least on Windows.

Re: NSM certificate prompt

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> If I do the same for savannah.gnu.org in IE, it shows the following
> certification path:
>
>    UTN-USERFirst-Hardware
>     Gandi Standard SSL CA
>      savannah.gnu.org
>
> Emacs's eww prompts me about https://savannah.gnu.org and shows me
> this information about its certificate:
>
>   Certificate information
>   Issued by:          Gandi Standard SSL CA
>   Issued to:          Domain Control Validated
>   Hostname:           savannah.gnu.org
>   Public key:         RSA, signature: RSA-SHA1
>   Protocol:           TLS1.0, key: RSA, cipher: AES-128-CBC, mac: SHA1
>   Security level:     Medium
>   Valid:              From 2014-03-05 to 2015-03-05
>
>
>   The TLS connection to savannah.gnu.org:443 is insecure for the
>   following reasons:
>
>   certificate signer was not found (self-signed)
>   certificate could not be verified
>
> which also talks about Gandi Standard SSL CA.  So I wonder why GnuTLS
> isn't happy with this, while MS IE is.  Am I missing something?

Likely for the same reason as Firefox: it knows the certificate(s) which
have been used for signing "Gandi Standard SSL CA". In your case, it is
"UTN-USERFirst-Hardware".

In Firefox, the chain is shown as

  AddTrust External CA Root
   UTN-USERFirst-Hardware
    Gandi Standard SSL CA
     savannah.gnu.org

One hop more ...

> (Please be gentle: I know nothing about Internet security and
> certificates.)

Not a big deal: Every certificate must be signed by another one
(certificate authority, or CA), which gives you the trust that this
certificate is valid. The CA certificate must be signed ("guarantee that
it is true") by another one, and so on. This is called a chain of trust.

In order not to create an infinite chain, there are so-called Root CAs,
which are "known by default". If any chain ends in such a root
certificate, you know that the initial certificate is true.

The problem is to distribute and maintain such root
certificates. Browsers have them built-in, but I don't believe Emacs
(eww) shall do so.

Best regards, Michael.

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I see the same for savannah.gnu.org, github.com, and
> www.facebook.com/GitHub.  If you have other https sites you want me to
> check, please tell.  But it looks like this happens for pretty much
> any https URL.  And in each case, Emacs does show me the authority
> that issued the certificate, but always claims that "certificate
> signer was not found" and "certificate could not be verified".

Yeah, that means that gnutls isn't able to access any root CAs from the
certificate store.  I'm wholly unfamiliar with how that's supposed to
work under Windows, but perhaps somebody else knows how to debug this?

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

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I don't think so. It will be an endless story, because this will require
> permanent updates.

It's what all other web browsers do.

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

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 13 Dec 2014 18:06:37 +0100
> Cc: emacs-devel@gnu.org
> 
> In order not to create an infinite chain, there are so-called Root CAs,
> which are "known by default". If any chain ends in such a root
> certificate, you know that the initial certificate is true.
> 
> The problem is to distribute and maintain such root
> certificates. Browsers have them built-in, but I don't believe Emacs
> (eww) shall do so.

GnuTLS on Windows uses the CertEnumCertificatesInStore API to retrieve
all the Root and Certification Authority certificates known to the
system.  I suppose at least IE uses the same API, so I wonder how come
GnuTLS fails to validate the certificates, while IE succeeds.

I guess some debugging is in order.

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 13 Dec 2014 18:29:06 +0100
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
> > I don't think so. It will be an endless story, because this will require
> > permanent updates.
> 
> It's what all other web browsers do.

A middle ground would be to offer to perform an update of the
certificates when validation fails.

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> A middle ground would be to offer to perform an update of the
> certificates when validation fails.

Yes, that would be nice.  We'd have to have a secure way to retrieve
those certificates, though.  Perhaps we could use GNU ELPA for this?
Wasn't there some work done on signing packages?

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

Re: NSM certificate prompt

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem is to distribute and maintain such root
>> certificates. Browsers have them built-in, but I don't believe Emacs
>> (eww) shall do so.
>
> GnuTLS on Windows uses the CertEnumCertificatesInStore API to retrieve
> all the Root and Certification Authority certificates known to the
> system.  I suppose at least IE uses the same API, so I wonder how come
> GnuTLS fails to validate the certificates, while IE succeeds.

As usual, I cannot speak about MS Windows. But even if IE uses the same
API, it might read the root certificates from somewhere else.

And like other browsers, it might also carry builtin root certificates inside.

Best regards, Michael.

Re: NSM certificate prompt

[Eli Zaretskii]

> Date: Sat, 13 Dec 2014 20:01:59 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> GnuTLS on Windows uses the CertEnumCertificatesInStore API to retrieve
> all the Root and Certification Authority certificates known to the
> system.  I suppose at least IE uses the same API, so I wonder how come
> GnuTLS fails to validate the certificates, while IE succeeds.
> 
> I guess some debugging is in order.

Ha!  It's very simple: we don't call the GnuTLS function that adds
system's default trusted CAs to the data used for certificate
verification.  The simple patch below solves the problem for me.

Any objections to installing this?  Including on the branch?  Ted?

What about Posix systems -- won't calling
gnutls_certificate_set_x509_system_trust remove the need to load
gnutls-trustfiles explicitly for every TLS connection?

diff --git a/src/gnutls.c b/src/gnutls.c
index ad4d997..bbe5d49 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -103,6 +103,11 @@ enum extra_peer_verification
 DEF_GNUTLS_FN (int, gnutls_certificate_set_x509_key_file,
 	       (gnutls_certificate_credentials_t, const char *, const char *,
 		gnutls_x509_crt_fmt_t));
+#if GNUTLS_VERSION_MAJOR +					\
+  (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3
+DEF_GNUTLS_FN (int, gnutls_certificate_set_x509_system_trust,
+	       (gnutls_certificate_credentials_t));
+#endif
 DEF_GNUTLS_FN (int, gnutls_certificate_set_x509_trust_file,
 	       (gnutls_certificate_credentials_t, const char *,
 		gnutls_x509_crt_fmt_t));
@@ -227,6 +232,10 @@ enum extra_peer_verification
   LOAD_GNUTLS_FN (library, gnutls_certificate_set_verify_flags);
   LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_crl_file);
   LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_key_file);
+#if GNUTLS_VERSION_MAJOR +					\
+  (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3
+  LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_system_trust);
+#endif
   LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_trust_file);
   LOAD_GNUTLS_FN (library, gnutls_certificate_type_get);
   LOAD_GNUTLS_FN (library, gnutls_certificate_verify_peers2);
@@ -314,6 +323,10 @@ enum extra_peer_verification
 #define fn_gnutls_certificate_set_verify_flags	gnutls_certificate_set_verify_flags
 #define fn_gnutls_certificate_set_x509_crl_file	gnutls_certificate_set_x509_crl_file
 #define fn_gnutls_certificate_set_x509_key_file gnutls_certificate_set_x509_key_file
+#if GNUTLS_VERSION_MAJOR +					\
+  (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3
+#define fn_gnutls_certificate_set_x509_system_trust gnutls_certificate_set_x509_system_trust
+#endif
 #define fn_gnutls_certificate_set_x509_trust_file gnutls_certificate_set_x509_trust_file
 #define fn_gnutls_certificate_type_get		gnutls_certificate_type_get
 #define fn_gnutls_certificate_verify_peers2	gnutls_certificate_verify_peers2
@@ -1308,6 +1321,14 @@ one trustfile (usually a CA bundle).  */)
       int file_format = GNUTLS_X509_FMT_PEM;
       Lisp_Object tail;
 
+#if GNUTLS_VERSION_MAJOR +					\
+  (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3
+      ret = fn_gnutls_certificate_set_x509_system_trust (x509_cred);
+      if (ret < GNUTLS_E_SUCCESS)
+	GNUTLS_LOG2i (4, max_log_level, "setting system trust failed with code ",
+		      ret);
+#endif
+
       for (tail = trustfiles; CONSP (tail); tail = XCDR (tail))
 	{
 	  Lisp_Object trustfile = XCAR (tail);

Re: NSM certificate prompt

[Michael Albinus]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> A middle ground would be to offer to perform an update of the
>> certificates when validation fails.
>
> Yes, that would be nice.  We'd have to have a secure way to retrieve
> those certificates, though.  Perhaps we could use GNU ELPA for this?
> Wasn't there some work done on signing packages?

That's not the crucial point. A root certificate could be compromised,
and with this compromised root certificate a validation might still
succeed when it shouldn't. ELPA does not has the means to urge a package
update of the hypothetical ca-certificates package, when a new version
appears.

And who from the core Emacs team will feel responsible to produce a new
version of that package when necessary? This must happen short-term,
which means a small security team of Emacs must observe relevant mailing
list and alike, and must react in time.

I don't believe this belongs to Emacs' core functionality. It might be
better to investigate first, whether there exist already an
infrastructure on the different supported systems we could use. Like the
Debian package I've mentioned already.

Best regards, Michael.

Re: NSM certificate prompt

[Ted Zlatanov]

On Sat, 13 Dec 2014 21:13:50 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Ha!  It's very simple: we don't call the GnuTLS function that adds
EZ> system's default trusted CAs to the data used for certificate
EZ> verification.  The simple patch below solves the problem for me.

EZ> Any objections to installing this?  Including on the branch?  Ted?

No problem for me, as long as it works.  This function was not available
back when we did the first cut of the GnuTLS integration.

I'd make it the default, but through the trustfiles list: if the symbol
'system is found in the list, we load the system trust. And that's the
default.  But the user can add their own trustfiles, as they do now.

EZ> What about Posix systems -- won't calling
EZ> gnutls_certificate_set_x509_system_trust remove the need to load
EZ> gnutls-trustfiles explicitly for every TLS connection?

I think the user should be able to customize the trustfiles so the two
are not exclusive.  I don't know about once-per-connection either, is
that a GnuTLS feature with gnutls_certificate_set_x509_system_trust()?

Ted

Re: NSM certificate prompt

[Ted Zlatanov]

On Sat, 13 Dec 2014 20:16:30 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>> A middle ground would be to offer to perform an update of the
>>> certificates when validation fails.
>> 
>> Yes, that would be nice.  We'd have to have a secure way to retrieve
>> those certificates, though.  Perhaps we could use GNU ELPA for this?
>> Wasn't there some work done on signing packages?

We have signed packages (but you need GnuPG installed).

The last time I brought up storing the CA certificates inside Emacs,
there was no interest in maintaining that facility. Similarly, we don't
package GnuTLS with Emacs, so the user has to update it manually (we
also discussed this with Eli a while back).

MA> That's not the crucial point. A root certificate could be compromised,
MA> and with this compromised root certificate a validation might still
MA> succeed when it shouldn't. ELPA does not has the means to urge a package
MA> update of the hypothetical ca-certificates package, when a new version
MA> appears.

Well, typically CRLs are used for such urgent revocations, right? So
those could be supported specifically. And we could say that
`network-security-level' of 'high or above requires having the latest
GNU ELPA certificates package. I think it's technically possible.

MA> I don't believe this belongs to Emacs' core functionality. It might be
MA> better to investigate first, whether there exist already an
MA> infrastructure on the different supported systems we could use. Like the
MA> Debian package I've mentioned already.

It's definitely easier to rely on the host OS.  I don't know if it's
always the right thing because not all platforms are up to date, and the
user may not be able to control the CA store updates.  The GnuTLS
updates are handled similarly.

Ted

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 13 Dec 2014 14:47:32 -0500
> 
> I'd make it the default, but through the trustfiles list: if the symbol
> 'system is found in the list, we load the system trust. And that's the
> default.  But the user can add their own trustfiles, as they do now.

What would be the reason for the user to remove 'system from the list?
If a user is somehow not happy about system trust data, she should
customize her system (if she is authorized), not Emacs.  E.g., add a
list of blacklisted certificates, remove certificates from the bundle,
etc.

> EZ> What about Posix systems -- won't calling
> EZ> gnutls_certificate_set_x509_system_trust remove the need to load
> EZ> gnutls-trustfiles explicitly for every TLS connection?
> 
> I think the user should be able to customize the trustfiles so the two
> are not exclusive.

To add certificates, I agree.  But to remove certificates through
Emacs?  That sounds backwards to me.

> I don't know about once-per-connection either, is that a GnuTLS
> feature with gnutls_certificate_set_x509_system_trust()?

No, I meant that we do this inside gnutls-boot, which AFAIU is invoked
for each new TLS connection.

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What would be the reason for the user to remove 'system from the list?
> If a user is somehow not happy about system trust data, she should
> customize her system (if she is authorized), not Emacs.

Yeah, I agree.

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

Re: NSM certificate prompt

[Ted Zlatanov]

On Sat, 13 Dec 2014 22:06:55 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 13 Dec 2014 14:47:32 -0500
>> 
>> I'd make it the default, but through the trustfiles list: if the symbol
>> 'system is found in the list, we load the system trust. And that's the
>> default.  But the user can add their own trustfiles, as they do now.

EZ> What would be the reason for the user to remove 'system from the list?
EZ> If a user is somehow not happy about system trust data, she should
EZ> customize her system (if she is authorized), not Emacs.  E.g., add a
EZ> list of blacklisted certificates, remove certificates from the bundle,
EZ> etc.

I don't see how it's OK to exclude users who are not authorized to
customize their systems.  This is a common case.

Another case is where the system is out of date and you don't have the
option of updating it, because it's too old or the update server is
down.

There's also the case that you may not want to use the host OS's trust
store for your own reasons.  That should not be a struggle.  Emacs is
not a all-in-one web browser, it's a platform.  Don't take away the
users' choice of who they trust.

Furthermore, GnuTLS until recently didn't have this functionality and
somehow we survived. So it's not essential.

But even if we decide to make 'system the only option, we'd have "if
you're running GnuTLS 3.x or older, you'll get this behavior, but with
3.y or newer, another behavior." I think it's pretty unpleasant behavior
to dynamically toggle who you trust based on system library versions. So
unless we *only* support GnuTLS versions that have this functionality,
I'm strongly against making it the only option when it's available.

Finally, we have to consider backward compatibility.  Users who have
customized their trustfiles should not be surprised.  We can put
warnings in NEWS and blame the users when they don't read them, but I
think it's much nicer to preserve the users' customizations.

Ted

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 13 Dec 2014 20:38:20 -0500
> 
> EZ> What would be the reason for the user to remove 'system from the list?
> EZ> If a user is somehow not happy about system trust data, she should
> EZ> customize her system (if she is authorized), not Emacs.  E.g., add a
> EZ> list of blacklisted certificates, remove certificates from the bundle,
> EZ> etc.
> 
> I don't see how it's OK to exclude users who are not authorized to
> customize their systems.  This is a common case.

If she's not authorized, she doesn't necessarily know what she is
doing.  This is security, right?

> Another case is where the system is out of date and you don't have the
> option of updating it, because it's too old or the update server is
> down.

This case means the user should want to _add_ certificates, not remove
the system ones.

> There's also the case that you may not want to use the host OS's trust
> store for your own reasons.  That should not be a struggle.  Emacs is
> not a all-in-one web browser, it's a platform.  Don't take away the
> users' choice of who they trust.

No other browser I know of allows that.

> Furthermore, GnuTLS until recently didn't have this functionality and
> somehow we survived. So it's not essential.

We survived because we do the equivalent by reading gnutls-trustfiles.

> But even if we decide to make 'system the only option

That's not my suggestion.  My suggestion is always to use system trust
(when it's available), and in addition allow the user to customize
gnutls-trustfiles.  The only issue is whether to have 'system' in
gnutls-trustfiles and allow its removal.

> we'd have "if you're running GnuTLS 3.x or older, you'll get this
> behavior, but with 3.y or newer, another behavior."

Yes, and why is that a problem?  Differences in behavior in different
versions exist whether we want it or not.

> I think it's pretty unpleasant behavior to dynamically toggle who
> you trust based on system library versions. So unless we *only*
> support GnuTLS versions that have this functionality, I'm strongly
> against making it the only option when it's available.
> 
> Finally, we have to consider backward compatibility.  Users who have
> customized their trustfiles should not be surprised.  We can put
> warnings in NEWS and blame the users when they don't read them, but I
> think it's much nicer to preserve the users' customizations.

Fine.  I'm going to make this a Windows-only code, and we can then
stop arguing.

Re: NSM certificate prompt

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> There's also the case that you may not want to use the host OS's trust
>> store for your own reasons.  That should not be a struggle.  Emacs is
>> not a all-in-one web browser, it's a platform.  Don't take away the
>> users' choice of who they trust.
>
> No other browser I know of allows that.

In Firefox, it's edit->preferences->advanced->certificates, and you can
remove any CAs you want there.

Not that I've ever heard of anybody using that.

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

Re: NSM certificate prompt

[Ted Zlatanov]

On Sun, 14 Dec 2014 05:46:15 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 13 Dec 2014 20:38:20 -0500
>> 
EZ> What would be the reason for the user to remove 'system from the list?
EZ> If a user is somehow not happy about system trust data, she should
EZ> customize her system (if she is authorized), not Emacs.  E.g., add a
EZ> list of blacklisted certificates, remove certificates from the bundle,
EZ> etc.
>> 
>> I don't see how it's OK to exclude users who are not authorized to
>> customize their systems.  This is a common case.

EZ> If she's not authorized, she doesn't necessarily know what she is
EZ> doing.  This is security, right?

The authentication and authorization structure of the host system
targets different risks. I've often had the need to build and install
binaries or dynamically updated external package systems like oh-my-zsh
for instance. Even when I was the host system's manager, it didn't
always make sense to make system-level changes to accommodate one user's
preferences and needs.

>> Another case is where the system is out of date and you don't have the
>> option of updating it, because it's too old or the update server is
>> down.

EZ> This case means the user should want to _add_ certificates, not remove
EZ> the system ones.

There have been several cases where users wanted to remove certificates
signed by a compromised certificate authority before updated CA
certificate OS packages were available. Sometimes a few hours can be
critical in these situations.

While CRL support is a good way to deal with this in general, I still
think giving the user the option to manage their trustfiles is valuable.
But we should definitely try to support CRLs or DANE more urgently,
rather than expecting the user to manage trustfiles and certificate
revocations.

>> But even if we decide to make 'system the only option

EZ> That's not my suggestion.  My suggestion is always to use system trust
EZ> (when it's available), and in addition allow the user to customize
EZ> gnutls-trustfiles.  The only issue is whether to have 'system' in
EZ> gnutls-trustfiles and allow its removal.

OK, sorry, I was arguing with a straw man. I think there's a better
approach, below...

EZ> Fine.  I'm going to make this a Windows-only code, and we can then
EZ> stop arguing.

Please add the code unconditionally as you planned. I think it will be
an improvement that way. I will then add code to make the transition
easier after your patch:

* add a featurep or a function to GnuTLS that tells us if that system
  function is available

* when it's available, default the trustfiles to nil

* when it's not available, use the old trustfiles default

* add a specific boolean option to disable that system function, off by default

* improve messaging to tell the user what trustfiles we're loading

* update NEWS, docs, etc.

I hope that's more agreeable.

Ted

Re: NSM certificate prompt

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> While CRL support is a good way to deal with this in general, I still
> think giving the user the option to manage their trustfiles is valuable.
> But we should definitely try to support CRLs or DANE more urgently,
> rather than expecting the user to manage trustfiles and certificate
> revocations.

CRLs are a good thing, in theory. But they work only when you are
online, and when you are able to retrieve a proper CRL from the CA. If
the CA is blocked by whatever means, CRLs don't work.

DANE uses an indepedent way in order to give you trust into a given
certificate (via DNSSec). However, I don't know how much it is supported
already, by both the servers and by gnutls as client.

I do not object to support CRLs and DANE, but we shouldn't expect
perfect trust then.

> Ted

Best regards, Michael.

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 14 Dec 2014 09:16:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> There's also the case that you may not want to use the host OS's trust
> >> store for your own reasons.  That should not be a struggle.  Emacs is
> >> not a all-in-one web browser, it's a platform.  Don't take away the
> >> users' choice of who they trust.
> >
> > No other browser I know of allows that.
> 
> In Firefox, it's edit->preferences->advanced->certificates, and you can
> remove any CAs you want there.

Yes, I know.  But that's one certificate at a time.  The equivalent
would be to add a certificate to a blacklist, or remove its file from
the certificate directory.

What I meant is a check-box saying "disregard all system-wide
certificates" or some such.

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sun, 14 Dec 2014 06:34:32 -0500
> 
> Please add the code unconditionally as you planned. I think it will be
> an improvement that way.

Done in e99ce63 on master.

> I will then add code to make the transition easier after your patch:
> 
> * add a featurep or a function to GnuTLS that tells us if that system
>   function is available
> 
> * when it's available, default the trustfiles to nil
> 
> * when it's not available, use the old trustfiles default
> 
> * add a specific boolean option to disable that system function, off by default

Please mention in the docstring of that option that disabling the
system function on MS-Windows requires the user to install a
certificate bundle and point gnutls-trustfiles to the place where it
is installed.

> * improve messaging to tell the user what trustfiles we're loading
> 
> * update NEWS, docs, etc.
> 
> I hope that's more agreeable.

Yes, thanks in advance.

Re: NSM certificate prompt

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, I know.  But that's one certificate at a time.  The equivalent
> would be to add a certificate to a blacklist, or remove its file from
> the certificate directory.
>
> What I meant is a check-box saying "disregard all system-wide
> certificates" or some such.

To the best of my knowledge, no other browsers use the system's
certificates.

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

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 19 Dec 2014 13:14:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, I know.  But that's one certificate at a time.  The equivalent
> > would be to add a certificate to a blacklist, or remove its file from
> > the certificate directory.
> >
> > What I meant is a check-box saying "disregard all system-wide
> > certificates" or some such.
> 
> To the best of my knowledge, no other browsers use the system's
> certificates.

If they go to /etc/ssl/ on Posix hosts, then they do.

Re: NSM certificate prompt

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Lars Ingebrigtsen  Date: Fri, 19 Dec 2014 13:14:51 +0100
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

 >>> What I meant is a check-box saying "disregard all system-wide
 >>> certificates" or some such.

 >> To the best of my knowledge, no other browsers use the system's
 >> certificates.

 > If they go to /etc/ssl/ on Posix hosts, then they do.

	Unless I be mistaken, the newer versions of Firefox (as in:
	Debian testing) no longer do that, relying instead on something
	called “Network Security Service.” [1]

[1] http://www.mozilla.org/projects/security/pki/nss/

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: NSM certificate prompt

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If they go to /etc/ssl/ on Posix hosts, then they do.

They don't.

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

Re: NSM certificate prompt

[Simon Leinen]

On Fri, Dec 19, 2014 at 1:14 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> To the best of my knowledge, no other browsers use the system's
> certificates.

I am forced to use Mac OS X at work. (Yes, I know, I should look for
another job.)  All browsers *except* for Firefox do use the system's
certificate store ("Keychain").  This makes it quite convenient for
the user to manage which kinds of certificates she wants to trust. I'd
like Emacs' emerging TLS support to be able to access the same.
Unfortunately I don't have the cycles to do this - and I understand
that the willingness of others to support this non-free system may be
low.
-- 
Simon.

Re: NSM certificate prompt

[Eli Zaretskii]

> From: Simon Leinen <simon.leinen@gmail.com>
> Date: Fri, 19 Dec 2014 20:53:31 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On Fri, Dec 19, 2014 at 1:14 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> > To the best of my knowledge, no other browsers use the system's
> > certificates.
> 
> I am forced to use Mac OS X at work. (Yes, I know, I should look for
> another job.)  All browsers *except* for Firefox do use the system's
> certificate store ("Keychain").  This makes it quite convenient for
> the user to manage which kinds of certificates she wants to trust. I'd
> like Emacs' emerging TLS support to be able to access the same.

It already does -- assuming that GnuTLS on OS X reads that store when
we call the gnutls_certificate_set_x509_system_trust function.  If
not, then you should lobby the GnuTLS developers to make GnuTLS do
that on OS X.