Compiling GROMACS 2019.5 with Intel Compilers and CUDA on CentOS 7 and 8

All tests reported bellow are performed by using Intel Parallel Studio XE 2019 Update 4. I presume you may achieve the same positive results using older versions of the Intel Compilers package.

Notes on CentOS 7: You have to install the SCL repository and EPEL (that are MANDATORY requirements you cannot skip):

$ sudo yum install centos-release-scl centos-release-scl-rh epel-release

Then, using the new repositories, install dvetoolset-8 and cmake3:

$ sudo yum install devtoolset-8 cmake3

In the bash session, where the compilation process will take place, execute:

$ scl enable devtoolset-8 bash

To install the CUDA latest compiler and libraries, you might use the procedure described in my previous posts. The latest version of CUDA is 10.2. Once all the pre-requisites are satisfied, download the GROMACS 2019.5 source code tarball, unpack it, create a folder named "build" inside the source tree, enter it, load the Intel Compilers variables, then the SCL environment and run the compilation and installation process:

$ mkdir ~/build
$ cd build
$ wget ftp://ftp.gromacs.org/pub/gromacs/gromacs-2019.5.tar.gz
$ tar xvf gromacs-2019.5.tar.gz
$ cd gromacs-2019.5
$ mkdir build
$ cd build
$ source /opt/intel/compilers_and_libraries/linux/bin/compilervars.sh intel64
$ CC=icc CXX=icpc CFLAGS="-xHost" CXXFLAGS="-xHost" cmake3 .. -DCMAKE_INSTALL_PREFIX=/usr/local/appstack/gromacs-2019.5-icc -DGMX_MPI=OFF -DGMX_BUILD_OWN_FFTW=OFF -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DGMX_FFT_LIBRARY=mkl
$ make -j6 install

The product of the compilation will be installed in /usr/local/appstack/gromacs-2019.5-icc. You might change that destination by set another value to -DCMAKE_INSTALL_PREFIX.




Read More

Getting ssllabs.com class "A+" by matching at 100% Key Exchange and Cipher Strength criteria

In most cases, getting "A+" rate by the TLS ssllabs.com server checker, does not necessary mean the examined server matches fully (at 100%) all criteria. For instance, "A+" might be given if your server matches partially (at 90% level) the requirements for key exchange protocols and cipher strength:

In my case, I got "A+" status for my Apache/mod_ssl 2.4.6 server (on CentOS 7) by using limited and very conservative list of ciphers (it is a long story about why I do avoid using "CBC"-based ciphers):

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256

So far (8 months since I implemented the new TLS configuration), I haven't received any complaints from my clients, related to TLS issues. Seems like they keep their mobile and desktop browsers very much up to date.

Recently, for another project (PKI-based one) I decided to go further and try to get "A+" by matching all criteria at 100% (using the same Apache/mod_ssl 2.4.6 setup on CenOS 7):

What I have done? I just removed from the list above the 128-bit ciphers:

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384

How does this change affect the clients? I got only 1 complaint from a person who is used to use Firefox on CentOS 6 (rather old distribution for a desktop, I dare say). On the other side, even mobile clients with Android 6.0, using Samsung Internet Browser, do not have any problem with the new TLS cipher set.

What was surprising is that replacing RSA server certificate with ECDSA-based one, does not create any significant TLS issues. Again, the first set of ciphers I tested (where "A+" is matched only partially), was based on both 256 and 128-bit ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256

and the second one included only 256-bit based ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384

It seems like most of the browser and OS vendors take a lot of measures to secure the TLS protocol implementation in their software products.

Read More

Re-deriving AES and 3DES attribute encryption keys for 389 Directory Server installation

1. Introduction

Even if you do not use attribute encryption keys in your 389 Directory Server (DS) installation, you might be bothered by all those messages that repeat themselves in /var/log/dirsrv/slapd-instance_name/error ("instance name" is your actual instance name), after every start/restart of the 389 DS daemon:

[04/Nov/2019:02:03:16.808096029 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher AES in backend userRoot, attempting to create one...
[04/Nov/2019:02:03:16.843731964 +0200] - ERR - attrcrypt_wrap_key - Failed to wrap key for cipher AES
[04/Nov/2019:02:03:16.808096029 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one...
[04/Nov/2019:02:03:16.843731964 +0200] - ERR - attrcrypt_wrap_key - Failed to wrap key for cipher 3DES

What causes their appearance and how to get rid of them (and to solve the problem they point to)?

There are two reasons for those message to be seen in /var/log/dirsrv/slapd-instance_name/error:

• the RSA-based X.509 certificate, used by the 389 DS server, was replaced with a new one and it has new encryption key (that situation might be fatal if your LDAP directory hosts encrypted attributes and the old RSA keys were lost);
• the 389 DS server uses Elliptic Curves based X.509 certificate.

First, some important remarks. While it is true that failing to access the attribute encryption keys is not a fatal event to most of the 389 DS installations, where upon the attribute encryption is not necessary and therefore - not truly implemented, the appearance of those error messages might indicate a disruption of some other services (especially those that frequently query the LDAP server). That means, you really have to investigate the source of those errors, if your goal is a reliable 389 DS installation.

2. The RSA-based X.509 certificate, used by the 389 DS server, was replaced with a new one and it has new encryption key

Go down to "Deriving new attribute encryption keys" to see how to fix the problem.

3. The 389 DS server uses Elliptic Curves (ECC) based X.509 certificate

389 Directory Server stores the keys, certificates, and passwords in Mozilla NSS DB storage. It is usually located inside the folder /etc/dirsrv/slapd-instance_name, where "instance_name" is the actual instance name of your 389 Directory Server setup (depends on how did you name the instance). The NSS DB store is split into three files: cert8.db, keys3.db, and secmod.db.

If the 389 Directory Server is configured to use SSL (and STARTTLS), a X.509v3 certificate is installed in the NSS DB store. The problem is that by default (so far), the administrative server sets any X.509 certificate in use, as if it is RSA-based. Therefore, in /etc/dirsrv/slapd-instance_name/dse.ldif (that is the starting configuration of the instance), you will find the entry:

dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: server-cert
nsSSLToken: internal (software)
nsSSLActivation: on

even if the X.509 certificate with nickname "server-cert" installed there (the nickname the certificate is know under in the NSS DB store) is ECDSA-based. And this "masking" of the ECDSA-based certificate as RSA, causes those errors from above to appear, when the SSL certificated is ECDSA-based. Note that the current method for deriving 3DES and AES attribute encryption keys is based on RSA encryption keys only. To solve this problem (especially if you want to deliberately generate 3DES and AES keys), you need to implement some workaround. That workaround works in the following way. Define an entry for the ECDSA certificate in the starting configuration (replace "server-cert" with your actual ECDSA X.509 certificate nickname, listed in the NSS DB certificate store):

$ ldapadd -D "cn=Directory Manager" -x -W
dn: cn=ECDSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: ECDSA
nsSSLPersonalitySSL: server-cert
nsSSLToken: internal (software)
nsSSLActivation: on

Then import into NSS DB certificate store new RSA certificate, that will be used only to support the attribute encryption key generation (we assume its nickname is "keygen-cert"), remove the old dn "cn=RSA,cn=encryption,cn=config" (if exists):

$ ldapdelete -D "cn=Directory Manager" -x -W "cn=RSA,cn=encryption,cn=config"

and add it again, pointing this time the attribute "nsSSLPersonalitySSL" to the RSA certificate nickname ("keygen-cert" in the example bellow):

$ ldapadd -D "cn=Directory Manager" -x -W
dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: keygen-cert
nsSSLToken: internal (software)
nsSSLActivation: off

PAY ATTENTION: To avoid the use of RSA certificate as a host certificate, and to force the use of ECDSA one for that purpose, you have to set nsSSLActivation to off. That is mandatory!

At this point, you might restart your 389 Directory Server instance:

$ sudo systemctl restart dirsrv@instance_name

Then proceed to "Deriving new attribute encryption keys".

4. Deriving new attribute encryption keys

If you don't know how many back-ends does your 389 DS currently supports, you might check that:

$ ldapsearch -D "cn=Directory Manager" -b "cn=config" -x -W "nsslapd-backend=*" nsslapd-backend | grep ^nsslapd-backend | awk '{print $2}'

(you will have to know the "cn=Directory Manager" password to complete the search). In most cases (default setup schema) the result will look like this:

userRoot

If the administrative server is also installed and configured, the NetscapeRoot back-end will be shown too:

NetscapeRoot
userRoot

The next step is to delete the dn-objects containing the AES and 3DES attribute encryption keys. For each back-end, you need to execute (replace BACKEND with the actual name of the back-end):

$ ldapdelete -D "cn=Directory Manager" -x -W "cn=AES,cn=encrypted attribute keys,cn=BACKEND,cn=ldbm database,cn=plugins,cn=config"
$ ldapdelete -D "cn=Directory Manager" -x -W "cn=3DES,cn=encrypted attribute keys,cn=BACKEND,cn=ldbm database,cn=plugins,cn=config"

If you receive "No such object" as a result, that might be a proof that only X.509 ECC-based certificates have been used with the current installation of 389 DS, ever since it was created.

You can restart now the 389 DS daemon (replace "instance_name" with your actual 389 Directory Server instance name):

$ sudo systemctl restart dirsrv@instance_name

and if the keys were successfully derived during the restart of 389 DS daemon, you will see the following messages at the end of /var/log/dirsrv/slapd-instance_name/error (two lines for each back-end):

[04/Nov/2019:04:57:08.393260367 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher AES in backend userRoot, attempting to create one...
[04/Nov/2019:04:57:08.446317176 +0200] - INFO - attrcrypt_cipher_init - Key for cipher AES successfully generated and stored
[04/Nov/2019:04:57:08.470085086 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one...
[04/Nov/2019:04:57:08.504787008 +0200] - INFO - attrcrypt_cipher_init - Key for cipher 3DES successfully generated and stored

No such messages will appear again during the next restarts, unless you remove the employed RSA-based X.509 certificates from the NSS DB.

Read More

Keep away the SSH scan bots by hardening the SSH key-exchange on the server side (CentOS/RHEL 7/8 case)

Analyzing the SSH login attempts, regularly performed by a vast number of bots, one can detect and interesting pattern - they use old-fashioned key-exchange protocols, like diffie-hellman-group1-sha1, diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1. I am not a bot operator myself and I cannot be absolutely sure why do the bot operators and programmers use those old key exchange protocols. I only speculate here, but they either target old SSH installations (old OpenSSH/SSH.com server version), or the bot software employs some old SSH library.

Knowing that certain pattern in the key-exchange, it might be easy to get rid of most of the SSH scans, by simply hardening the key-exchange configuration on the SSH server. To do that, add to the end of your /etc/ssh/sshd_config the following line:

• on CentOS 7/RHEL 7:

  Edit /etc/ssh/sshd_config by appending to its end the line:

  KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

  Save the changes and restart sshd:

  # systemctl restart sshd

on CentOS 8/RHEL 8:

Edit CRYPTO_POLICY declaration in /etc/crypto-policies/back-ends/opensshserver.config by replacing there the -oKexAlgorithms declaration with:

-oKexAlgorithms=curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp521

Save the changes and restart sshd:

# systemctl restart sshd

Finally (after implementing the recommendations from above), tail /var/log/secure and prove that the bots are being repelled. You should see lines like those:

Nov  2 05:07:36 server sshd[26440]: Unable to negotiate with xxx.xxx.xxx.xxx port 28482: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 [preauth]
Nov  2 05:16:53 server sshd[26517]: Unable to negotiate with xxx.xxx.xxx.xxx port 14046: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 [preauth]

Important note: some old SSH clients might not "speak" the modern key-exchange algorithms, like those recommended above!

Even if the suggested key-exchange settings might drop some of your actual SSH clients, it is better to keep the configuration, for it is the only way to show your SSH users that the SSH clients get old too and they should be replaced or upgraded to keep up with the modern cryptography requirements.

Read More

Using TLSv1.3 and strong cryptography for 389 Directory Server (on CentOS 7)

TLS v1.3 support came recently to the 389 Directory Server (via mod_nss) with the latest CentOS 7. Due to an inconstancy between EPEL and CentOS7 upstream, TLS v1.3 is not currently available to the dirsrv admin service!

To activate the TLS v1.3 protocol for 389 Directory Server, do prepare a LDIF file, and describe there the modification that will take place in "cn=encryption,cn=config" (a dn-object which is a part of the 389 start up configuration), and insert there the following text:

dn: cn=encryption,cn=config
changetype:modify
replace: sslVersionMin
sslVersionMin: TLS1.2

dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: off

dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3Ciphers
nsSSL3Ciphers:  +TLS_CHACHA20_POLY1305_SHA256,+TLS_AES_256_GCM_SHA384,+TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Save that content as "modify.ldif", then invoke ldapmodify, and authenticate as "cn=Directory Manager" to enforce the modification:

$ ldapmodify -D "cn=Directory Manager" -x -W -f modify.ldif

In case of successful modification, the following message will appear:

modifying entry "cn=encryption,cn=config"

At this point you need to restart 389 Directory Server:

systemctl reload dirsrv@instance-name

and check if the requested cipher suite, already requested for TLS v1.2 above, is really available to the server (replace "localhost" with the actual server name of your 389 server):

$ nmap -sV --script ssl-enum-ciphers -p 636 localhost

In latest Fedora, CentOS, and Ubuntu, one can use openssl (>= 1.1.1) to verify that that TLS v1.3 is successfully configured and (therefore) available (just replace "server-name" down bellow with your actual server name):

$ openssl s_client -connect server-name:636

This is how a positive result, the one detecting the presence of TLS v1.3, will appear on your screen:

New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent

Read More

Using high-grade ECC temporary keys with Apache and mod_ssl on CentOS 7

To support ECHDE-based SSL ciphers, your Apache server (through mod_ssl) needs a temporary ECC key to be generated and loaded during each start or restart of the httpd daemon. While on RHEL8 and CentOS 8 you can automatically generate and load such keys, every time when Apache daemon is invoked, simply by adding the declaration:

SSLOpenSSLConfCmd Curves P-384

to the section in /etc/httpd/conf.d/ssl.conf, there is no such support in mod_ssl 2.4.6 - the version shipped with CentOS 7. That does not mean mod_ssl 2.4.6 does not support ECDHE and the use of temporary ECC keys. It supports it, but instead of allowing the temporary ECC key size to be configured as a parameter in /etc/httpd/conf.d/ssl.conf, it sticks only to 256-bit secp256k1 key. Key of that size might not be suitable (cannot be recognized secure enough) for use in long-time running Apache instances. One workaround here is to manually generate ECC key, using secp384r1 (that is high-grade key), and add it to the end of the certificate file (that is the file pointed by the SSLCertificateFile declaration in /etc/httpd/conf.d/ssl.conf).

To generate the key, use openssl:

$ openssl ecparam -genkey -name secp384r1

The output will look like:

-----BEGIN EC PARAMETERS-----
BgUrgQQAIg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCL5996z0+JsNAR2boRU0zULurtLbKbILiysJx3BbWEWFrlkuXL11BS
MI9bqrYNXjOgBwYFK4EEACKhZANiAAQISZYiUhc3GUXCaxOfsNun9KBiMyp9yAR3
qGH2NR1Va51Q4WfS4X0XPCaa3w3gA5g69MQV8aak3BVnbE27Q+yAZ5zi+dSNt5VU
Jg1tGgZmzX+SfJ6WWtMSv0Aa3r62UEE=
-----END EC PRIVATE KEY-----

Add it to the end of the certificate file, right after the line:

-----END CERTIFICATE-----

Save the changes to the file and reload or restart Apache's daemon httpd:

$ sudo systemctl reload httpd

To check if the server is successfully loaded and using the newly generated 384-bit long temporary key, use openssl:

$ openssl s_client -connect your_server_name:443

In case of success, you should see in the result the following line:

Server Temp Key: ECDH, P-384, 384 bits

NOTES: The configuration of mod_ssl should include at least one ECDHE cipher. Do not try to go to 521-bit key, for it is not supported by some browsers (yet).

Read More

How to protect the Google Chrome NSS Certificate DB store in Linux with password

Google Chrome for Linux, keeps the installed X.509 certificates and keys in NSS Certificate DB store, which is not protected by default. That means, everyone with access to the browser and/or the user's home directory, can copy the signing keys. The goal of this memo is to explain how to protect the Google Chrome's certificate store with password.

Note, that the folder, where Google Chrome keeps the NSS Certificate DB files per user is:

${HOME}/.pki/nssdb

During its first start (initiated by the user), the browser generates the NSS Certificate DB store files there in:

cert9.db
key4.db
pkcs11.txt

It is very important to keep in mind that Google Chrome uses SQLite3-based format of NSS Certificate DB, when using the NSS tools to manage the database.

To list the content of the database, use the tool certutil (mind the file system locator "sql:" that is after "-d" in the command line bellow):

$ certutil -L -d sql:${HOME}/.pki/nssdb

If there are X.509 certificates installed in NSS Certificate DB, you will see their friendly names and trust attributes (otherwise, only the column descriptions will be displayed).

To set the password for protecting the keys and the integrity of NSS Certificate DB, stop Google Chrome first (check if it is running), and then execute the following command line:

$ certutil -W -d sql:${HOME}/.pki/nssdb

That will start a dialogue in the terminal. At the beginning, you will need to type the current password (simply press "Enter" to try the default password, which is an empty string):

Enter Password or Pin for "NSS Certificate DB":

If that is the correct password, the next step will begin with the following statement displayed:

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

followed by a prompt, where the new password for protecting NSS Certificate DB to be entered twice:

Enter new password:
Re-enter password:

If the new password is correctly typed, a confirmation message will be displayed:

Password changed successfully.

From this moment onward, the installation of new certificates (with or without their private keys) in NSS Certificate DB, as well as the access to the installed private keys, will be granted based on password.

To verify the password controlled access to the NSS Certificate DB is working, run Google Chrome, type in the address bar:

chrome://settings/certificates

and press "Enter". If NSS Certificate DB is password protected, the following window will appear on the screen:

(note the window description saying "Please sign in to NSS Certificate DB"). In case you cannot provide the correct password, only read-only access to the NSS Certificate DB will be granted, with no access to the private keys installed there (that means no certificate authenticated logins, no digital signatures).

What if I forget the password for NSS Certificate DB?

You cannot do much, because the private keys, previously installed in the database, are now encrypted with a password you have forgotten. Moreover, the password is irretrievable, since no additional decryption key or another mechanism, that might help to retrieve the password from the locked database files exists, as a part of the NSS Certificate DB design. Hence, if you forget the NSS Certificate DB password, consider the keys installed in there lost.

In case you keep backup copies of the certificates and keys (as PFX/PKCS#12 files), you might create a new database and install them there. To create new NSS Certificate DB, you need to stop Google Chrome (mandatory). Then move the old NSS Certificate DB files to a temporary location (who knows, one day the forgotten password might be found):

$ mkdir ${HOME}/.pki/nssdb-lost
$ mv ${HOME}/.pki/nssdb/* ${HOME}/.pki/nssdb-lost/

and create new database files in ${HOME}/.pki/nssdb:

$ certutil -N -d sql:${HOME}/.pki/nssdb

After the message:

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

enter the new password twice:

Enter new password:
Re-enter password:

and if the confirmation message:

Password changed successfully.

is displayed, you new (but empty) NSS Certificate DB, is created and protected with password.

Now you can run the Google Chrome and install the certificates and private keys, using the NSS Certificate DB management tools, embedded in the browser.

Read More