How to enable the screen/window sharing (screen casting) on Rocky Linux 9 (GNOME)

By default (fresh installation of the distribution and the apps) the desktop applications available on Rocky Linux 9 (GNOME desktop) cannot share the entire screen, a window, or a browser tab.

That problem appears due to a combination of a missing package (xdg-desktop-portal-gnome), which might not be installed by default, and systemd services (xdg-desktop-portal and/or pipewire), which are either missing or not enabled.

To solve the issue you need to install xdg-desktop-portal-gnome

sudo dnf -y install xdg-desktop-portal-gnome

and enable/start/restart the required services (as user):

systemctl --user enable --now pipewire
systemctl --user restart xdg-desktop-portal.service

Read More

Opening a collection of build recipes for compiling software for simulations and data analysis (HPC-related)

Those build recipe prototypes are siple bash scripts but they could be easily converted into Jenkins jobs:

https://gitlab.discoverer.bg/vkolev/recipes

Read More

Working on new HPC farm and its documentation project

Busy during the last 12 months. Designing and supporting yet another HPC farm, and writing documentation:

https://docs.discoverer.bg

Read More

Creating SHA256/SHA384/SHA512 based S/MIME digital signatures and using AES-256 for encryption in Outlook

Content:

1. Why does Outlook sticks to SHA-1 and 3DES when creating S/MIME signatures and encrypting the content
2. How to set the use modern and secure hash functions and encryption algorithms for S/MIME in Outlook
3. How to sign your outgoing e-mail messages
4. How to check the algorithm used for creating the S/MIME signature

1. Why does Outlook sticks to SHA-1 and 3DES when creating S/MIME signatures and encrypting the content

That is not clear at the moment. If one tries to select different hash function for S/MIME signature (SHA256, SHA384, SHA512) and an encryption algorithm different than 3DES (AES-256, for instance), those changes cannot be saved under the default S/MIME settings profile. Outook keeps using SHA-1 and 3DES. The most strange thing is that even the support of the Microsoft products cannot provide a solution:

https://answers.microsoft.com/en-us/msoffice/forum/all/cant-change-smime-hashing-algorithm-in-outlook/3d2a5cae-e4d2-4533-b29e-c341254b6ceb

2. How to set the use modern and secure hash functions and encryption algorithms for S/MIME in Outlook

Important: You cannot use a hash function that is of a higher order than the one used by your Certificate Authority to sing your X.509 certificate. For instance, if the CA signature on your certificate is SHA256, you cannot use SHA384 and SHA512 when creating the S/MIME signatures. Obviously, if the CA signature on your X.509 certificate is one based on SHA-1, you cannot use even SHA-256 for signing in Outlook. Therefore, check your case before starting with the instructions bellow.

Before starting, you need to have your certificate installed - either in Windows Certificate Store of the current user, via PKCS#12 file, or by connecting the smart card reader to the system. Once the certificate is accessible, start Outlook and in the main window go to "File":

Click there on "Options":

Next, go to "Trust Center" (1) and from there open "Trust Center Settings" (2):

Finally, click on "Email Security" (1) and "Settings"(2) to start modifying the S/MIME profile:

And here comes the big problem. You cannot change the hash function and the encryption algorithm in the default profile (that profile is created automatically). Therefore, you have to create manually a new default profile, by naming it differently and select there the desired combination of hash and encryption algorithms. This is what is done bellow.

First, select the certificate for signing (if it is not already selected):

And here comes the trick. Select the desired encryption algorithm (1), then the desired hash function (2), and CHANGE THE NAME OF THE PROFILE WITH SETTINGS - THIS MAKES THE MAGIC (3):

Press "OK" to exit (4) and in the previous window be sure the new profile is selected:

You may close the corresponding windows in the configuration menu and start signing your outgoing e-mail messages.

3. How to sign your outgoing e-mail messages using the new S/MIME settings

Nothing new here. Compose a new short e-mail message, addressed to yourself, do not send it yet, and open the tab "Options":

Click on "Sign", then press the button "Send" to send the message:

A new window will pop up. There you should either enter your password for protecting the private key in the Windows Certificate Store of the current user, or the PIN for unlocking the access to the smart card processor for signing:

4. How to check the algorithm used for creating the S/MIME signature

Once the signed email is received in the Inbox, click on the seal icon:

In the new window, check if the S/MIME signature is valid:

and them click on "Details":

If you click on "Signer" you will see the algorithm used for creating the S/MIME signature:

Read More

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