Add support for TLS 1.3 #228
Comments
|
It will happen at some point, but there's currently no specific timeline. |
|
+1 on that thread. Anyone has a timeline (or a rough estimation)? |
|
OpenSSL plans to ship TLS 1.3 in about three weeks (April 5): https://blogs.akamai.com/2017/01/tls-13-ftw.html |
|
As noted in https://www.mail-archive.com/openssl-dev@openssl.org/msg46709.html, OpenSSL has code that is "available" rather than "released". That aside, TLSv1.3 is still a draft and is not yet standardised. Additionally, we are well aware of the draft implementations in BoringSSL and OpenSSL. |
|
Apparently nginx already supports 1.3 though?? Somehow |
|
nginx has only added support for |
|
You know, I am really thinking that those who are dying for a draft implementation of a not yet ratified standard could run code from other projects with a proven track record of draft quality implementations of not yet ratified standards.... |
|
TLSv1.3 is still a draft and is not yet standardised largely due to industries that make a lucrative trade on SSL/TLS intercept products for enterprises not yet knowing how to "break" the protocol and allow it to properly proxy across their appliances. Please dont let draft prevent the inclusion of an important advancement of the protocol. |
|
Amazing. I would not have known any of that if someone hadn't posted it
into a github PR..
…On Sat, Mar 24, 2018 at 5:19 AM, Denis Denisov ***@***.***> wrote:
The Committee IETF (Internet Engineering Task Force), engaged
<http://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html>
in the development of protocols and architecture of the Internet, approved
the final version of the specification
<https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/> defines a TLS
1.3, as the "Proposed standard" (Proposed Standard). Those involved in the
development of TLS Protocol members of the working group (Transport Layer
Security Working Group) were able to reach consensus and voted to
standardize the 28 draft specifications (all voted "Yes", excluding Warren
Kumari <https://research.google.com/pubs/WarrenKumari.html> from Google,
who voted "I don't mind", explaining
<https://www.ietf.org/mail-archive/web/tls/current/msg25562.html> that he
is not an expert on the issue under discussion). The installation of secure
connections using TLS 1.3 is already supported in Firefox and Chrome, and
will be offered in the OpenSSL 1.1.1 branch.
Features of TLS 1.3:
- Disposal of obsolete and unreliable cryptographic primitives (MD5,
SHA-224) and capabilities (compression, re-negotiation, non-AEAD ciphers,
static key exchange RSA and DH, specifying a unix-time in Hello-messages,
etc.);
- In mode perfect forward secrecy (PFS, Perfect Forward Secrecy
<https://ru.wikipedia.org/wiki/Perfect_forward_secrecy>), in which the
compromise of one of the long-term keys does not allow you to decrypt
previously captured sessions. Leaving only PFS support caused a lot of
controversy <https://www.cs.uic.edu/%7Es/musings/tls13-enterprises/>
and became a stumbling block in reaching consensus, as a number of
manufacturers pointed to the possible negative impact of PFS on corporate
systems, on-premises networks of which are used
<https://www.ietf.org/mail-archive/web/tls/current/msg21275.html>
inspection of passing traffic, for example, to ensure fault tolerance,
monitoring, problem diagnosis, malware filtering and detection of attacks.
- Reducing the number of steps in soglasovanii connections and mode
support 0-RTT <https://blog.cloudflare.com/introducing-0-rtt/> to
eliminate delays in the resumption of the previously established HTTPS
connections. When you install an HTTPS connection are 4 stages: DNS lookup,
TCP Handshake (1 RTT), the TLS Handshake (2 RTTS to the key agreement
parameters and an encrypted channel) and send a HTTP request (1 RTT).
Compared to TLS 1.2 in the new standard, the number of RTT for TLS
Handshake is reduced from 2 to 1, i.e. for the installation and resumption
of a connection requires a DNS query and 3 of the communication cycle (RTT)
instead of 4. 0-RTT allows you to save the previously agreed parameters of
the TLS and to reduce to 2 the number of RTT when resuming a previously
established connection;
- Support for the ChaCha20 <http://cr.yp.to/chacha.html> stream cipher
and the Poly1305 <http://cr.yp.to/mac.html> message authentication
algorithm developed by Daniel Bernstein (Daniel J. Bernstein
<http://cr.yp.to/djb.html>), Tanja Lange (Tanja Lange), and Peter
Schwabe (Peter Schwabe). ChaCha20 and Poly1305 can be considered as faster
and safer analogues of AES-256 CTR and HMAC, the software implementation of
which allows you to achieve a fixed run time without using special hardware
accelerators;
- Support for secure Ed25519 <http://ed25519.cr.yp.to/> authentication
keys, which have a higher level of security than ECDSA and DSA, with a very
high rate of verification and signature creation. Resistance to cracking
for Ed25519 is of the order of 2^128 (the average for the attack on
Ed25519'll need to make 2^140 bitwise operations), which corresponds to the
resistance of different algorithms such as NIST P-256 and RSA with the key
size of 375 bytes, or 128-bit block cipher. Ed25519 is also not affected by
problems with the collisions in the hashes are not sensitive to attacks
over the definition of the speed of the cache (cache-timing attacks
<http://cr.yp.to/antiforgery/cachetiming-20050414.pdf>) and side
channel attacks (side-channel attacks);
- Support key exchange based algorithm x25519
<https://en.wikipedia.org/wiki/Curve25519> (RFC 7748
<https://tools.ietf.org/html/rfc7748>) x448 and (RFC 8031
<https://tools.ietf.org/html/rfc8031>);
- Support HKDF <https://en.wikipedia.org/wiki/HKDF> (HMAC-based
Extract-and-Expand Key Derivation Function).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#228 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHv2dQtpDBMul6JHlV_aUxYDEdI_LyEJks5thivdgaJpZM4KEGQu>
.
|
|
We will support 1.3 once the standard is firmed up and finalized (i.e. ceases to be coopted by vendors making changes to allow for people to continue to run moribund middle boxes that can't recognize a new protocol on the wire) Since there is effectively nothing wrong with TLS 1.2 with a sanely chosen cipher suite today, we believe a clean careful implementation is more beneficial than early adoption. |
|
FWIW 1.3 was finalized and approved by the IETF last wednesday. please check: in my opinion this should probably remain a secure-by-default "off" feature unless a gas leak in the users office has convinced them to enable it for some reason. Thanks again for your dedication and careful consideration. |
|
Is there a plan/roadmap for TLS 1.3? |
|
What is the status of TLSv1.3 in LibreSSL 2.9.0? I can see it's in the source, but disabled by default. Is it incomplete yet, or just not tested thoroughly? If you need testers, I can compile with LIBRESSL_HAS_TLS1_3. |
|
Same here, I am more than willing to test it out. |
|
TLS 1.3 support is in development, as you have noticed. There will be an announcement when the implementation is ready for wider testing. It's not ready currently, so defining LIBRESSL_HAS_TLS1_3 will not help much. |
|
What is the roadmap for TLS1.3 in LibreSSL？ |
|
No news? |
|
The roadmap is -> it is being worked on. We are volunteers so it will be finished when it is finished.. client side works. |
|
@bob-beck That's great and thanks for all the work. When are you going to release a version which includes client side? Currently, I only care about client side, so it'd help a lot. |
|
Client side was enabled with 3.1.0, and server side has come up in the upstream. |
|
Forgive me if this is not in the scope, as I'm not fully up to speed on the inner workings of TLS. But I've been having trouble with OpenVPN compiled against LibreSSL 3.1.3 connecting to a server (ProtonVPN) which uses a TLS 1.3 cipher, specifically Problem is, I'm not seeing it listed in: If client side was enabled, is there a reason I don't see it listed here? Do I need to compile it myself with additional build flags? Thanks for any help. Edit: and sorry, I realize that's output from OpenVPN, but I also checked with: and don't see it there. |
|
The OpenSSL API is not implemented yet. |
|
Oh, I see. Thanks! I was unsure how that worked. I'll keep an eye out for that. |
|
3.2.2 is released with client and server TLS 1.3 on by default when using the regular API. Adding support for the new OpenSSL tls 1.3 specific API's is a separate issue (and will be addressed later) |
|
Does that mean v3.2.2 should bring TLS 1.3 support to nginx? Cause It's not working for me :( |
|
On Mon, Oct 19, 2020 at 11:55:56AM -0700, leonklingele wrote:
Does that mean v3.2.2 should bring TLS 1.3 support to nginx? Cause It's not working for me :(
This is expected.
nginx does its own version selection and turns off TLSv1.3 unless
TLS1_3_VERSION is defined:
https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L364-L367
We can't define TLS1_3_VERSION publicly yet since this would break other
software that assumes OpenSSL TLSv1.3 API to be present if TLS1_3_VERSION
is defined. We didn't have time to implement and test this API before
this release.
Passing -DTLS1_3_VERSION=0x0304 on nginx's compiler command line
(CFLAGS) or adding
```
#ifndef TLS1_3_VERSION
#define TLS1_3_VERSION 0x0304
#endif
```
before the lines linked above would make nginx use TLSv1.3.
|
|
Thank you, @botovq! Nice work, LibreSSL team! :)
|
|
This is what I get on ssllabs.com with nginx-1.19.3 and v3.2.2 with the TLS 1.3 "patch" from #228 (comment):
|
|
On Mon, Oct 19, 2020 at 11:55:52AM -0700, leonklingele wrote:
Does that mean v3.2.2 should bring TLS 1.3 support to nginx? Cause It's not working for me :(
That would be an issue for nginx, not for libressl. If you do as suggested when compiling
it will work.
This issue is closed, we support 1.3 If you would like to open an issue for nginx
to not turn off 1.3 support when using Libressl you should probably take that
up with nginx.
…
--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
#228 (comment)
|
|
Sorry for disturbing in this closed issue. But LIBRESSL_HAS_TLS1_3 is still not defined in opensslfeatures.h, and therefore OPENSSL_NO_TLS1_3 is defined. Is it meant to be so? |
|
On Tue, Dec 01, 2020 at 04:53:21AM -0800, Stefan Strogin wrote:
Sorry for disturbing in this closed issue. But LIBRESSL_HAS_TLS1_3 is still not defined in opensslfeatures.h, and therefore OPENSSL_NO_TLS1_3 is defined. Is it meant to be so?
@steils: Yes. There are feature checks that guard use of OpenSSL's TLSv1.3 API
(such as SSL_set_ciphersuites() which we do not publicly expose yet) with either
OPENSSL_NO_TLS1_3 or TLS1_3_VERSION or something similar. Thus, we will
only be able to define LIBRESSL_HAS_TLS1_3 once the OpenSSL compat layer
is completed. We're working on it.
|
set Ciphersuites once API is available (SSL_CTX_set_ciphersuites()) in LibreSSL. x-ref: "Add support for TLS 1.3" libressl/portable#228
|
Hello, is there any ETA on proper tls 1.3 support? It appears postfix 3.6 is currently unsupported with libressl due to this feature. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255677 |
@dgerzo - I presume that by "proper tls 1.3 support" you're referring to the OpenSSL 1.1 APIs - if so, the 3.4.0 release (September 2021) included these. |
|
@4a6f656c - by "proper 1.3 support" I mean I will be able to compile and use postfix :) I tried to compile it with 3.4.2 and it still does not work - see the full log here: https://danger.rulez.sk/postfix-13x64-default.txt |
|
Looks like this macro is undefined. What happens when you set it the value from https://github.com/openssl/openssl/blob/09345c8cab01d0030234a001c7b2d64eac1e75ae/include/openssl/x509_vfy.h.in#L693? |
Will LibreSSL wait for OpenSSL to add TLS 1.3 support?
openssl/openssl#963
The text was updated successfully, but these errors were encountered: