Fix for secure connection in FIPS environment

[Jason Sikes]

Hi everyone.

We at SUSE had a problem using TigerVNC in our newer FIPS-compliant environment. I am attaching a patch to fix this problem.

As part of establishing a secure connection, TigerVNC generates Diffie-Hellman parameters to use for creating a shared key. This was the way to do it before GnuTLS 3.6.0.

The problem is that generating DH parameters is no longer allowed in FIPS mode. Any attempt to securely connect to a TigerVNC server fails in a FIPS system.

GnuTLS 3.6.0 has deprecated Diffie-Hellman parameter generation. Instead, GnuTLS now defaults to using parameters from RFC-7919, which would solve our problem. 

Fortunately for us the solution is simple: remove from TigerVNC the code that generates DH parameters.

Thank you, and I hope you find this helpful.

--Jason

diff --git a/common/rfb/SSecurityTLS.cxx b/common/rfb/SSecurityTLS.cxx
index d5ef47e6..2111bae6 100644
--- a/common/rfb/SSecurityTLS.cxx
+++ b/common/rfb/SSecurityTLS.cxx
@@ -37,8 +37,6 @@
 #include <rdr/TLSOutStream.h>
 #include <gnutls/x509.h>
 
-#define DH_BITS 1024 /* XXX This should be configurable! */
-
 using namespace rfb;
 
 StringParameter SSecurityTLS::X509_CertFile
@@ -50,7 +48,7 @@ StringParameter SSecurityTLS::X509_KeyFile
 static LogWriter vlog("TLS");
 
 SSecurityTLS::SSecurityTLS(SConnection* sc, bool _anon)
-  : SSecurity(sc), session(NULL), dh_params(NULL), anon_cred(NULL),
+  : SSecurity(sc), session(NULL), anon_cred(NULL),
     cert_cred(NULL), anon(_anon), tlsis(NULL), tlsos(NULL),
     rawis(NULL), rawos(NULL)
 {
@@ -70,11 +68,6 @@ void SSecurityTLS::shutdown()
     }
   }
 
-  if (dh_params) {
-    gnutls_dh_params_deinit(dh_params);
-    dh_params = 0;
-  }
-
   if (anon_cred) {
     gnutls_anon_free_server_credentials(anon_cred);
     anon_cred = 0;
@@ -198,18 +191,10 @@ void SSecurityTLS::setParams(gnutls_session_t session)
     throw AuthFailureException("gnutls_set_priority_direct failed");
   }
 
-  if (gnutls_dh_params_init(&dh_params) != GNUTLS_E_SUCCESS)
-    throw AuthFailureException("gnutls_dh_params_init failed");
-
-  if (gnutls_dh_params_generate2(dh_params, DH_BITS) != GNUTLS_E_SUCCESS)
-    throw AuthFailureException("gnutls_dh_params_generate2 failed");
-
   if (anon) {
     if (gnutls_anon_allocate_server_credentials(&anon_cred) != GNUTLS_E_SUCCESS)
       throw AuthFailureException("gnutls_anon_allocate_server_credentials failed");
 
-    gnutls_anon_set_server_dh_params(anon_cred, dh_params);
-
     if (gnutls_credentials_set(session, GNUTLS_CRD_ANON, anon_cred)
         != GNUTLS_E_SUCCESS)
       throw AuthFailureException("gnutls_credentials_set failed");
@@ -220,8 +205,6 @@ void SSecurityTLS::setParams(gnutls_session_t session)
     if (gnutls_certificate_allocate_credentials(&cert_cred) != GNUTLS_E_SUCCESS)
       throw AuthFailureException("gnutls_certificate_allocate_credentials failed");
 
-    gnutls_certificate_set_dh_params(cert_cred, dh_params);
-
     switch (gnutls_certificate_set_x509_key_file(cert_cred, certfile, keyfile, GNUTLS_X509_FMT_PEM)) {
     case GNUTLS_E_SUCCESS:
       break;
diff --git a/common/rfb/SSecurityTLS.h b/common/rfb/SSecurityTLS.h
index dd89bb49..fe9fe673 100644
--- a/common/rfb/SSecurityTLS.h
+++ b/common/rfb/SSecurityTLS.h
@@ -55,7 +55,6 @@ namespace rfb {
 
   private:
     gnutls_session_t session;
-    gnutls_dh_params_t dh_params;
     gnutls_anon_server_credentials_t anon_cred;
     gnutls_certificate_credentials_t cert_cred;
     char *keyfile, *certfile;

[Pierre Ossman]

On 07/06/2021 05:22, Jason Sikes wrote:
> GnuTLS 3.6.0 has deprecated Diffie-Hellman parameter generation. Instead,
> GnuTLS now defaults to using parameters from RFC-7919, which would solve
> our problem.
>
> Fortunately for us the solution is simple: remove from TigerVNC the code
> that generates DH parameters.
>
> Thank you, and I hope you find this helpful.
>

Thanks. Unfortunately GnuTLS 3.6.0 is probably a bit too new for us to
require, so this change would need to retains backwards compatibility
with older versions. Could we perhaps include the parameters from RFC 7919?

Please also see this PR here:

https://github.com/TigerVNC/tigervnc/pull/1263

Regards
--
Pierre Ossman Software Development
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Jason Sikes]

On Sunday, June 6, 2021 at 10:14:24 PM UTC-7 Pierre Ossman wrote:

Thanks. Unfortunately GnuTLS 3.6.0 is probably a bit too new for us to
require, so this change would need to retains backwards compatibility
with older versions. Could we perhaps include the parameters from RFC 7919?

It looks like the answer is yes. Either gnutls_dh_params_import_pkcs3() or gnutls_dh_params_import_raw() will do the job. The former would be easier for me, and I will do that really soon here.

--Jason

[DRC]

Hi, Jason.  I have been experimenting with FIPS and was able to get my
CentOS 7 machine up and running with it, but how does one detect FIPS
compliance issues such as these?

Darrell

[Brian Hinz]

Yeah we’ve been running on CentOS 7 with FIPS turned on for a couple of years now without issue, so there must be something different in SuSE

--
You received this message because you are subscribed to the Google Groups "TigerVNC Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-devel/f1e9cd8d-1ae3-ce98-250d-aa8ada862cd8%40virtualgl.org.

--

Sent from Gmail Mobile

[DRC]

FWIW, I tried Rocky Linux 9 as well.  On both operating systems, the random DH parameters are allowed without complaint.

DRC

[Jason Sikes]

There are two standards: 140-2 (current) and 140-3 (new).

Current FIPS-compliant systems (140-2) allow randomly-generated EC Diffie-Hellman parameters. FIPS 140-2 is valid for another four years.

Its successor, FIPS 140-3, only allows "safe" parameters. Nobody has 140-3 certification yet, as far as I know.

So random parameter generation should still work fine for now.

--Jason

[Jason Sikes]

@DRC

FIPS issues show up as errors. In this case, TigerVNC checks for an error after calling a gnuTLS function. A FIPS issue would be one of those errors.

--Jason