OpenSSL Using TLS1.3 With OpenSSL 1.1.1

eva2000 · Feb 14, 2018

OpenSSL folks have updated their blog with a new article Using TLS1.3 With OpenSSL - OpenSSL Blog just in time for the first OpenSSL 1.1.1-pre1 alpha release

Differences with TLS1.2 and below
TLSv1.3 is a major rewrite of the specification. There was some debate as to whether it should really be called TLSv2.0 - but TLSv1.3 it is. There are major changes and some things work very differently. A brief, incomplete, summary of some things that you are likely to notice follows:

There are new ciphersuites that only work in TLSv1.3. The old ciphersuites cannot be used for TLSv1.3 connections.

The new ciphersuites are defined differently and do not specify the certificate type (e.g. RSA, DSA, ECDSA) or the key exchange mechanism (e.g. DHE or ECHDE). This has implications for ciphersuite configuration.

Clients provide a “key_share” in the ClientHello. This has consequences for “group” configuration.

Sessions are not established until after the main handshake has been completed. There may be a gap between the end of the handshake and the establishment of a session (or, in theory, a session may not be established at all). This could have impacts on session resumption code.

Renegotiation is not possible in a TLSv1.3 connection

More of the handshake is now encrypted.

More types of messages can now have extensions (this has an impact on the custom extension APIs and Certificate Transparency)

DSA certificates are no longer allowed in TLSv1.3 connections

Note that at this stage only TLSv1.3 is supported. DTLSv1.3 is still in the early days of specification and there is no OpenSSL support for it at this time.
Click to expand...

Ciphersuites
OpenSSL has implemented support for five TLSv1.3 ciphersuites as follows:

TLS13-AES-256-GCM-SHA384

TLS13-CHACHA20-POLY1305-SHA256

TLS13-AES-128-GCM-SHA256

TLS13-AES-128-CCM-8-SHA256

TLS13-AES-128-CCM-SHA256

Of these the first three are in the DEFAULT ciphersuite group. This means that if you have no explicit ciphersuite configuration then you will automatically use those three and will be able to negotiate TLSv1.3.

All the TLSv1.3 ciphersuites also appear in the HIGH ciphersuite alias. The CHACHA20, AES, AES128, AES256, AESGCM, AESCCM and AESCCM8 ciphersuite aliases include a subset of these ciphersuites as you would expect based on their names. Key exchange and authentication properties were part of the ciphersuite definition in TLSv1.2 and below. This is no longer the case in TLSv1.3 so ciphersuite aliases such as ECDHE, ECDSA, RSA and other similar aliases do not contain any TLSv1.3 ciphersuites.
Click to expand...

eva2000 · Mar 3, 2018

What is SSL? (And why it’s time to upgrade to TLS 1.3)

The next major version of the protocol, TLS 1.3, will soon be finalized — and most anyone who runs a website will want to upgrade, because cybercriminals are catching up.
Click to expand...

TLS 1.2 and TLS 1.2 vulnerabilities
TLS 1.2 is the most current defined version of the protocol, and it has been for several years. It established a host of new cryptographic options for communication. However, like some previous versions of the protocol, it also allowed older cryptographic techniques to be used, in order to support older computers. Unfortunately, that opened it up to vulnerabilities, as those older techniques have become more vulnerable as time has passed and computing power has become cheaper.

In particular, TLS 1.2 has become increasingly vulnerable to so-called "man-in-the-middle" attacks, in which a hacker intercepts packets in mid-communication and sends them on after reading or altering them. It's also open to the POODLE, SLOTH, and DROWN attacks. Many of these problems have arisen in the last two years, increasing the sense of urgency for updating the protocol.

TLS 1.3
Fortunately, help is on the way. Version 1.3 of the TLS protocol, currently in draft form but soon to be finalized, plugs a lot of these holes by jettisoning support for legacy encryption systems. There is backwards compatibility in the sense that connections will fall back to TLS 1.2 if one end isn't capable of using the newer encryptions systems on the 1.3 approved list. However, if, for instance, a man-in-the-middle attack tries to force a fallback to 1.2 in order to snoop on packets, that will be detected and the connection dropped.

There are still servers out there that are using versions of TLS even older than 1.2 — some are still using the original SSL protocol. If your sever is one of those, you should upgrade now, and just leap ahead and upgrade to the draft 1.3 spec.
Click to expand...

eva2000 · Mar 24, 2018

@bassie World celebrates, cyber-snoops cry as TLS 1.3 internet crypto approved

A much-needed update to internet security has finally passed at the Internet Engineering Task Force (IETF), after four years and 28 drafts.

Internet engineers meeting in London, England, approved the updated TLS 1.3 protocol despite a wave of last-minute concerns that it could cause networking nightmares.

TLS 1.3 won unanimous approval (well, one "no objection" amid the yeses), paving the way for its widespread implementation and use in software and products from Oracle's Java to Google's Chrome browser.

The new protocol aims to comprehensively thwart any attempts by the NSA and other eavesdroppers to decrypt intercepted HTTPS connections and other encrypted network packets. TLS 1.3 should also speed up secure communications thanks to its streamlined approach.

The critical nature of the protocol, however, has meant that progress has been slow and, on occasion, controversial. This time last year, Google paused its plan to support the new protocol in Chrome when an IT schools administrator in Maryland reported that a third of the 50,000 Chromebooks he managed bricked themselves after being updating to use the tech.

Most recently, banks and businesses complained that, thanks to the way the new protocol does security, they will be cut off from being able to inspect and analyze TLS 1.3 encrypted traffic flowing through their networks, and so potentially be at greater risk from attack.

Unfortunately, that self-same ability to decrypt secure traffic on your own network can also be potentially used by third parties to grab and decrypt communications.
Click to expand...

Andy · Mar 24, 2018

How will this translate to us centmin users?

eva2000 · Mar 24, 2018

Not much yet as need browser support, Chrome 65 is at TLSv1.3 draft 23 support. OpenSSL 1.1.1 pre2 is at TLSv1.3 draft 23. OpenSSL 1.1.1 pre3 is at TLSv1.3 draft 26 and final TLSv1.3 is at draft 28.

OpenSSL 1.1.1 development schedule /policies/releasestrat.html

The next version of OpenSSL will be 1.1.1. This is currently in development and has a primary focus of implementing TLSv1.3. The RFC for TLSv1.3 has not yet been published by the IETF. OpenSSL 1.1.1 will not have its final release until that has happened.

The draft release timetable for 1.1.1 is as follows. This may be amended at any time as the need arises.

13th February 2018, alpha release 1 (pre1)

27th February 2018, alpha release 2 (pre2)

13th March 2018, beta release 1 (pre3)

OpenSSL_1_1_1-stable created (feature freeze)

master becomes basis for 1.1.2 or 1.2.0 (TBD)

27th March 2018, beta release 2 (pre4)

10th April 2018, beta release 3 (pre5)

24th April 2018, beta release 4 (pre6)

1st May 2018, release readiness check (new release cycles added if required, first possible final release date: 8th May 2018)

Click to expand...

So you need for OpenSSL 1.1.1 final in May 8th 2018 and see if that is TLSv1.3 draft 28. Then need to see when web browsers update to support TLSv1.3 draft 28.

Demo of Centmin Mod Nginx 1.13.10 + OpenSSL 1.1.1 pre2 with TLSv1.3 draft 23 supported by SSL labs and Chrome 65 and Firefox 59 OpenSSL - OpenSSL 1.1.1 pre release 3 (beta) released

SSL Server Test: http2.centminmod.com (Powered by Qualys SSL Labs)

buik · Mar 24, 2018

despite a wave of last-minute concerns that it could cause networking nightmares.
Click to expand...

I'm balloting NoObj instead of Yes only because I don't think I have enough
background/expertise in the topic.
Click to expand...

...............could cause networking nightmares.
Chanceless.
And you do not think that until after 4 years as .ietf specialist?
And than intended standard, at that time version 23. a few days before the deadline Heeelp!

eva2000 · Mar 25, 2018

bassie said: ↑

...............could cause networking nightmares.
Chanceless.
And you do not think that until after 4 years as .ietf specialist?
And than intended standard, at that time version 23. a few days before the deadline Heeelp!
Click to expand...

Yeah the full range of implications TLSv1.3 is still an unknown long term even if you're a specialist. The fact that not all web browsers have enabled TLSv1.3 also makes it hard to check. But I guess everyone just wants/wishes to make TLSv1.3 to work long term (ok not everyone i.e. financial sector etc).

Log in / Register

Forums

Welcome to Centmin Mod Community

OpenSSL Using TLS1.3 With OpenSSL 1.1.1

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Andy Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Welcome to Centmin Mod Community

OpenSSL Using TLS1.3 With OpenSSL 1.1.1

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Andy Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

.