Bug 1492107

Summary: VNC cannot be used when FIPS is enabled because DH_BITS is too low
Product: Red Hat Enterprise Linux 7 Reporter: Joe Wright <jwright>
Component: tigervncAssignee: Jan Grulich <jgrulich>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: urgent    
Version: 7.4CC: bgollahe, cww, jkoten, thudziec, tpelka
Target Milestone: rcKeywords: Regression, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1501165 (view as bug list) Environment:
Last Closed: 2018-04-10 11:37:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1420851, 1501165    

Description Joe Wright 2017-09-15 13:30:46 UTC
Description of problem:
- VNC cannot be used when FIPS is enabled because DH_BITS is too low

Version-Release number of selected component (if applicable):
- 1.8.0



How reproducible:
100%

Steps to Reproduce:
1. set fips=1 on the kernel cmdline of the system hosting the VNC server 
2. boot with this setting and attempt to use vncviewer to connect to a system running a vnc daemon with FIPS turned on
3. Observe error:

$ vncviewer 192.168.1.2:5901

TigerVNC Viewer 64-bit v1.8.0
Built on: 2017-05-17 05:47
Copyright (C) 199-2017 TigerVNC Team and many others (see README.txt)
see http://www.tigervnc.org for information on TigerVNC.

Wed Sep 13 09:39:52 2017
DecodeManager: Detected 4 CPU cores(s)
DecodeManager: Creating 4 decoder thread(s)
CConn:                  connected to host 192.168.1.2 port 5901
CConnection:     Server supports RFB protocol version 3.8
CConnection:     Using RFB protocol version 3.8
CConnection:      Choosing security type VeNCrypt(19)
CVeNCrypt:         Choosing security type TLSVnc (258)
CCon:                   gnutls_dh_params_generate2 failed

Log from VNC Server side:

Wed Sep 13 10:54:38 2017
Connections: accepted: 192.168.1.1::12345
SConnection: Client needs protocol version 3.8
SConnection: Client requests security type VeNCrypt(19)
SVeNCrypt:   Client requests security type TLSVnc (258)
Sconnection: AuthFailureException: gnutls_dh_params_generate2 failed
Connections: closed: 192.168.1.1::12345 (gnutls_dh_params_generate2 failed)
EncodeManager: Framebuffer updates: 0
EncodeManager:     Total: 0 rects, 0 pixels
EncodeManager:                0 B (1: -nan ratio)
TLS:                           TLS session wasn't terminated gracefully
ComparingUpdateTracker: 0 pixels in / 0 pixels out
ComparingUpdateTracker: (1: -nan ratio)



Actual results:
"gnutls_dh_params_generate2" failed then after too many tries get "Too Many Security Errors"

Expected results:
- successful connection

Additional info:

It appears to be the same problem as identified in libvirt here: https://www.redhat.com/archives/libvir-list/2014-September/msg00194.html

This should fix it:

diff -up tigervnc-1.8.0/common/rfb/SSecurityTLS.cxx.moar-bits tigervnc-1.8.0/common/rfb/SSecurityTLS.cxx
--- tigervnc-1.8.0/common/rfb/SSecurityTLS.cxx.moar-bits	2017-09-14 16:32:59.224766365 -0400
+++ tigervnc-1.8.0/common/rfb/SSecurityTLS.cxx	2017-09-14 16:33:20.974546604 -0400
@@ -36,7 +36,7 @@
 #include <rdr/TLSInStream.h>
 #include <rdr/TLSOutStream.h>
 
-#define DH_BITS 1024 /* XXX This should be configurable! */
+#define DH_BITS 2048 /* XXX This should be configurable! */
 
 using namespace rfb;

Comment 4 Joe Wright 2017-09-15 13:44:08 UTC
Version correction: 1.8.0-1

Comment 5 Jan Grulich 2017-09-19 07:30:14 UTC
Fixed in tigervnc-1.8.0-3.el7.

Comment 8 Tomas Hudziec 2018-02-08 12:41:12 UTC
Verified, that with tigervnc-server-1.8.0-5.el7.x86_64 and FIPS mode on VNC connection is working properly.

Comment 11 errata-xmlrpc 2018-04-10 11:37:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0722