IETF Approves TLS 1.3 As Internet Standard (bleepingcomputer.com)
An anonymous reader writes: The Internet Engineering Task Force (IETF), the organization that approves proposed Internet standards and protocols, has formally approved TLS 1.3 as the next major version of the Transport Layer Security (TLS) protocol. The decision comes after four years of discussions and 28 protocol drafts, with the 28th being selected as the final version. TLS 1.3 is now expected to become the standard method in which a client and server establish an encrypted communications channel across the Internet -- aka HTTPS connections.
The protocol has several advantages over its previous version -- TLS 1.2. The biggest feature is that TLS 1.3 ditches older encryption and hashing algorithms (such as MD5 and SHA-224) for newer and harder to crack alternatives (such as ChaCha20, Poly1305, Ed25519, x25519, and x448). Second, TLS 1.3 is also much faster at negotiating the initial handshake between the client and the server, reducing the connection latency that many companies cited when justifying not supporting HTTPS over HTTP.
Browsers like Chrome, Edge, Firefox, and Pale Moon have already rolled out support for earlier versions of the TLS 1.3 draft, and are now expected to update this support to the official standard.
The protocol has several advantages over its previous version -- TLS 1.2. The biggest feature is that TLS 1.3 ditches older encryption and hashing algorithms (such as MD5 and SHA-224) for newer and harder to crack alternatives (such as ChaCha20, Poly1305, Ed25519, x25519, and x448). Second, TLS 1.3 is also much faster at negotiating the initial handshake between the client and the server, reducing the connection latency that many companies cited when justifying not supporting HTTPS over HTTP.
Browsers like Chrome, Edge, Firefox, and Pale Moon have already rolled out support for earlier versions of the TLS 1.3 draft, and are now expected to update this support to the official standard.
I'm pretty sure this means the efforts to make PFS optional failed:
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
For people to stop spying on us!
Let the routers and switches do as they intend, no hacks or tricks to tee off data. If the data needs to go to server X then it should go to server X.
I know that is probably the dumbest thing you heard all day. But I wish they would find a way to make encryption secure and much more cheaper (Certificates are still a killer, in terms of ease of installing, and price you often need to pay for them, for the amount of actual validation they give you for it)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
It makes MITM attacks almost impossible. GG corporate proxy decryption.
"The biggest feature is that TLS 1.3 ditches older encryption and hashing algorithms (such as MD5 and SHA-224) for newer and harder to crack alternatives"
Adding support for bigger and better algorithms and defaulting to them if available is a feature, dropping support is a nightmare. It's challenging enough communicating with things like embedded web servers on old ilo interfaces and the like because they did this with TLS 1.3. It should be strongly advised to update to the latest and greatest but it shouldn't be forced because it isn't always possible.
security.tls.version.fallback-limit 4
security.tls.version.max 4
I'd expect someone reporting on IETF standards to know that "Internet Standard" is a different maturity level that "Proposed Standard". I get that "proposed standard" sounds less definitive for someone not used with the lingo, but surely one could have come with a different expression.
Download the Firefox source code and modify it any way you please.
If you have so many web servers that it takes you two weeks to do this, you should spend the two weeks looking into infrastructure automation like Chef or Ansible.
This config change should take 5 minutes, not two weeks.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
With 'packet sniffing' via hooks on the corporate desktops just before the traffic is encrypted/after it is decrypted?
Seems like a lot simpler solution overall, doubly so if you have sufficient bandwidth to send them side by side over the same link, or disable the internet accessable link if the oob link isn't also connected.
But maybe that would require too much technical knowledge and pressuring Intel to open up/include the feature for corporate environments.
He is probably on Windows and infosec will not allow remote powershell----or GASP! Ansible. I hear it is free and open source (insecure).
I object to power without constructive purpose. --Spock
Comment removed based on user account deletion
Give me something that doesn't leak memory, drain the CPU of its blood and has a decent footprint.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And that's pretty much the thought process that drove my design. An uber-dumb packet forwarder can't be hacked and has the lowest possible latency. You can plug an ultra-dumb firewall in front and have a router module that sits sideways on that figures out how packets are to be forwarded. By being sideways, it isn't directly addressed by anything. If it falls over, oh well, it takes out nothing and delays nothing as it reboots. One module, one function, independent of all other modules. Everything is nice, everything is simple, I can add new modules as I think of new things and not a single one of those new modules will add complexity to anything that's there.
The design uses Linux where Linux is appropriate, SEL4 where Linux is too complex. I considered using BareMetal OS, because I don't need levels of reliability in anything I just want minimum latency, but decided learning one new API at my advanced age was enough.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"Generally speaking though, given the security flaws in the previous standards it really is time to force the upgrade."
How exactly do you propose to do that? An upgrade has been forced with every "mode" you just listed and yet magically no upgrades have occurred. After all, there is a reason you know you have the option to adjust and select those modes manually and it isn't because everything magically updates to the latest and greatest TLS.
Funny, we are switching all our corporate support to Firefox. Mostly because other browsers don't support the older systems we use.
You can use several DDNS providers with letsencrypt
And there are several that you can't use because the provider hasn't completed the process to add itself to the Public Suffix List. If a DDNS provider is not on the PSL, whether by the provider's ignorance of the PSL, by the provider's choice to remain off the PSL, or by the PSL's own backlog, then all users of that provider put together are limited to 20 certificates per week, and other users are likely to have already obtained those certificates before you.
Here's directions for the one I use, duckdns.
I see that Duck DNS is on the PSL. Do you project that Duck DNS will remain in operation for the foreseeable future?
Another problem is DDNS providers that go behind a paywall. Dyn started charging for all services once it became popular, making it no better than registering a domain.