“how mane features can we add to this..."
Horse?
Corrected before I could even finish drafting the Corrections email.
The ink has dried, so to speak, on TLS 1.3, so it's time for work developing software to implement the standard to begin in earnest. As we reported last week, now that the protocol's received the necessary consensus in the IETF, implementation “will require people to put in some effort to make it all work properly.” Vulture …
This post has been deleted by its author
This post has been deleted by its author
So, how long do you suppose it will take to actually start benefiting users?
My bet is a good few years or so before it becomes "standard" and supported everywhere, I mean look how long websites were still dependant (and in some cases, are still) on IE6 and SSLv3 even after both were long deemed obsolete.
But, the sooner we get started the better!
But I'm hoping RedHat[1] put TLS 1.3 support into RHEL[2] 7 instead of delaying it for RHEL 8. But we'll see!
[1] An Enterprise Linux Vendor
[2] RHEL is an acronym for RedHat Enterprise Linux, it's their primary product.
I'm talking about server side. You can have every browser support it, but if the servers do not then you'll just fall back to TLS 1.2 or lower depending on server.
Some servers were still (and in some cases still do) requiring users to use SSLv3 long after TLSv1.2 was released.
OpenSSL will fully support TLSv1.3 in an upcoming point release, likely within the next couple of weeks (alpha support has been there a while). That accounts for the overwhelming majority of application support. The other major server-side component is JVM support, which is being tracked with JEP8145252. This is still in draft status, but is likely to proceed quickly because as the article discusses, the basic version of TLS1.3 can be implemented entirely using TLS1.2 APIs.
It's quite a graceful change, all told. I'd expect the optional features to follow in later releases across the next six or so months.
"It's quite a graceful change, all told. I'd expect the optional features to follow in later releases across the next six or so months."
That's great, but the big question now is how long until that version of OpenSSL filters down to enterprise grade distributions (who do not just run latest version of OpenSSL)
Hopefully Redhat backport the changes which add TLS 1.3 to RHEL 7, if not I'll have to wait for RHEL 8 :-).
But knowing Redhat they probably will, they added forward secrecy to RHEL 6 later in its life during a point release, so maybe they'll do the same with TLS 1.3 for RHEL 7.
Either way, as soon as it lands it is being configured and set up :-).
My client have literally spent years already trying to move to RHEL6 which should hopefully remain supported by Red Hat for a while longer. They will struggle to quickly move to a later version as the Oracle Weblogic based APIs that their applications currently run on might not move nicely to the latest stack. In any case, the default yum packages for OpenSSL that come with RHEL are woefully outdated, suggestion might be to actually download and compile latest version from source, scary! Here is a link anyway which might help when testing OpenSSL updates -
https://www.linuxhelp.com/how-to-install-and-update-openssl-on-centos-6-centos-7/
"OpenSSL that come with RHEL are woefully outdated, suggestion might be to actually download and compile latest version from source"
Redhat backport security patches and such like to them. They've become tried and tested so to speak.
I prefer to have good clean systems. Manually compiling and installing using "make install" is a dirty process as it means you have binaries outside of your package manager, and often when it comes to removing them some files get left behind.
Naturally there are also third party repos which will provide updated versions of software, but can you trust the person who compiled it?
You can of course run your own repo with your own compiled packages, but you'd have to ensure all dependancies match up and you keep it updated.
Not to mention if a package is overriding a default and one of its dependancies is updated, your replacement package may not work with it or cause conflicts where as a distro package would already be updated for that.
Realistically for a stable server your better off sticking with the packages included by the distro as you can just sign up the announce mailing list and get an email each time a package is updated along with what was included and the security rating etc, thus you only need to determine whether or not it is necessary to apply that update.
That's my method though, I prefer to create less work for myself and ensure the systems are stable and secure for a long term basis. Even more so as I have multiple systems to manage.
No doubt it will flush out a few middle boxes written by code monkeys from a bunch of code they trawlered up from some code repository they barely understood. *
So cautious thumbs up.
*I wonder if this will include the hardware that implements the UK Snoopers Charter, supplied by the BAe subsidiary formerly nown as Dettica, formerly known as Smith Associates.
“Assuming that the middlebox implements TLS 1.2 correctly, then the session goes through … it looks like TLS 1.2, but it's using TLS 1.3.”
Compromising by building in kludges into something from the very start looks like a recipe for disaster. I
What other kludges have they slipped in that haven't been as wildly publicised?
Can't see this ending well.
"The IETF decided that systems like OpenSSL should ship with “middlebox compatibility” enabled by default. In this mode, the TLS 1.3 connection looks like TLS 1.2, Velvindron said."
I would prefer my connections to fail when somebody's arseing about in the middle of my secure connection.
Exactly.
Something a lot of people just don't seem to get.
So doing it this way improves the chances of it being accepted by most companies, as well as home users.
That's important because the truth is the internet is only as secure as its weakest link.