Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
The Internet

IETF Approves TLS 1.3 As Internet Standard (bleepingcomputer.com) 84

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.

This discussion has been archived. No new comments can be posted.

IETF Approves TLS 1.3 As Internet Standard

Comments Filter:
  • PFS made it (Score:5, Informative)

    by bill_mcgonigle ( 4333 ) * on Monday March 26, 2018 @02:59PM (#56329369) Homepage Journal

    I'm pretty sure this means the efforts to make PFS optional failed:

    IETF members voted the protocol unanimously, even after members of the financial sector asked for the introduction of a backdoor in the protocol's structure, so financial institutions could decrypt TLS 1.3 traffic inside internal networks.

    The proposal was laughed off by experts, who pointed out that the backdoor would effectively make TLS 1.3 useless in the first place.

    • by mellon ( 7048 )

      Yeah, there was no consensus to do the PFS weakening proposal. The proponents of this work are now working on an out-of-band signaling mechanism. It was a really crappy situation—the people behind the PFS-weakening have a real problem. They were just taking (IMHO) the wrong approach to addressing it. Hopefully now they will regroup and try to do something less harmful to the Internet.

      • by Anonymous Coward

        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.

        • The problem is that there is valid reasons to be able to decrypt traffic. IDS and performance monitoring are two big reasons. However what will happen is that companies will delay rolling out 1.3, and then using static key provisioning rather than ephemeral keys so they can still do MITM.
  • 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)

    • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Monday March 26, 2018 @03:27PM (#56329527) Homepage

      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)

      Try looking at Let's Encrypt [letsencrypt.org] if you want free certificates.

      • by tepples ( 727027 )

        A certificate from Let's Encrypt or any other CA trusted by well-known web browsers requires a fully qualified domain name. The fee to register a domain imposes a recurring monetary cost on someone who just wants a certificate to use with a router, printer, or NAS device on a home LAN.

        • by skids ( 119237 )

          If it's a home LAN you can make your own CA and add it to your OS trust store. What are you talking about, like 10 client devices to provision? Not a huge deal.

          • by tepples ( 727027 )

            First, the user has to add the CA not only to the operating system's trust store but also the trust store of each web browser, as not all web browsers use the operating system's trust store.

            Second, last I checked, it was harder to provision devices running a smartphone OS than devices running a desktop OS. Adding a certificate on Android is impossible without first setting up a PIN or pattern lock [google.com], and developers of apps made for Android 7 "Nougat" and later have to opt in to use of user-provisioned CAs thr

            • by skids ( 119237 )

              Second, last I checked, it was harder to provision devices running a smartphone OS than devices running a desktop OS. Adding a certificate on Android is impossible without first setting up a PIN or pattern lock [google.com], and developers of apps made for Android 7 "Nougat" and later have to opt in to use of user-provisioned CAs through the network security config [android.com]. Even if Chrome does, your favorite media playing app might not.

              It's your choice to use that software. Why are you surprised it puts you on a path of having to pay for things like public CA certs? That's what that ecosystem was designed to do, to make you pay for things.

              • by tepples ( 727027 )

                What operating system for pocket computers sold in the United States isn't "designed [...] to make you pay for things"?

        • by pnutjam ( 523990 )
          You can use several DDNS providers with letsencrypt. Here's directions for the one I use, duckdns.

          https://www.reddit.com/r/letse... [reddit.com]
    • by jd ( 1658 )

      The chief problem is that everyone wants an all-in-one router, no modules, no mess, that has a single CPU that does absolutely everything and that allows admins to log in from any port. I've built routers that are a lot more secure than that, but I'm not convinced there's a market for them.

      • pfSense on a $120 PC-engines.ch APU.

        3 ethernet ports and enough CPU to handle everything most home users need.
    • 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.

      Errr that couldn't be further from the truth.

      Price: There are several free DV certificates available, and relatively cost effective EV certificates too.

      Ease of installing: Are you talking about obtaining or installing? Because installing is literally putting 2 lines in your config file pointing to the certificates for most servers. Obtaining isn't any more difficult. Even the signing process is nothing more than copying and pasting a string into a terminal and then uploading the result to a website.

      Actual v

  • by geek ( 5680 ) on Monday March 26, 2018 @03:05PM (#56329427)

    It makes MITM attacks almost impossible. GG corporate proxy decryption.

    • How does this prevent me from MITM with self-signed certs that your computer is set to accept via corporate policy?

      Also, what's wrong with MITM in that case? Corporations controlling what their computers can do makes perfect sense to me.

  • Not a feature.... (Score:4, Insightful)

    by shaitand ( 626655 ) on Monday March 26, 2018 @03:09PM (#56329449) Journal
    "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.
    • by Aaden42 ( 198257 )

      Having to support the entirely new version of TLS is the barrier. The ciphers are just an implementation detail.

      If your stack supports TLS1.3, it will support the new algos (cause if it doesn't it doesn't support TLS1.3). Removing the junk ciphers & hashes makes it impossible for garbage default settings or clueless admins to turn on insecure options. Removing the cruft won't prevent adoption of TLS1.3 in any meaningful way.

      • Sounds like the argument made with TLS 1.2... which proved to be incorrect and now thousands of enterprises have crappy old browsers that still allow them to turn on "insecure" old settings for all kinds of old hardware they have to use and administer with embedded or unsupported appliances running old webservers and standards. People don't replace things because the oob interface uses a crappy version old HTTPS to load it's self-signed cert driven interface and there are systems like this in EVERY fortune
        • Seriously, what would it take to get a Rpi Based KVM?

          Open source BMC is one place I figured would get some traction - all options are like $300 minimum per node. I'm lucky, my Supermicro boards come with BMCs, but again, not open.
    • by ERJ ( 600451 ) on Monday March 26, 2018 @03:27PM (#56329523)
      The fallback would happen at the protocol level if you need older crypto standards (I.e. TLS 1.3 fallback to TLS 1.2).
      • No, it won't because everyone is going to start requiring the latest and greatest as part of their compliance policy and you'll force people to enable the lowest common denominator and lose the other benefits of the newer protocol as well. Hell, the fallback probably won't even work.

        Thanks to forced obsolescence in these standards you have thousands of systems running IE 6 with security settings cranked down because it is the only way for people to do their job and interact with older systems that can't or
    • Maybe you should think about retiring these old devices, especially if they are visible from the global Internet. The encryption that they support is no longer fit for purpose and is dangerous -- vulnerable to being cracked by $enemy. Continuing to use them is like continuing to drive a car where it is known that the brakes have failed.

      • by vux984 ( 928602 )

        Maybe you should think about retiring these old devices, especially if they are visible from the global Internet.

        What if they are not visible?

        The encryption that they support is no longer fit for purpose and is dangerous -- vulnerable to being cracked by $enemy.

        God forbid an $enemy inside my lan sees what is about to come out of the laser printer, a few seconds before it literally gets printed out on paper in plain text.

        At the lab we have equipment that still run MSDOS internally. Hundreds of thousands of dollars worth, and they work perfectly fine. I agree we shouldn't put them anywhere publicly facing on the internet. But they accept jobs over the LAN just fine.

        Continuing to use them is like continuing to drive a car where it is known that the brakes have failed.

        It's really not though.

        • "What if they are not visible?"

          Then you're relying on M&M security.

          "What is about to come out of the laser printer, a few seconds before it literally gets printed out on paper in plain text."

          I'd take a guess that what comes out of that printer would be internal documents which may or may not contain financial, PII and other confidential information.

        • What you have to understand is that there is a good chance that an enemy is on your LAN. Not using strong protocols is a very real risk.

          In your own example, what is coming out of a laser printer probably is information that you probably don't want being public.

          Your equipment that runs MSDOS internally has no business being connected to a network at all.

          • by vux984 ( 928602 )

            What you have to understand is that there is a good chance that an enemy is on your LAN. Not using strong protocols is a very real risk.

            In your own example, what is coming out of a laser printer probably is information that you probably don't want being public.

            In my home? It's my kids homework assignments mostly. But sure, you're right to the point that i do occasionally print tax information etc. But what? I'm going to toss a $600 color laser printer that works perfectly because it's web based admin panel isn't up to 2018 best practices? because there's a chance my LAN could be compromised ?

            Your equipment that runs MSDOS internally has no business being connected to a network at all.

            And how are multimegabyte job files going to be moved back and forth? zip'd onto split archives on a bundle of floppy 3.5" disks? Get real. The stuff is IPX/SPX; connected to

          • "What you have to understand is that there is a good chance that an enemy is on your LAN."

            Highly improbable. The enemy might be on the users lan but it's very doubtful they are anywhere useful. In most all cases detection software will find all sorts of threats... somehow magically none of these threats resulted in a compromise before the system was added and that is because these attacks are dumb poorly tested and automated bots that don't work with a damn in practice. They work by hamfisted attacks on tho
      • You are aware this is the situation with about 80% of ILO/IPMI/Lights out, etc interfaces on the management networks of essentially every fortune 500 company, ESPECIALLY the ones selling security solutions (maybe not especially but certainly including).

        There is nobody upgrading a critical system, anywhere, because the ILO management interface can't run the latest cipher suite. There is also nobody upgrading such an interface after racking the thing even if one is available. Further these are all running sel
    • by Anonymous Coward

      Adding support for bigger and better algorithms and defaulting to them if available is a feature, dropping support is a nightmare.

      Given than TLS1.3 was never finalized until now, if you have a device that supports TLS1.3 and will only work with a weak algorithm, your device is a POS and you should throw it away.

      Nothing in TLS1.3 requires that a browser stop supporting TLS1.0, TLS1.1 or TLS1.2.

      Nothing in TLS1.3 requires that a browser stop supporting weaker algorithms when connecting with TLS1.0, TLS1.1 or T

      • by Bert64 ( 520050 )

        The annoying thing is that browsers (especially firefox) are now removing the older ciphers completely, and making it difficult or impossible to turn them back on. There are various old embedded devices we need to connect to which use insecure ciphers and even do stupid things like use small private keys, and there's no way to change that...
        The browsers need to implement configuration options to bring back all the weak ciphers so we can still manage these old legacy devices.

        • by Strider- ( 39683 )

          The browsers need to implement configuration options to bring back all the weak ciphers so we can still manage these old legacy devices.

          My favourite bonehead maneuver is in Chrome. If a site doesn't conform to the latest and greatest SSL/TLS (or whatever it is, I don't care) it's internal password manager refuses to work. This encourages the use of weak passwords as they're something tha tyou can remember. Either that or an external password manager. Either way, it's particularly boneheaded because the internal password manager continues to work with non-encrypted websites. SSL 1.0 w/56bit crypto is still better than plain http with no cryp

        • Yes, there is more to TLS 1.3 than the cipher suite. There is no reason you can make TLS 1.3 able to fall back and support older ciphers and dial down only the degree necessary to negotiate a resolution. In that way, claiming to support TLS 1.3 also means continuing to be able to support those older ciphersets.

          Honestly, even a self-signed cert serves it's purpose if it is has been saved as an exception in the browser of the admin... that point you not only have encryption but personally known identity verif
      • TLS 1.3 needs to continue to include the ciphers so there is something in TLS 1.3 that forces the browsers to continue supporting older (incidently weaker) algorithms. It is the responsibility of TLS 1.x to include backward compatibility for TLS 1.x-1 otherwise it stops becoming practical to support TLS as the standard at all. Previous versions have cost millions of dollars because of this nonsense and resulted in thousands of old systems running IE 6 with poorly chosen settings so they can interact with th
    • There's still many different ciphers and hashes available without the brand new - they are retiring age-old stuff that is on the edge of being broken, as well as ciphers and hashes that have known collisions and attacks.

      If you're still using these 10+ year old ciphers for security, you aren't secure to begin with - your TLS client may as well tell you so outright.

      • "If you're still using these 10+ year old ciphers for security, you aren't secure to begin with - your TLS client may as well tell you so outright."

        Nobody is using 10+ year old ciphers for security... they are stuck with what someone was using for security 10+ years ago. Your TLS client doesn't tell you so outright, it drops support for them or forces you to turn on lower security settings that compromise more than just the cipher.
      • "If you're still using these 10+ year old ciphers for security, you aren't secure to begin with - your TLS client may as well tell you so outright."

        Your TLS client should realise that not all equipment can be tossed just because there is some new standard out or some browser developers decided to deprecate ciphers.

        They should allow users to configure policies for which destinations (IP wildcards or subnets, dns suffixes, the way proxy exclusion lists work) may use old ciphers.

        I hated having to allow old cip

    • by jonwil ( 467024 )

      These embedded web servers presumably dont even support TLS 1.3 so the dropping of the older crypto makes no difference for these devices.

    • by jabuzz ( 182671 )

      That's because there is no easy way to fall back hundreds of devices. Ideally I need a way to say that devices on network X.X.X.X/Y should be allowed to use any crap old TLS and even SSL version because the fricking vendors have stopped doing firmware updates even though the hardware is still under maintenance. However any other network what the hell only known secure protocols allowed.

  • 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

    If removing older options is the biggest new feature, then there is not much to speak of, is there?

    And it took these people how long to come to this important milestone?

    The decision comes after four years of discussions and 28 protocol drafts

    Tar and feathers... Either for those involved, or for those, who described their work for Slashdot...

  • by Anonymous Coward


    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.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...