Busy during the last 12 months. Designing and supporting yet another HPC farm, and writing documentation:
https://docs.discoverer.bgCreating SHA256/SHA384/SHA512 based S/MIME digital signatures and using AES-256 for encryption in Outlook
Content:
- Why does Outlook sticks to SHA-1 and 3DES when creating S/MIME signatures and encrypting the content
- How to set the use modern and secure hash functions and encryption algorithms for S/MIME in Outlook
- How to sign your outgoing e-mail messages
- 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:
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:
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.
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.
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.
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_configby 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.
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
