3

I need to enable TLSv1 and TLSv1.1 for backward compatibility. This is my setup.

>>> nginx -V
nginx version: nginx/1.16.1 (packages.exove.com: SSE2, openssl-1.1.1d, PCRE JIT, TCP Fast Open)
built by gcc 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) 
built with OpenSSL 1.1.1d  10 Sep 2019
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-pcre=../pcre-8.43 --with-pcre-jit --with-pcre-opt=-fPIC --with-openssl=../openssl-1.1.1d --with-libatomic --add-dynamic-module=../incubator-pagespeed-ngx-1.13.35.2-stable --build='packages.exove.com: SSE2, openssl-1.1.1d, PCRE JIT, TCP Fast Open' --with-openssl-opt=no-dtls --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC -mmmx -msse -msse2 -DTCP_FASTOPEN=23' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie'

And this is my nginx conf files.

nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    include /etc/nginx/conf.d/*.conf;

}

application conf file

server {

  server_name api.test.com;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;

  ssl_certificate         /etc/letsencrypt/live/api.test.com/fullchain.pem;
  ssl_certificate_key     /etc/letsencrypt/live/api.test.com/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/api.test.com/fullchain.pem;

  ssl_session_cache shared:MozSSL:10m;
  ssl_session_timeout 1d;
  ssl_session_tickets off;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
  ssl_prefer_server_ciphers off;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  add_header Strict-Transport-Security "max-age=31536000" always;
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 1.1.1.1 8.8.8.8 8.8.4.4 valid=60s;
  resolver_timeout 2s;


  location / {

    proxy_pass http://localhost:48515/;

    add_header Access-Control-Allow-Origin * always;
    add_header Access-Control-Allow-Headers * always;
    add_header Access-Control-Allow-Methods * always;

    proxy_pass_request_headers on;
    proxy_set_header           X-FILE $request_body_file;
    proxy_redirect             off;
    client_body_in_file_only   clean;

  }

}

ssllabs test says that only TLSv1.2 is enabled. What is my mistake?

yooneskh
  • 131
  • 3
  • 1
    No mistake. Both TLS 1.0 and 1.1 reach **END OF LIFE** at the end of this month, and should no longer be used. – Joel Coel Mar 04 '20 at 14:31
  • i have another server with similar setup which has TLS1.0 and TLS1,1 enabled and my application works correctly there. I know that these are deprecated but i need them for backward compatibility @JoelCoel – yooneskh Mar 04 '20 at 15:25
  • "Deprecated" is the wrong word. Okay, it's the right word for the moment... but that moment is passing faster than you realize. 3/31/2020 (just 4 weeks from now) "deprecated" changes to "dead". Google it. Are you ready for that? You're likely spending on effort putting duct tape over a cut, only to have it painfully peeled off very soon. Maybe this effort is better spent pushing to get away from the situation entirely? – Joel Coel Mar 04 '20 at 15:42
  • I completely agree with what you say. But my this server is going to serve android 4.X and i need TLSv1 and TLSv1.1 for those old devices. @JoelCoel – yooneskh Mar 04 '20 at 17:57
  • Android 4.x is also end-of-life, and has it's own serious active unpatched security issues. This is a good chance to push to update those devices. 5.1 is the minimum safe version of Android, and even that's pushing it. Again... you could probably make this work today, but you'll very likely find this effort **wasted** by the start of next month. – Joel Coel Mar 04 '20 at 18:01
  • I couldn't find any way to do it on my new server so i just moved my app to my old server which somehow has TLSv1.x enabled on its nginx. I would like to know why i couldn't enable it on my new server though. @JoelCoel – yooneskh Mar 04 '20 at 19:53

2 Answers2

3

Have similar issue because some of the client (api) still using old openssl and unable to upgrade in the mean time,

got it working after enable the protocol and chipper on my default_server too.

my sites-enable/default.conf

server {
  listen 443 ssl default deferred http2;
  listen [::]:443 ssl default deferred http2;
  server_name server.example.com;

  # Old configuration based on https://ssl-config.mozilla.org/
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;

# other default directive ....
} 

and my sites-enable/api.conf

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name api.example.com;
  root /home/user/api;

  # Old configuration based on https://ssl-config.mozilla.org/
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;

# other directive ....
}

The api is now able to service TLSv1.0,TLSv1.1 and the www locked to only use TLSv1.2 and TLSv1.3.

  • Where do you put the SSL key files? do you put any in the default block? – yooneskh May 09 '20 at 05:42
  • 1
    under the #other directive... I just copied the significant part of the setting. most of the other setting are like in the https://ssl-config.mozilla.org/#server=nginx&version=1.16.1&config=old – Sakurai Evsa May 10 '20 at 06:30
  • what kind of certificate did you issue to be able to put it in the default block and be applicable to all domains? – yooneskh May 10 '20 at 09:06
  • 1
    @yooneskh For the default block I am using the ssl for subdomain `server` for example I use the `server.example.com` certificate on the default block. and using `api.example.com` on the api block. tho if you have a wildcard certificate you can put same certificate on all block. for example using `certbot cloudflare dns` plugin to create `*.example.com` certificate. – Sakurai Evsa May 11 '20 at 14:29
  • Sorry to ask you so much and thank you for your time :) i have one more question. if we put a certificate for `server.example.com` (for example) in the default block of nginx, will it be ok for requests that come for `anothersub.anotherdomain.com` ? – yooneskh May 12 '20 at 19:12
  • 1
    if there is no `vhost` on your server that handle `anothersub.anotherdomain.com` it will return invalid certificates. or Privacy error in chrome with `NET::ERR_CERT_AUTHORITY_INVALID` the client then decide to ignore it and continue or cancel the request. – Sakurai Evsa May 13 '20 at 20:16
  • @Sakurai You save my hair, thanks. – DQM Jul 06 '20 at 09:26
0

I had simmiliar issues with an old apache installation. Maybe Let's encrypt bot has changed the standard configuration file?!