I ran a ssl certificate test on https://www.ssllabs.com/ssltest/ and I get a good rating but I see errors next to a few devices for example, under handshake simulation, Android 5.0 and 6.0 have the error message:
Server sent fatal alert: handshake_failure
Does this mean the website won't work on these devices or what does it mean?
My config file looks like this:
ssl_protocols TLSv1.2;# Requires nginx >= 1.13.0 else use TLSv1.2
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
# Add our strong Diffie-Hellman group
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
These ciphers are neither supported on Android 6 nor Android 5. Have a look at SSLLabs report for Android 6.0 to find out which ciphers are supported. Specifically no ciphers using SHA384 or SHA512 as HMAC are supported.
Related
Recently I am getting "SSL handshake failed" error on my Cloudflare websites.
When I looked at my nginx log I found the following errors:
2021/05/23 02:35:52 [info] 10528#0: *124920510 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 172.68.155.147, server: 0.0.0.0:443
2021/05/23 02:42:57 [info] 10528#0: *124925310 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 172.68.155.147, server: 0.0.0.0:443
2021/05/23 02:50:19 [info] 11633#0: *124929231 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 172.68.155.165, server: 0.0.0.0:443
2021/05/23 02:50:27 [info] 11632#0: *124929281 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 172.68.155.165, server: 0.0.0.0:443
2021/05/23 02:54:18 [info] 11633#0: *124930616 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 172.68.155.161, server: 0.0.0.0:443
Everytime SSL Handshake error occurs, "peer closed connection in SSL handshake" line gets added in the log.
Can you please tell me how can I fix this issue?
Nginx config
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name mydomain.in;
set $base /home/username/websites/mydomain.in;
root $base/;
# SSL
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
ssl_certificate /etc/letsencrypt/live/mydomain.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.in/privkey.pem;
# logging
access_log /home/username/nginx/logs/mydomain.in.access.log;
error_log /home/username/nginx/logs/mydomain.in.error.log debug;
# index.php
index index.php;
# index.php fallback
location / {
try_files $uri $uri/ /index.php?$query_string;
}
# handle .php
location ~ \.php$ {
include nginxconfig.io/php7.4_fastcgi.conf;
}
#include nginxconfig.io/general.conf;
# security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline' worker-src blob:" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# . files
location ~ /\.(?!well-known) {
deny all;
}
# favicon.ico
location = /favicon.ico {
log_not_found off;
access_log off;
}
# robots.txt
location = /robots.txt {
log_not_found off;
access_log off;
}
# assets, media
location ~* \.(?:css(\.map)?|js(\.map)?|jpe?g|png|gif|ico|cur|heic|webp|tiff?|mp3|m4a|aac|ogg|midi?|wav|mp4|mov|webm|mpe?g|avi|ogv|flv|wmv)$ {
expires 7d;
access_log off;
}
# svg, fonts
location ~* \.(?:svgz?|ttf|ttc|otf|eot|woff2?)$ {
add_header Access-Control-Allow-Origin "*";
expires 7d;
access_log off;
}
# gzip
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss application/atom+xml image/svg+xml;
}
Server Ubuntu 18.04
Nginx 1.16
No information can be extracted just based on the provided information on why these specific clients abandoned the TLS handshake. It might be some tests, it might be something else.
If these are normal browsers than a common cause is that the certificate provided by the server can not be verified by the client. This might for example happen with self-signed certificates, certificates issued by a non-public CA, missing intermediate certificates, mismatch of hostname ...
Given that these IP seem to belong to Cloudflare it might still be the a messed up setup of the certificates - simply giving the filenames without the actual content will not help though.
But again, just based on the provided log entries and config one can only do educated guesses and speculations.
I am trying to enable TLS 1.3 on my server. I have followed an abundance of articles on Google and have the same configs settings in my own config, yet I cannot get it past TLS 1.2.
I am on Ubuntu 16.
I am using NGINX version 1.14 which is built with OpenSSL 1.1.1.
➜ nginx -V
nginx version: nginx/1.14.2
built with OpenSSL 1.1.1 11 Sep 2018 (running with OpenSSL 1.1.1a 20 Nov 2018)
TLS SNI support enabled
These are all the required versions of the software I have seen that are needed to support TLS 1.3.
I'm using Chrome 72 and SSL Labs when testing the certificate but it just always says it's on 1.2.
Here is the part of my NGINX config file that's related to the SSL options
ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_ecdh_curve X25519:secp256k1:secp384r1:prime256v1;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES25
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 216.146.35.35 216.146.36.36 valid=60s;
resolver_timeout 2s;
I got the Ciphers from https://cipherli.st.
With these configuration options, I cannot get past the TLS 1.2 protocol.
I believe this is everything I can think of that might be causing me issues, but I can tell you of anything further you might need to know to help my case.
Thanks,
Chris
Enabling TLSv1.3 on Nginx might be looking pretty straight forward, but is not documented as it should.
Cutting to the chase now. The trick is to include the SSL settings in every server block of your config. Not doing so, will result in the fact of a disabled TLSv1.3. This makes sense in the way that the tls protocol is not "upgraded" upon the first request that hits the server:
sudo vi ssl_config
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Referrer-Policy no-referrer;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256: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;
ssl_prefer_server_ciphers on;
ssl_session_tickets on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_ecdh_curve auto;
keepalive_timeout 70;
ssl_buffer_size 1400;
ssl_dhparam ssl/dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=86400;
resolver_timeout 10;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
And:
server {
server_name xxx.xxx.xxx.xxx; #Your current server ip address. It will redirect to the domain name.
listen 80;
listen 443 ssl http2;
include ssl_config;
return 301 https://example.com$request_uri;
}
server {
server_name www.example.com;
listen 80;
listen 443 ssl http2;
listen [::]:80;
listen [::]:443 ssl http2;
include ssl_config;
# Non-www redirect
return 301 https://example.com$request_uri;
}
server {
server_name example.com;
listen 443 ssl http2;
listen [::]:443 ssl http2;
root /var/www/html;
charset UTF-8;
include ssl_config;
location ~* \.(jpg|jpe?g|gif|png|ico|cur|gz|svgz|mp4|ogg|ogv|webm|htc|css|js|otf|eot|svg|ttf|woff|woff2)(\?ver=[0-9.]+)?$ {
expires max;
add_header Access-Control-Allow-Origin '*';
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
access_log off;
}
#access_log logs/host.access.log main;
location ~ /.well-known/acme-challenge {
allow all;
root /var/www/html;
default_type "text/plain";
}
location / {
index index.php;
try_files $uri $uri/ /index.php?$args;
#limit_conn num_conn 15;
#limit_req zone=num_reqs;
}
error_page 404 /404.php;
#pass the PHP scripts to FastCGI server listening on php-fpm unix socket
location ~ \.php$ {
try_files $uri =404;
fastcgi_index index.php;
fastcgi_pass php:9000; #for docker.
#fastcgi_pass unix:/var/run/php7-fpm.sock; #for non-docker.
fastcgi_pass_request_headers on;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_request_buffering on;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
include fastcgi_params;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
}
Now it will work 100%, using the strongest ciphers available.
I made a blog post a while back about how to enable TLS 1.3 in Nginx.
As added bonus, as of versions 1.18.0, 1.17.10 and above,i maintain fresh tls1.3 enabled docker images
Your ssl_protocols should be ordered as TLSv1.2 TLSv1.3.
Then, your ssl_ciphers should include the list of TLSv1.3 ciphers first (in this order):
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
followed by your TLSv1.2 ciphers. Here's what tls13.iachieved.it nginx.conf looks like:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_prefer_server_ciphers on;
And connecting to it with Chrome 72:
And the response from the site:
Your User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Your client supports the following ciphers: 0x2a2a:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256: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:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:0x000a
The negotiated cipher with this server is: TLS_AES_256_GCM_SHA384
Note that the your client supports the following ciphers is what your web browser supports, not the server.
Did you also check /etc/nginx/sites-enabled/yoursite and if you are using Let's Encrypt, /etc/letsencrypt/options-ssl-nginx.conf? Only editing /etc/nginx/nginx.conf might not be enough.
I experienced the same problem today. For me, the reason was that I use letsencrypt's Certbot. It creates /etc/letsencrypt/options-ssl-nginx.conf, where the ssl-protocols are also defined. If you don't adjust them there, changing the /etc/nginx/nginx.conf won't help.
Be careful when editing /etc/letsencrypt/options-ssl-nginx.conf as it is managed by Cerbot. Check, if everything is still working using sudo certbot renew --dry-run.
For further reading, I recommend https://libre-software.net/tls-nginx/.
anyone seeing this should be sure they check/adjust the protocol and cipher list in their default server block in nginx.conf also.
Just try to start nginx with simply ssl configuration:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
My nginx confid files looks like:
server {
listen 80;
listen [::]:80;
server_name hostserver.ru www.hostserver.ru;
return 301 https://hostserver.ru$request_uri;
server_tokens off;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name hostserver.ru www.hostserver.ru;
ssl_certificate /etc/letsencrypt/live/hostserver.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/hostserver.ru/privkey.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-R$
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000" always;
ssl_stapling on;
ssl_stapling_verify on;
root /var/www/html;
index index.html index.htm;
server_tokens off;
... some location stuff...
}
Ufortunatelly, TLS1.2 not supported by Android 4.0-4.3 and I've chanched config:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
But after using SSLTest it shows me report that TLS1 and TLS1.1 are not supported.
Did I missed smth to change in config files?
Thanks in advance.
UPDATE: I've checked certificates by command:
openssl s_client -tls1 (and so on) -connect example.org:443 < /dev/null
and certificate enabled for each protocol.
I don't know which ciphers work with TLSv1 and TLSv1.1. But I notice from testing sites with SSLTest, that the GCM ciphers are listed against TLSv1.2 only.
You may need to use a more inclusive list of ciphers.
For example:
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
After creating 7 SSL Certificates with Let's Encrypt, I have stumbled upon this error. I had setup all my configs correct and I scanned my whole site for SSL Vulnerabilities on [SSLLabs.com][1] and it told me that my server's certificate chain is incomplete.
The grading picture:
My SSL Grading
The error:
The error I got
I am running CentOS Linux release 7.2.1511 (Core) as a Reverse Proxy in NginX. And my configuration is:
# GhostAntiDDoS
server {
listen 443 ssl;
server_name ghostantiddos.com *.ghostantiddos.com;
ssl on;
ssl_certificate /etc/letsencrypt/live/ghostantiddos.com/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/ghostantiddos.com/privkey.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
add_header Strict-Transport-Security max-age=15768000;
# Bulletin
#limit_conn conn_limit_per_ip 10;
#limit_req zone=req_limit_per_ip burst=5 nodelay;
client_body_timeout 5s;
client_header_timeout 5s;
....
The rest of the parts are hidden as they will expose my origin.
If anyone could assist me in this, I'd be great!
Replace
certificate /etc/letsencrypt/live/ghostantiddos.com/cert.pem
by
certificate /etc/letsencrypt/live/ghostantiddos.com/fullchain.pem
then test again with https://ssllabs.com
SSLlabs still show the following message even after i added the ssl_session_cache
Session resumption (caching) No (IDs assigned but not accepted)
Here is my full configuration
server {
listen 443 spdy; #Change to 443 when SSL is on
ssl on;
ssl_certificate /etc/ssl/domain.com_bundle.crt;
ssl_certificate_key /etc/ssl/domain.com.key.nopass;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
#ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_buffer_size 8k;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/trustchain.crt;
resolver 8.8.8.8 8.8.4.4;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
#rest config goes here
}
SSL Labs doesn't assume that SNI is available to the client, so it only tests the default virtual server.
The problem could be that you don't have SSL session caching enabled on the default server. To enable it, you just need to add that ssl_session_cache line to your default_server. Alternatively, if you'd like that configuration the work across all of your nginx virtual servers (which I would recommend), you could move the ssl_session_cache line outside of the server declaration, so it applies to all of them.
Here's the configuration I use:
# All your server-wide SSL configuration
# Enable SSL session caching for improved performance
# http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache
ssl_session_cache shared:ssl_session_cache:10m;
server {
# All your normal virtual server configuration
}
Sources:
I tested both options on my own server and SSL Labs loves it!
This thread on the Nginx mailing list
when you use one server, it be correct. If you have load balance before servers, it may be like this. Because of request can not transmit to same server before. I suggest ssl_session_tickets.