Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on from the next-up dept.

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.

84 comments

  1. PFS made it by bill_mcgonigle · · Score: 5, Informative

    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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:PFS made it by mellon · · Score: 2

      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.

  2. A better alternative. by jellomizer · · Score: 1

    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.
    1. Re:A better alternative. by Alain+Williams · · Score: 4, Interesting

      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 if you want free certificates.

    2. Re:A better alternative. by jd · · Score: 1

      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.

      --
      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)
    3. Re:A better alternative. by tepples · · Score: 1

      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.

    4. Re:A better alternative. by skids · · Score: 1

      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.

      --
      Someone had to do it.
    5. Re:A better alternative. by thegarbz · · Score: 1

      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 validation: This is most confusing to me. What are you complaining about here? The validation they provide is perfect: You know the machine you're talking to is the one you're trying to talk to without someone listening in. This is easy and free to achieve. Want to validate the organisation? Get an EV certificate.

    6. Re:A better alternative. by pnutjam · · Score: 1

      You can use several DDNS providers with letsencrypt. Here's directions for the one I use, duckdns.

      https://www.reddit.com/r/letse...

      --
      Cheap storage VM.
    7. Re:A better alternative. by tepples · · Score: 1

      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, 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. Even if Chrome does, your favorite media playing app might not.

      Third, friends or family bringing their own devices to your home in order to view the videos stored on your NAS or print to your printer might not be technical enough to complete the provisioning process on their own.

    8. Re:A better alternative. by ckaminski · · Score: 1

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

      3 ethernet ports and enough CPU to handle everything most home users need.

    9. Re:A better alternative. by skids · · Score: 1

      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.

      --
      Someone had to do it.
    10. Re:A better alternative. by tepples · · Score: 1

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

    11. Re: A better alternative. by Anonymous Coward · · Score: 0

      What have the United States got to do with it?

    12. Re: A better alternative. by tepples · · Score: 1

      I live in the United States, and Slashdot is headquartered in the United States.

  3. Also by geek · · Score: 2

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

    1. Re:Also by Anonymous Coward · · Score: 0


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

      How? Corporate proxies operate by installing self-signed CA certificate inside the browser. Essentially they trick the browser into accepting the certificate generated by the proxy server. Is there some alternate way TLS 1.3 does certificate authentication that a corporate proxy can't fake?

    2. Re:Also by Actually,+I+do+RTFA · · Score: 1

      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.

      --
      Your ad here. Ask me how!
    3. Re:Also by Anonymous Coward · · Score: 0

      What it breaks is the selective MITM that a lot of corporate proxies use. By inspecting the certificate negotiation in 1.2, the proxies could decide whether or not to step in and hijack the actual encryption during the negotiation phase or leave it alone. Corporate proxies used that to set policies like "leave my employee's banking and healthcare traffic alone, inspect everything else". That's impossible with TLS 1.3. You have to either break all or it, or none of it.

    4. Re:Also by ageoffri · · Score: 1
      Huh? This makes absolutely zero sense. The selection of which traffic is intercepted is based on the destination. TLS1.3 doesn't change that TCP has to have a destination address in the packet.

      I'd love for someone to explain if I'm missing something.

      --
      -- Slashdot, making the Left look conservative since 1997.
    5. Re:Also by Anonymous Coward · · Score: 0

      Re-encrypting proxies were depending on SNI (Server Name Indication) to make the decision. They can't do that in TLS 1.3 for various reasons.

    6. Re:Also by Anonymous Coward · · Score: 0

      Re-encrypting proxies were depending on SNI (Server Name Indication) to make the decision. They can't do that in TLS 1.3 for various reasons.

      Yes they can.

    7. Re:Also by Actually,+I+do+RTFA · · Score: 1

      Corporate proxies used that to set policies like "leave my employee's banking and healthcare traffic alone, inspect everything else".

      That sounds like a perfectly reasonable corporate policy. You're not worried about data exfiltrating via the health or banking sites. And employees expect some privacy there (certainly with a corporate health plan, there needs to be firewalls in place). So why wouldn't you intercept all but a few sites?

      --
      Your ad here. Ask me how!
    8. Re:Also by Anonymous Coward · · Score: 0

      Only if they force a protocol downgrade to TLS 1.2 or earlier. Although SNI still exists in TLS 1.3 it's already encrypted in the ClientHello packet using the client's DH key.

    9. Re:Also by Anonymous Coward · · Score: 0

      Only if they force a protocol downgrade to TLS 1.2 or earlier. Although SNI still exists in TLS 1.3 it's already encrypted in the ClientHello packet using the client's DH key.

      Your misinformed. SNI is still cleartext.

    10. Re:Also by Anonymous Coward · · Score: 0

      I'm having difficult finding out. There is a lot of discussion and ideas around encrypted SNI in TLS 1.3, but I can't find if any made the standard. The primary target was to protect against passive snooping, which is easy enough to do by sending the SNI after DHKE, but before the cert.

    11. Re: Also by Anonymous Coward · · Score: 0

      Why would you intercept sites in the first place?

  4. Not a feature.... by shaitand · · Score: 3, Insightful

    "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.

    1. Re:Not a feature.... by Aaden42 · · Score: 1

      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.

    2. Re: Not a feature.... by ERJ · · Score: 3, Informative

      The fallback would happen at the protocol level if you need older crypto standards (I.e. TLS 1.3 fallback to TLS 1.2).

    3. Re:Not a feature.... by Alain+Williams · · Score: 1

      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.

    4. Re:Not a feature.... by vux984 · · Score: 2

      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.

    5. Re:Not a feature.... by Anonymous Coward · · Score: 1

      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 TLS1.2.

      If you have old devices (printers, switches, routers, whatever) that only use TLS1.0 with weak algorithms (and my office still has some devices in that category), nothing in TLS1.3 says a browser can't use TLS1.0.

      Much like Obama's statement "if you like your healthcare plan you can keep it...", but in this case it isn't a lie.

    6. Re:Not a feature.... by MachineShedFred · · Score: 2

      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.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    7. Re:Not a feature.... by Bert64 · · Score: 1

      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.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    8. Re:Not a feature.... by grimthaw · · Score: 1

      "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.

    9. Re:Not a feature.... by jonwil · · Score: 1

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

    10. Re:Not a feature.... by Mark+of+the+North · · Score: 1

      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.

    11. Re:Not a feature.... by Strider- · · Score: 1

      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 crypto.

      And before anyone gets panties in a twist, the devices I need to control are on a private VLAN that is not accessible to either my user VLANs or the public internet. But the cost of replacing them is far and beyond what our small non-profit can afford. And besides, otherwise they work perfectly fine, do their job, and are stupidly stable.

      --
      ...si hoc legere nimium eruditionis habes...
    12. Re:Not a feature.... by vux984 · · Score: 1

      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 a VM that acts as a bridge between the TCP/IP and IPX/SPX segment. (ie the job files are delivered to the bridge VM in a fileshare, and the VM in turns passed them over to the other equipment. If we were trying to enrich uranium and were worried the US/Israeli would try to sabotage us, then sure, but we're not. Sure the system might get knocked over incidental to a network breach, but it would still be cheaper to repair the breach, and rebuild the system than it would be to purchase new equipment.

    13. Re:Not a feature.... by Anonymous Coward · · Score: 0

      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.

      This is the difference between a Security Officer, or Scanner and someone that actually works in IT. Recognizing that an Apache server being used for mod_proxy or mod_jk probably isn't vulnerable to an attack on mod_lua and responding appropriately. Yes, it'd be better to upgrade to fix the vulnerability, but if you aren't impacted, it's a waste of time getting the ticket opened, installed to test, QA signoff done, approvals for production change, another prod signoff, and then a couple of days sweating hoping there wasn't some edge case missed.

       

    14. Re:Not a feature.... by shaitand · · Score: 1

      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 500 company.

      By the time the systems you are forcing to "not have garbage default settings" become an issue, the "not garbage" settings will be old and garbage settings already. They won't use the crappy old settings out of the box on mainstream servers and browsers regardless and clueless admins don't even know to change anything less alone reduce the security.

    15. Re: Not a feature.... by shaitand · · Score: 1

      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 won't be upgraded until their actual operational function can't be performed. Continuing this poor practice extends this massive risk and probably expands it.

    16. Re:Not a feature.... by shaitand · · Score: 1

      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 self-signed certs in the first place. Yet another ignorant practice. The possibility a MITM attack can happen doesn't mean there is no benefit to encrypting the content on the wire. There is a dramatically higher probability that someone is sniffing the white than has managed to successfully employ a man in the middle attack against an admin. Especially when that admin will have all those self-signed certs cached.

      The enemy is not likely inside your lan as suggested in another one of these sub-threads. Hell the enemy is most likely nowhere except some malware downloaded by an end user. A high profile compromise here and there doesn't change that 99.9999% of "threats" detected are utter bullshit and with proper firewalls, zoning, and minimal lazy security in place the same number of vulnerabilities detected on your platform are practically exploitable on the systems as deployed whether present in the underlying software or not.

    17. Re:Not a feature.... by shaitand · · Score: 1

      "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 thousands of thousands of systems to slowly pick up the ones they get lucky on. Admins following commonly employed admin best practices won't be vulnerable to most attacks even if the software on their hosts is. For instance, an apache vulnerability on a web server sounds critical and will require patching fast... unless of course your web servers don't host any content and are several layers of caching and proxy server behind where someone who doesn't already have root could access.

    18. Re:Not a feature.... by shaitand · · Score: 1

      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 the hardware that doesn't get caught or have to be replaced on the latest PCI audit or that got tossed on the exception list if someone was bright enough to realize that you notate pretty much anything onerous to implement on an exception list and still be PCI compliant.

    19. Re:Not a feature.... by shaitand · · Score: 1

      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 verification with fingerprint which blows a third party issue out of the water. At least it does if it's using a decent cipher.

    20. Re:Not a feature.... by shaitand · · Score: 1

      "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.

    21. Re:Not a feature.... by Anonymous Coward · · Score: 0

      Then your VM bridge is setup as a secure gateway to isolate the DOS machines from other things ffs.

      It's not really that hard

    22. Re:Not a feature.... by jabuzz · · Score: 1

      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.

    23. Re:Not a feature.... by ckaminski · · Score: 1

      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.

    24. Re: Not a feature.... by buchanmilne · · Score: 1

      "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 ciphers for all destinations just to get into the iLO/ILOM/DRAC of a 5-year server (in some cases to upgrade thr firmware to a version with newer cipher support!).

      Of course, it might be wise to allow enterprise desktop admins to set such policies for all users.

      Sadly, it's probably only Microsoft browsers that have such features ...

  5. Not much of an accomplishment by mi · · Score: 0

    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...

    --
    In Soviet Washington the swamp drains you.
    1. Re:Not much of an accomplishment by Anonymous Coward · · Score: 0

      It seems like you don't know what you're talking about.

      I know what I'm talking about and I agree with parent.

      You clearly do not know the 4 main components that make up the suite of algorithms used in TLS, you don't know why each of those four things are important to set correctly and why that is hard, and therefore do not understand why TLSv1.3 making that easy/default is a good thing for everyone

      Every major TLS stack has easy to specify high/medium/low selection filters constantly managed and updated by the stack developers. It's ridiculous to assert a whole new protocol is necessary to solve a simple management problem that has already been solved.

      The real source of complexity is dealing with mixed environments containing old hardware with old cipher suites that will never ever see an update. Adding a new version to TLS does nothing to address this.

      and last but not least clearly have no idea this system is something that will be used by you for basically everything you do in the future online -- from general access to purchasing shit.

      Why is this at all relevant?

      Let me know when anything you do gets even discussed by the IETF.

      Nice (if not misplaced) appeal to authority. The IETF is not much more than a bunch of open mailing lists anyone can post.

  6. enable in firefox about:config by Anonymous Coward · · Score: 1


    security.tls.version.fallback-limit 4
    security.tls.version.max 4

    1. Re:enable in firefox about:config by Anonymous Coward · · Score: 1

      This works. It can be tested at Qualsys SSL Labs

  7. Yay, I get to redo Apache and Nginx configs again! by Anonymous Coward · · Score: 0

    I just spent the last two weeks updating all of my web servers to the latest ciphers. Now I'll get to do it again. Yay!

  8. What kind of standard? by rpetre · · Score: 1

    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.

  9. Internet Explorer won’t support it by Anonymous Coward · · Score: 0

    Therefore corporates and China won’t support it. Plus the billions of fragmented unupdated Android devices too.

  10. Re:Oh Lordy! by jfdavis668 · · Score: 2

    Download the Firefox source code and modify it any way you please.

  11. Fake news by Anonymous Coward · · Score: 0

    BS: "All in all, TLS 1.3 is a serious boost to Internet security"

    Reality: No it isn't even close. It's an incremental improvement with no practical implication WRT Internet security vs accepting some small responsibility in not allowing completely braindead algorithms to be selected in existing systems.

    There are however many klocs harboring potential new vulnerabilities. In unrelated news medium security vulns are dropping for OpenSSL tomorrow.

    BS: "Fourth, TLS 1.3 is also superior to previous TLS versions because it comes with protection against downgrade attacks that prevent an attacker from tricking a server into using an older version of the protocol, susceptible to known vulnerabilities."

    Reality: Version negotiation is not currently broke. The only reason downgrade attacks were possible is the fucking browsers intentionally subverted TLS secure negotiation to make it possible. If you take the time to disable shit algorithms (RSA-MD5 and crew) and don't intentionally subvert the process then version negotiation is safe as far as anyone knows.

    BS: "IETF avoids efforts to insert backdoor. The proposal was laughed off by experts, who pointed out that the backdoor would effectively make TLS 1.3 useless in the first place."

    Reality: Over the top hyperbole completely unmoored from reality. An operator consciously electing not to use forward security if they don't want to is not a backdoor.

    BS: "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."

    Reality: Nothing prevents them from decrypting traffic inside internal networks.

  12. Re:Yay, I get to redo Apache and Nginx configs aga by MachineShedFred · · Score: 1

    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.
  13. The available ciphers depend on client+server... by Anonymous Coward · · Score: 0

    version.

    IE if the server reports it is 1.3 but the client is 1.2, it will renegotiate to the subset of ciphers both support. If the server doesn't mind allowing a client insecure connections it can drop back to the older ciphers, or vice versa (assuming mozilla/google/etc in their infinite stupidity didn't remove those ciphers when selecting sslv3/tls1.0/1.1/1.2 mode manually, if needed.)

    Generally speaking though, given the security flaws in the previous standards it really is time to force the upgrade. It would be better if the OS/App developers were forced to produce a point release for certain devices/platform versions that included just this new transport layer support, but sadly that is unlikely to happen.

  14. Corporate Management Engine? by Anonymous Coward · · Score: 1

    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.

    1. Re:Corporate Management Engine? by 110010001000 · · Score: 1

      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.

    2. Re:Corporate Management Engine? by Anonymous Coward · · Score: 0

      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.

      What does encryption on an internal network even do for security? More cipher policies to manage, keys, certificates, cpu overhead, people overhead, to protect against MITM on a corporate network that fully intends to MITM everything.

      Say I can't trust MAC/IP/DNS resolution on an internal network, then an encrypt everything at the app level policy is supposed to save the day?? Why are we doing this to ourselves...

    3. Re:Corporate Management Engine? by skids · · Score: 1

      Say I can't trust MAC/IP/DNS resolution on an internal network,

      ...fix your network with dhcp snooping, arp protection, ip source guard and DNSSec... but...

      then an encrypt everything at the app level policy is supposed to save the day??

      ...actually that's kind of the point... TLS isn't just encryption it is also server authentication via PKI.

      (Back in WEP-just-got-cracked days some people just ran open wifi networks where the only protocol allowed on the hosts/APs was cert-based IPSec. Workable workaround by the same principle.)

      --
      Someone had to do it.
  15. Re:Yay, I get to redo Apache and Nginx configs aga by datavirtue · · Score: 1

    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
  16. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  17. Re:Oh Lordy! by jd · · Score: 1

    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)
  18. Firefox on the corporate desktop by Anonymous Coward · · Score: 0

    What you described is Firefox!

    In many situations it has a smaller memory footprint than Chrome, and it's memory utilization is about the same.

    The kicker...I no longer use Firefox since it decided to be a Chrome-clone.

    Where Firefox totally looses the corporate desktop is by breaking the ability to connect to older equipment. In some places by ditching older encryption protocols entirely, and in others by requiring hunting down registry keys to restore compatibility. It's a great thing thing to warn when someone tries to connect to a URL using insecure encryption, but it's another to require more than setting a preference in the normal config screen and clicking "Proceed anyway" on a warning screen.

    Now, on top of that, they've broken support for plugins necessary to connect to some not-very-old equipment. This further alienates corporate IT people. End-result...it has no chance of winding up on the desktop.

    1. Re:Firefox on the corporate desktop by jfdavis668 · · Score: 1

      Funny, we are switching all our corporate support to Firefox. Mostly because other browsers don't support the older systems we use.

  19. Do one thing, and do it well by Anonymous Coward · · Score: 0

    The entire breakthrough that led to TCP/IP and the Internet was that it was way cheaper to have a dumb network and intelligent end-points.

    It's the approach I take to build large networks, and unsurprisingly, simpler equipment tends to provide for faster networks, way fewer problems, and cost a whole lot less.

    When I do need network intelligence, I lean-towards industrial grade PC servers as routers. Running Linux or FreeBSD. With such equipment...replacing a failed network interface is fast and cheap, often with no need to order anything. And with Linux, you can do hot-kernel patching for free...and OS support never expires, and if you want, that's free too.

    There ARE use cases when Juniper or Cisco gear are the right choice, mainly because of lower (usually up-front) cost, and in those situations, I use the correct gear for the problem. But in terms of flexibility, and performance per $, it's pretty close to impossible to beat Linux or FreeBSD on server HW.

    Linux benefits vs All-in-one-enterprise-router
    * Support never expires. Check - Free
    * 4 TB of logs? Check - Low cost
    * Hundreds of GB RAM. Check - Low cost
    * Kernel hot-patching without reboots. Check - Free
    * Traffic shaping. Check - Free
    * Most tested and proven IP stack possible. Double Check
    * Low-cost parts you rarely, if ever need. Check
    * Amazing debug tools. Check
    * Multicore multi-GHz CPU. Check
     

    1. Re:Do one thing, and do it well by jd · · Score: 1

      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)
  20. Re:The available ciphers depend on client+server.. by shaitand · · Score: 1

    "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.

  21. TLS is a mess by Anonymous Coward · · Score: 0

    TLS is a too complex mess, and therefore unsafe

  22. Public Suffix List limits LE issuance on DDNS by tepples · · Score: 1

    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.

    1. Re:Public Suffix List limits LE issuance on DDNS by pnutjam · · Score: 1

      I've been using duckdns since September 2015. If it goes away, I'll find another one. It seems stable enough and they have added features and directions in that time, so it's does not appear to be abandoned.
      It also looks like they have met their funding goals and get sufficient monthly income. Although, you should donate if it's important to you.

      --
      Cheap storage VM.
  23. Re:Oh Lordy! by Anonymous Coward · · Score: 0

    Oh yeah, another downmod! Go ahead! Mod this down too, you cunt! The agenda is clear. Facts are horrible stupid things in your book when you are paid to deny and obscure them the best you can. Go fuck yourself! And your little god too!

  24. Diffie-Hellman parameters by Anonymous Coward · · Score: 0

    There is one issue with TLS 1.3 though, despite how nice it is otherwise. TLS 1.3 has deprecated custom DHE groups, making it so all DHE connections are required to use default, pre-created groups, making precomputation attacks possible. Thankfully, ECDHE is still preferred over DHE.

    From Stack Exchange: https://security.stackexchange.com/questions/181820/why-does-tls-1-3-deprecate-custom-dhe-groups