TLSv1.3 support and OpenSSL 1.1.1

[julianxhokaxhiu]

I saw that your current image is build on top of OpenSSL 1.0.2k.

Any plan to move to the newest one, in order to enable support for TLS 1.3?

---

//EDIT: Sorry, I saw it now that is still to be released ( https://www.openssl.org/news/changelog.html#x0 ). Can you please keep this issue anyway in your future plans? Would be nice to have support for TLS 1.3.

[thresheek]

There are no plans for that; It'd be automatically available when distributions we use (namely Debian and Alpine) will import openssl-1.1.1.

[julianxhokaxhiu]

Good to know :) Thank you!

[McKinleyGroup]

Hi @julianxhokaxhiu

In the meantime it works:

nginx -v

nginx version: nginx/1.14.0

nginx -V

nginx version: nginx/1.14.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
built with OpenSSL 1.1.1-dev xx XXX xxxx
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-openssl=openssl --with-openssl-opt=enable-tls1_3

openssl version

OpenSSL 1.1.1-pre5 (beta) 17 Apr 2018

Today, there is even a newer version out:

https://www.openssl.org/source/openssl-1.1.1-pre6.tar.gz

Haven't tested OpenSSL 1.1.1 pre6 so far! :-)

Hope it helps!

[sanderkoenders]

Unfortunately it doesn't work for the Alpine image yet because Alpine does not ship with openssl > 1.1.1 yet..

[julianxhokaxhiu]

What about using libressl on Alpine? I saw Nginx can compile just fine with it.

[sanderkoenders]

Does libressl on alpine offer support for the new TLSv3?

[julianxhokaxhiu]

Looking at this issue ( libressl/portable#228 ), the official documentation ( https://man.openbsd.org/TLS_method.3 ) and the Wikipedia page ( https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations ) it seems it doesn't. I was too optimistic.

But boringssl does ( https://github.com/google/boringssl ). and it seems Nginx can be compiled with it too ( cloudflare/sslconfig#87 ). Actually this looks like to me the best option as BoringSSL is a fork of OpenSSL ( most compatible actually then LibreSSL could be )

An example of Nginx with BoringSSL using Alpine: https://github.com/nginx-modules/docker-nginx-boringssl

[sanderkoenders]

Hmm, in my opinion we should stick with one of the official versions even if that means we have to wait, libressl and openssl sound good in that regard, boringssl not so much..

[McKinleyGroup]

Hi all:

Nginx 1.14 and 1.1.5 can be compiled with support for TLS 1.3. Reportedly Nginx 1.13 should work to, but I haven't tested it...

---

#nginx -V

nginx version: nginx/1.14.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
built with OpenSSL 1.1.1-dev xx XXX xxxx
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-openssl=openssl --with-openssl-opt=enable-tls1_3

[McKinleyGroup]

Hi @julianxhokaxhiu

https://csrc.nist.gov/CSRC/media/Publications/sp/800-52/rev-2/draft/documents/sp800-52r2-draft.pdf

In (DRAFT) of NIST Special Publication 800-52, Revision 2
Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

it states: "(...) shall be configured to use TLS 1.2, and should be configured to use TLS 1.3. These servers should not be configured to use TLS 1.1, and shall not use TLS 1.0, SSL 3.0, or SSL 2.0."

So, TLS 1.2 and TLS 1.3 are allowed and any older protocol is forbidden... :-)

@Archcry

Hmm, in my opinion we should stick with one of the official versions even if that
means we have to wait, (...)

Like you would stick with Linux Kernel 3.10 in CentOS 7 / RHEL 7?

In the era of GDPR I would suggest to take cyber security finally more seriously and switch to Linux Kernel 4.16.14 and switch to TLS 1.2 and TLS 1.3... :-)

[sanderkoenders]

I don't think you get the point, Nginx will work just fine with TLSv1.3 but the problem lies with openssl in alpine not being up to date.

In the era of GDPR I would suggest to take cyber security finally more seriously and switch to Linux Kernel 4.16.14 and switch to TLS 1.2 and TLS 1.3... :-)

you're talking about an extreme scenario here, it's not like we need TLSv1.3 because alternatives aren't safe. TLSv1.2 is safe so I don't see why we can't wait for Alpine to update openssl. You're talking as if TLSv1.3 is the only safe piece of software at the moment.

[McKinleyGroup]

@Archcry
TLS 1.2 actually isn't safe... and that's the problem!

Please read e.g. Cisco's blog:

https://blogs.cisco.com/security/tls-1-3-and-forward-secrecy-count-us-in-and-heres-why

Security Fans are Forward Secrecy Fans

The goal of forward secrecy is to protect the secrecy of past sessions so that a session stays secret going forward. With TLS 1.2 and earlier versions, a bad actor who discovered a server’s private key could use it to decrypt network traffic that had been sent earlier. For example, suppose someone started recording encrypted traffic in our network on January 1st and then discovered a server’s private key on January 31st. That person could decrypt all of the server’s traffic and make off with the credit card numbers we entered yesterday, our lab results from last week, and our team’s patent application from the week before.

With the forward secrecy in TLS 1.3, there’s no longer a single secret value that will decrypt multiple sessions. Instead, TLS 1.3 uses the Ephemeral Diffie-Hellman key exchange protocol, which generates a one-time key that’s used only for the current network session. At the end of the session, the key is discarded. While attackers can still record and store encrypted network traffic, to decode it they need the unique key for each session. A session key won’t decode data sent during an earlier session or help an attacker discover future session keys.

Forward secrecy is a best practice for security—which is why we’re all for it.

[sanderkoenders]

But still, the issue lies with Alpine, they should update their openssl

[McKinleyGroup]

@Archcry

But still, the issue lies with Alpine, they should update their openssl

I agree with you on that of course! :-)

[sanderkoenders]

Anyways, I though boringssl was some kind of shady fork of openssl but it turns out it's forked by Google. So if boringssl is upt-do-date in Alpine and supports TLSv1.3 for Nginx it would be an option to use that for the Alpine docker image.

[tnguyenns1]

It's just me or even nginx 1.15.0 image doesn't have openssl 1.1.1, which i'm waiting for to enable TLS1.3?

$ docker run --rm -it nginx:1.15.0 nginx -V

nginx version: nginx/1.15.0
built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled

[ghadishayban]

Some alpine + TLS1.3 images available here -- using OpenSSL 1.1.1-beta9. (It supports TLS 1.3 final, not the draft version. Currently non-nightly browsers don't support the final version)

[J0WI]

OpenSSL 1.1.0 is now available in the edge branch of Alpine Linux:
https://pkgs.alpinelinux.org/packages?name=openssl1.1&branch=edge

The upgrade from 1.1.0 to 1.1.1 shouldn't break any APIs. So I'm looking forward to get TLS 1.3 with the next Alpine Linux release and Debian backports, once 1.1.1 has been released.

[sanderkoenders]

Ye the final release should not be far away now.

[julianxhokaxhiu]

What about re-opening this issue until is really fixed?

[sanderkoenders]

"11-Sep-2018 | Final version of OpenSSL 1.1.1 (LTS) is now available: please download and upgrade!"

Let's hope it'll make its way into alpine soon.

[J0WI]

You can track it here:
alpinelinux/aports#5143
https://tracker.debian.org/pkg/openssl/news/

@thresheek would you accept a PR for an image based on a backports/edge/testing base, due the high interest in OpenSSL 1.1.1 support?

[thresheek]

No, and until nginx supports 0RTT I dont see any point in moving to openssl 1.1.1.

[Santinell]

pros:

1. New crypto algorithms
2. Crypted handshakes

So 1.3 is more secure than 1.2 by default

cons:
No

[gfrankliu]

Another pro is openssl 1.1.1 supports early callback which allows us to use different ssl_protocols on a per virtual host level: https://trac.nginx.org/nginx/ticket/844

[McKinleyGroup]

Hi @gfrankliu

Another pro is openssl 1.1.1 supports early callback which allows us to use different
ssl_protocols on a per virtual host level: https://trac.nginx.org/nginx/ticket/844

mydomain.com and www.mydomain.com both support TLS1.0, TLS1.1 and TLS1.2:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

aaa.mydomain.com and bbb.mydomain.com however should only use TLS1.2

Why don't use you just TLS 1.2 (as fallback) and TLS 1.3 (otherwise)? Just one config and move on?
Why would you want to use protocols (TLS 1.0 and 1.1) which have been hacked & or are hackable?

https://www.infoworld.com/article/2620383/security/red-alert--https-has-been-hacked.html

In my experience, straddling too many different configs never works well...

[McKinleyGroup]

Hi @gfrankliu

It's time for TLS 1.0 and 1.1 to die (die, die) • The Register Forums

https://forums.theregister.co.uk/forum/1/2018/06/19/ietf_calls_for_formal_tls_1_0_1_1_deprecation/

I think it's time to let TLS 1.0 and TLS 1.1 RIP.

[gfrankliu]

There are reasons 1.0/1.1 still there. Only PCI sites deprecated TLSv1.0 for now.
Why do you think you still see 1.0/1.1 in this report: https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com

[McKinleyGroup]

Hi @gfrankliu

There are reasons 1.0/1.1 still there.

Like what? To keep sites hackable? Seriously?!!

There are reasons 1.0/1.1 still there. Only PCI sites deprecated TLSv1.0 for now.
Why do you think you still see 1.0/1.1 in this report: https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com

Google frequently screws up cyber security and has minor hacks only, or shall we say admits only to minor hacks? Regardless, Yahoo had a similar disregard for cyber security and got all 3 billions accounts hacked!

Yahoo says all three billion accounts hacked in 2013 data theft

https://www.reuters.com/article/us-yahoo-cyber/yahoo-says-all-three-billion-accounts-hacked-in-2013-data-theft-idUSKCN1C82O1

[McKinleyGroup]

@lubo

Looks like OpenSSL 1.1.1 is coming to Ubuntu 18.04.

Wow, finally some progress!!!! :-)

[J0WI]

Alpine 3.9.0 has just been released, so as soon as the base image is build this can be fixed. 🎉

[McKinleyGroup]

Hi @J0WI

Alpine 3.9.0 has just been released, so as soon as the base image is build this can be fixed.

Wow, that's truly amazing! :-)

[McKinleyGroup]

NGINX has webinar which might be useful:

TLS 1.3 and Other New Features in NGINX Plus R17 and NGINX Open Source:
https://twitter.com/RealPro4Real/status/1090564669117353985

[aiomaster]

I tried with the new image but could not get it to work.
The relevant parts of my nginx config:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-ARIA256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384;
ssl_ecdh_curve X25519:secp521r1:secp384r1;
ssl_prefer_server_ciphers on;

It doesn't seem to give me TLS 1.3

$ openssl s_client -tls1_3 my-domain-replaced-here:443                                                                                                                        
CONNECTED(00000005)
140577738282816:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1528:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 250 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

My nginx is this:

# nginx -V
nginx version: nginx/1.15.8
built by gcc 8.2.0 (Alpine 8.2.0) 
built with OpenSSL 1.1.1a  20 Nov 2018
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-threads --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-stream_geoip_module=dynamic --with-http_slice_module --with-mail --with-mail_ssl_module --with-compat --with-file-aio --with-http_v2_module

Can someone confirm, that the new alpine nginx image really works with TLS 1.3?

[sanderkoenders]

@aiomaster, I checked this yesterday and pulled the latest image, turns out it was still running on the old version of Alpine (3.8) which does not have openssl 1.1.1. I pulled nginx:alpine this morning (9 hours old at that time) and this one does run the latest alpine version making TLS1.3 available! Have fun pulling the latest image and enjoy TLS1.3!

[julianxhokaxhiu]

As of this commit now Nginx can finally run on TLS 1.3.

Closing the issue as this is no more :)

[samkelleher]

Same as @aiomaster above, same config, pulled the latest image but nginx won't serve TLS1.3 despite having the required versions to do so 😩 pulling from nginx:alpine

nginx version: nginx/1.15.8
built by gcc 8.2.0 (Alpine 8.2.0)
built with OpenSSL 1.1.1a  20 Nov 2018

[J0WI]

Works for me like a charm.
Please note that TLSv1.3 is not enabled by default, so you need to adjust your ssl_protocols:
https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols

[aiomaster]

As you can see in my config, I did that, but could not get it to work.
But if it works for you maybe there is another problem somewhere in my config. I tried to find it but with no luck atm.

[CaptainGlac1er]

Hype! It worked for me! :)

[samkelleher]

@CaptainGlac1er @J0WI @julianxhokaxhiu if it works for you can you provide a snippet of your nginx config to use as an example?

[J0WI]

You can use https://www.ssllabs.com/ssltest/ to verify your config.
Not all ciphers are compatible with TLSv1.3, so make sure that TLS_CHACHA20_POLY1305_SHA256, TLS_AES_256_GCM_SHA384 or TLS_AES_128_GCM_SHA256 are supported.

[CaptainGlac1er]

@samkelleher will do when I get home

[McKinleyGroup]

if it works for you can you provide a snippet of your nginx config to use as an example?

Yes, of course! :-)

https://www.ssllabs.com/ssltest/analyze.html?d=cloudinsidr.com

How to Activate HTTP/2 with TLS 1.3 Encryption in NGINX for Secure Connections without a Performance Penalty

https://www.cloudinsidr.com/content/how-to-activate-http2-with-ssltls-encryption-in-nginx-for-secure-connections/#more-123

[samkelleher]

maybe there is another problem somewhere in my config

@aiomaster What else is there in the config, global, other servername bindings.

The below config reports running normally, but any request to it remains TLS1.2.

server {
   listen       443 ssl http2;
   listen       [::]:443 ssl http2;
   server_name  abc.example.com;
   ssl_certificate /etc/letsencrypt/live/abc.example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/abc.example.com/privkey.pem;
   ssl_trusted_certificate /etc/letsencrypt/live/abc.example.com/chain.pem;
   ssl_session_timeout 1d;
   ssl_session_cache shared:SSL:50m;
   ssl_session_tickets off;
   ssl_stapling on;
   ssl_stapling_verify on;
   ssl_protocols TLSv1.3 TLSv1.2;
   ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:TLS-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES;
   ssl_prefer_server_ciphers on;
   ssl_dhparam /etc/nginx/ssl/dhparams.pem;
   proxy_pass_header Server;

   location / {
       proxy_set_header Host $http_host;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection $proxy_connection;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Real-Port $remote_port;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
       proxy_set_header X-Forwarded-Host $http_host;
       proxy_set_header X-SSL-Cipher $ssl_cipher;
       proxy_set_header X-SSL-Protocol $ssl_protocol;
       proxy_set_header X-SSL-SNI $ssl_server_name;
       proxy_set_header X-SSL-SessionId $ssl_session_id;
       proxy_set_header X-SSL-SessionReused $ssl_session_reused;
       proxy_set_header X-HTTP-Proto $server_protocol;
       proxy_set_header X-HTTP2-Proto $http2;
       proxy_set_header X-Connection-Serial $connection;
       proxy_set_header X-Connection-Requests $connection_requests;
       proxy_pass http://web:8080;
   }
}

[CaptainGlac1er]

@samkelleher This shows up as TLSv1.3 on ssllabs (fyi just don't copy and paste the entire thing as this one is more strict and I haven't fully optimized for 1.3 yet)
https://github.com/CaptainGlac1er/serverFramework/blob/master/proxy/includes/ssl.conf

[aiomaster]

If anyone is interested (I know this is not a support forum, but maybe it is helpfull):
My problem was, that I did not specified a default_server so the behaviour of nginx is to use the first defined server. This is important cause ssllabs does not use SNI for its tests and so your "default server" answers. And if you don't have you ssl settings right there, it seems that TLS1.3 is not enabled.
Sorry for the noise.

[gfrankliu]

If anyone is interested (I know this is not a support forum, but maybe it is helpfull):
My problem was, that I did not specified a default_server so the behaviour of nginx is to use the first defined server. This is important cause ssllabs does not use SNI for its tests and so your "default server" answers. And if you don't have you ssl settings right there, it seems that TLS1.3 is not enabled.
Sorry for the noise.

ssllabs does support SNI. Your issue is nginx doesn't support ssl_protocols settings on the per server level. The default ssl_protocols overrides all virtual hosts. See my comment above #190 (comment)

[AnatomicJC]

Many thanks @aiomaster for your feedback regarding default_server settings. I had same problem than you.

[ripper2hl]

Thanks, it works

docker run --rm -it nginx:1.15-alpine  nginx -V
Unable to find image 'nginx:1.15-alpine' locally
1.15-alpine: Pulling from library/nginx
Digest: sha256:e0292d158b6b353fde34909243a4886977cb9d1abb8a8a5fef9e0ff7138dd3e2
Status: Downloaded newer image for nginx:1.15-alpine
nginx version: nginx/1.15.8
built by gcc 8.2.0 (Alpine 8.2.0) 
built with OpenSSL 1.1.1a  20 Nov 2018
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-threads --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-stream_geoip_module=dynamic --with-http_slice_module --with-mail --with-mail_ssl_module --with-compat --with-file-aio --with-http_v2_module

[Amunak]

Aaand nginx 1.14 is now stable, and not even mainline debian build is built against OpenSSL 1.1.1.

When can we expect the debian-mainline to be able to use TLSv1.3?

[chand3257]

bash-4.3# nginx -V
nginx version: nginx/1.18.0
built by gcc 6.2.1 20160822 (Alpine 6.2.1)
built with OpenSSL 1.0.2q 20 Nov 2018
TLS SNI support enabled

How i will update OpenSSL 1.0.2q to 1.1.1 inside alpine container? Please help me out.