Upgrade affected connectivity from 2012 R2

I upgraded to 14.1.1, and my API calls from the PowerShell cmdlet Invoke-RestMethod on Server 2012 R2 stopped working. Through investigation, I found that only TLS1.2 and TLS1.3 are enabled in 14.1.1, so I proceeded to enable TLS1.2 in Server 2012 R2 (not enabled by default and TLS1.3 not supported). I then ran into a cipher problem, finding that the two ciphers below (displayed for TLS1.2 when scanned with ssllabs.com) were only supported in Server 2016 and higher:


So then I examined the TLS Cipher Suites in Windows 8.1 section (TLS Cipher Suites in Windows 8.1 - Win32 apps | Microsoft Docs), cross referencing this list with an examination of the system using IISCrypto and also the results of /usr/bin/openssl ciphers -v | grep TLSv1.2 on the Gitlab server. It appears that the cipher below is the only candidate supported by Server 2012 R2 and the Gitlab server:


So then I updated the /etc/gitlab/gitlab.rb file with the following:


And followed that with a sudo gitlab-ctl reconfigure && sudo gitlab-ctl hup nginx.

I checked the /var/opt/gitlab/nginx/conf/gitlab-http.conf file and confirmed the cipher was showing there.

# GitLab needs backwards compatible ciphers to retain compatibility with Java IDEs
  ssl_protocols  TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers off;
  ssl_session_cache  shared:SSL:10m;
  ssl_session_tickets off;
  ssl_session_timeout  1d;

However, a ssllabs.com scan, as well as a scan using testssl.sh (https://github.com/drwetter/testssl) does not show any changes to the cipher suites list.

Just to make sure I wasn’t crazy, I temporarily enabled TLS1.1 via /etc/gitlab/gitlab.rb, did a reconfigure and hup nginx, confirmed the gitlab-http.conf file was showing the change, and then re-ran my scans. To my surprise, TLS1.1 still didn’t show as an enabled protocol!

However, when I uncomment nginx[‘ssl_prefer_server_ciphers’] and set it to “on”, the scans do reflect “server order” which seems to imply the changes I am making are indeed finding their way to the running nginx web server instance. But I am at a loss as to why I cannot get the cipher I need to become available. Is there something I am missing?

Found the problem, though I am not sure why it only happened with the latest upgrade. It appears that the “DHE” ciphers are not available by default in Nginx releases greater than 1.11. Additionally, some operating systems, I suppose even Debian, do not setup a DHE key which results in the ciphers not being available. (Diffie–Hellman (DHE) Ciphers On Nginx Reliable Penguin - Blog)

I had to create the key and then configure the ssl_dhparam in /etc/gitlab/gitlab.rb.

Subsequent scan showed:

TLSv1.2 (server order)
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 253   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 253   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 253   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
 x9e     DHE-RSA-AES128-GCM-SHA256         DH 4096    AESGCM      128      TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
 x9f     DHE-RSA-AES256-GCM-SHA384         DH 4096    AESGCM      256      TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLSv1.3 (server order)
 x1302   TLS_AES_256_GCM_SHA384            ECDH 253   AESGCM      256      TLS_AES_256_GCM_SHA384
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 253   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256
 x1301   TLS_AES_128_GCM_SHA256            ECDH 253   AESGCM      128      TLS_AES_128_GCM_SHA256

And I still achieve the A+ SSL Lab’s rating.

1 Like