Domino 12 Beta 1 - HTTPS Review & Ratings
Daniel Nashed – 24 January 2021 06:03:46
Now that Domino V12 Beta1 is available, I took the opportunity to look into the current state of TLS and ciphers in Domino.
Rating of the results
You can see from the rating that we are at a very high score.
Even without TLS 1.3 support, this already looks great!
And looking into details you see, that you could switch to ECDSA keys already for most web servers.
If are are interested in the details and want to test your own server -- even if not exposed to the internet .. continue reading and see the details from the commented results.
-- Daniel
Test Setup
- Requested a new TLS certificate from Let's Encrypt using the new CertMgr integrated into Domino V12.
- After receiving the certificate, I redirected HTTP to HTTPS (if you have HTTP enabled HSTS isn't working).
- I set the following notes.ini variables to enable HSTS and OCSP for Let's Encrypt production:
set config OCSP_RESPONDER=http://ocsp.int-x1.letsencrypt.org/
set config SSL_ENABLE_OCSP_STAPLING=1
set config HTTP_HSTS_INCLUDE_SUBDOMAINS=1
set config HTTP_HSTS_MAX_AGE=17280000
Test Tool "testssl.sh"
Even my server is reachable over the internet, I have been using a very cool shell script available on GitHub -- which will also work for internal hosts.
Beside that I have looked into a SSL Labs test result, confirming my findings.
https://github.com/drwetter/testssl.sh
yum install -y git bind-utils
mkdir -p /local/github
cd /local/github/
git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh
Details looking into testssl.sh output
Let's have a closer look of the current state.
Domino V12 introduces support for ECDSA crypto. So I requested a ECDSA certificate from Let's Encrypt using CertMgr, creating a ECDSA NIST-P 256 key.
Note:
A ECDSA NIST-P 256 is comparable to a RSA 3072 bit key. This should be fully sufficient and provides good security with best performance.
The ratings for NIST-P 256 and NIST-P 384 are the same in my tests.
A NIST-P 384 key would be comparable to a RSA key size of 7680 bit!
So my recommendation would be to stay with NIST-P 256!
Ciphers for ECDSA
When using a ECDSA key the standard cipher list is ignored and the following two ciphers are enabled automatically -- and all other ciphers are disabled.
So there are no additional settings you have to configure. And by the way TLS 1.0 is disabled by default in Domino V12 Beta1 already.
xc02c TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc02b TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
You can see from the client simulation in the detailed report below, that those ciphers are available in most platforms.
Only very old clients don't support them.
New curves supported
Domino V12 supports two new curves X25519 and X448 which are leveraged with ECDSA
Specially Curve X25519 is an important addition and you can see in the test report, that most client simulations negotiated a connection leveraging X25519.
Curve X25519 is not just faster, it is also an independent implementation, not influenced by the NSA -- in contrast to the NIST-P curves.
It has become "the de facto alternative to P-256" also because it's an independent implementation and is the preferred Curve used for Domino.
(See details here: https://help.hcltechsw.com/domino/earlyaccess/wn_new_curves_ecdhe.html)
Detailed look into the test results
You can see that the testssl.sh script delivers comparable results to the SSL Labs website.
The big benefit is that it works also for intranet hosts, without any external connections.
And you can get the output different formats.
Running the scan for HTTPS on the standard is simple. You just specify the hostname:
./testssl.sh pluto.csi-domino.com
The scan is also faster and uses your locally installed OpenSSL and DNS lookup tools.
Let's have a look into the details.
###########################################################
testssl.sh 3.1dev from https://testssl.sh/dev/
(124f6f5 2021-01-22 12:21:01 -- )
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
on localhost:./bin/openssl.Linux.x86_64
(built: "Jan 18 17:12:17 2019", platform: "linux-x86_64")
Start 2021-01-24 06:27:14 -->> 159.69.147.90:443 (pluto.csi-domino.com) <<--
rDNS (159.69.147.90): pluto.csi-domino.com.
Service detected: HTTP
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1 not offered
TLS 1.2 offered (OK)-- Only TLS 1.2 is offered
TLS 1.3 not offered and downgraded to a weaker protocol
NPN/SPDY not offered
ALPN/HTTP2 not offered
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export) not offered (OK)
Triple DES Ciphers / IDEA not offered
Obsoleted CBC ciphers (AES, ARIA etc.) not offered
Strong encryption (AEAD ciphers) with no FS not offered
Forward Secrecy strong encryption (AEAD ciphers) offered (OK) -- Forward Secrecy is offered
Testing server's cipher preferences
Has server cipher order? yes (OK) -- Server provides the cipher order
Negotiated protocol TLSv1.2
Negotiated cipher ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)-- openssl negotiated the right cipher.
Cipher per protocol
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
SSLv2
-
SSLv3
-
TLSv1
-
TLSv1.1
-
TLSv1.2 (server order)
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
The server cipher order lists the two ciphers mentioned above, with a favor to the more secure cipher
TLSv1.3
-
Testing robust forward secrecy (FS) -- omitting Null Authentication/Encryption, 3DES, RC4
FS is offered (OK) ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256
Elliptic curves offered: prime256v1 -- Curve offered is what we expect
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "status request/#5"
Session Ticket RFC 5077 hint no -- no lifetime advertised
SSL Session ID support yes
Session Resumption Tickets no, ID: yes
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size EC 256 bits (curve P-256)-- yes we got a ECDSA NIST-P 256 key
Server key usage Digital Signature
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial / Fingerprints 048635D3302F808EBEFDC34DF8244BDAEDD5 / SHA1 C264144A2B2FAE743441A4B51BC46722D8A1CDEC
SHA256 C69718BF1A8BFD1436F4173659C21295E8232293D3918017280C2A4EF30BCA4D
Common Name (CN) pluto.csi-domino.com
subjectAltName (SAN) pluto.csi-domino.com
Trust (hostname) Ok via SAN and CN (same w/o SNI)
Chain of trust Ok
EV cert (experimental) no
Certificate Validity (UTC) 89 >= 30 days (2021-01-24 05:26 --> 2021-04-24 06:26) -- You can see that I just got the new certificate requested, because I had to compare P-256 and P-384 ;-)
ETS/"eTLS", visibility info not present
Certificate Revocation List --
OCSP URI http://r3.o.lencr.org -- our OCSP configuration worked
OCSP stapling offered, not revoked -- certificate looks good
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)-- Let's Encrypt offers certificate transparency, which is the newer standard replacing "HTTP Public Key Pinning (HPKP)"
Certificates provided 3
Issuer R3 (Let's Encrypt from US)
Intermediate cert validity #1: ok > 40 days (2021-09-29 21:21). R3 <-- DST Root CA X3
#2: ok > 40 days (2021-09-30 16:01). DST Root CA X3 <-- DST Root CA X3
Intermediate Bad OCSP (exp.) Ok
Testing HTTP header response @ "/"
HTTP Status Code 401 Unauthorized WWW-Authenticate: Basic realm="/"
HTTP clock skew +1 sec from localtime
Strict Transport Security 200 days=17280000 s, includeSubDomains
Public Key Pinning --
Server banner Lotus-Domino
Application banner --
Cookie(s) (none issued at "/") -- maybe better try target URL of 30x
Security headers X-Content-Type-Options: nosniff
Cache-Control: no-cache
Reverse Proxy banner --
Testing vulnerabilities
All vulnerability test passed -- But this is not new in Domino V12:
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (RFC 5746) supported (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no gzip/deflate/compress/br HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 support
TLS_FALLBACK_SCSV (RFC 7507) No fallback possible (OK), no protocol below TLS 1.2 offered
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
no RSA certificate, thus certificate can't be used with SSLv2 elsewhere
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
BEAST (CVE-2011-3389) not vulnerable (OK), no SSL3 or TLS1
LUCKY13 (CVE-2013-0169), experimental not vulnerable (OK)
Winshock (CVE-2014-6321), experimental not vulnerable (OK) - doesn't seem to be IIS 8.x
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Running client simulations (HTTP) via sockets
Browser Protocol Cipher Suite Name (OpenSSL) Forward Secrecy
------------------------------------------------------------------------------------------------
Android 4.4.2 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Android 5.0.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256 256 bit ECDH (P-256)
Android 6.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256 256 bit ECDH (P-256)
Android 7.0 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Android 8.1 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Android 9.0 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Android 10.0 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Chrome 74 (Win 10) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Chrome 79 (Win 10) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Firefox 66 (Win 8.1/10) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Firefox 71 (Win 10) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
IE 6 XP No connection
IE 8 Win 7 No connection
IE 8 XP No connection
IE 11 Win 7 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
IE 11 Win 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Edge 15 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Edge 17 (Win 10) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Opera 66 (Win 10) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Safari 9 iOS 9 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Safari 9 OS X 10.11 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Safari 10 OS X 10.12 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Safari 12.1 (iOS 12.2) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Safari 13.0 (macOS 10.14.6) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Apple ATS 9 iOS 9 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Java 6u45 No connection
Java 7u25 No connection
Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Java 11.0.2 (OpenJDK) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
Java 12.0.1 (OpenJDK) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256)
OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 256 bit ECDH (P-256) --> OpenSSL 1.0.2 is not using the newer X25519 curve we prefer
OpenSSL 1.1.0l (Debian) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
OpenSSL 1.1.1d (Debian) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
Thunderbird (68.3) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384 253 bit ECDH (X25519)
You can see that only very very old OS/Browser/Software combination doesn't connect with those settings.
And I would see it more as a feature that really old software, which isn't patched any more cannot connect to a server.
Many clients already support the X25519 curve. All others use NIST-P 256 which is perfectly OK
Rating (experimental)
Rating specs (not complete) SSL Labs's 'SSL Server Rating Guide' (version 2009q from 2020-01-30)
Specification documentation https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
Protocol Support (weighted) 100 (30)
Key Exchange (weighted) 100 (30)
Cipher Strength (weighted) 90 (36)
Final Score 96
Overall Grade A+
The rate we get is in line what SSL Labs returned. Not only from the overall rate, but also from the detailed ratings.
So a final score of 96 from 100 points looks very good to me!
Done 2021-01-24 06:27:56 [ 43s] -->> 159.69.147.90:443 (pluto.csi-domino.com) <<--
The whole test took 43 seconds. You can run this against all your internal servers and see what you get back.
This can be run also against SMTP servers and other services!
Here is the command line for SMTP/STARTTLS:
./testssl.sh --starttls=smtp domino.nashcom.de:25
- Comments [1]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}