Thinlinc fails due to fips mode

Running RHEL8 with FIPS mode enabled (fips=1 on kernel command line) to disable insecure/unapproved crypto.

First bug is that the install-server scripts does not work. It produces errors related to ’ rpm error “does not verify: no digest” '. The workaround is to manually install the RPM using
–nodigest --nofiledigest options. See 7809 – Server RPMs cannot be installed on FIPS enforcing system
I think I read somewhere that one fix is to use a new version of rpm when creating the RPMs (I think rpm 4.14 or newer).

Second bug is that after installing, I cannot use thinlinc. There is a bug which is low priority, but seems a show stopper to me. 7657 – MD5 is considered unsecure and shouldn't be used

On my server:

type or paste code heretail /var/log/vsmagent.log 
  File "/opt/thinlinc/modules/thinlinc/vsm/handler_reqsession.py", line 352, in start_session
    II1 = oO00 . start ( )
  File "/opt/thinlinc/modules/thinlinc/vsm/sessionstart.py", line 40, in start
    self . create_session_env ( )
  File "/opt/thinlinc/modules/thinlinc/vsm/sessionstart.py", line 72, in create_session_env
    self . session_env [ "TLSESSIONMCOOKIE" ] = self . mcookie ( )
  File "/opt/thinlinc/modules/thinlinc/vsm/sessionstart.py", line 122, in mcookie
    Oo0O0o0oO000 = hashlib . md5 ( )
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS

The low priority bugzilla report mentions something about MD5 being used to support older clients (4.1.0). I am using latest client. Any fix or workaround for this so I can use thinlinc?

@kbass just to clarify, is the requirement here that ThinLinc should be certified FIPS compliant, or just that it is able to be installed and run on RHEL8 with FIPS mode enabled?

@aaron Just need to be able to install and run on RHEL8. There is a workaround, so this is more a quality of life issue. I included some info in the bugzilla report on how ThinLinc might fix this.

Okay, thanks. That helps us understand the scope a bit better. Appreciate the feedback.

@kbass is this an industry- or organization-wide requirement? Or more of a “best practice” type thing for this particular installation?

We’re trying to understand a bit more about FIPS in general, who uses it, what level of compliance we would need to meet, etc.

Happy to discuss off thread if you prefer.

@aaron This is an industry standard for computer systems that process or store data related to any Government business in the US. It is a rather large set of requirements and guidelines that are supposed to bring together best practices from cyber-security experts with an aim to secure systems.

Two specific guidelines are that only approved cryptographic algorithms are permitted and two factor authentication is required.

Red Hat Enterprise Linux (and other derivatives) enforce the cryptographic part by providing a kernel argument ‘fips=1’. That flag disables all non-approved cryptographic algorithms such as MD5 or SHA1 and requires newer more secure versions be used. This is a flag that is supposed to be enabled when you install the operating system and left enabled. Technically it will cause all libraries that use non approved algorithms to return error codes.

As far as two factor, I have setup my machine to use the Red Hat Identity Server which is based off of FreeIPA. Unfortunately I have not found a way for that to work with Thinlinc either. I believe FreeIPA integrates with PAM / SSSD and requires ‘AuthenticationMethods publickey,password:pam publickey,keyboard-interactive:pam’. However this does not work with Thinlnc.

Thanks @kbass, that makes sense. Regarding 2FA, please see:

https://www.cendio.com/bugzilla/show_bug.cgi?id=4962

Hi again @kbass, note that ThinLinc 4.17.0 will work well on machines with fips mode enabled. Go test the beta if you like:

Hi @samuel, I just reinstalled my machine from RHEL8 to RHEL9 and ThinLinc 4.17.0 beta installed with fips mode enabled. It also got past the issue related to the 4.16.0 rpm package failing digest verify due to unsupported MD5 signature. Both issues seem to be fixed with 4.17.0 beta. Thanks.

1 Like

Good. Thanks for taking the time to test