Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Monday March 26 2018, @11:07AM   Printer-friendly
from the Certificate-verification-failed dept.

The web will soon be a little safer with the approval of this new security standard

TLS 1.3 makes a few prominent changes that should keep you safe.

  • The "handshake" between client and server has been streamlined and encryption initiated earlier to minimize the amount of data transmitted in the clear.
  • "Forward secrecy," meaning hackers can't skim decryption keys from one exchange and use it to decrypt others later.
  • "Legacy" encryption algorithms have been removed as options, as these could occasionally be forced into use and their shortcomings leveraged to break the cipher on messages.
  • A new "0-RTT," or zero round-trip time, mode in which the server and client that have established some preliminaries before can get right to sending data without introducing themselves to each other again.

The whole standard is 155 pages long, and really only other engineers will want to dig in. But it's available here if you'd like to peruse it or go into detail on one of the new features.

Also at The Register.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2, Interesting) by Scrutinizer on Monday March 26 2018, @11:34AM (14 children)

    by Scrutinizer (6534) on Monday March 26 2018, @11:34AM (#658370)

    As long as it still relies upon a busted system of compromised Certificate Authorities, it's all just (dangerous) security theater.

    youbroketheinternet.org [youbroketheinternet.org] for those "doers" with some spare time on your hands...

    • (Score: 2) by takyon on Monday March 26 2018, @11:39AM (1 child)

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Monday March 26 2018, @11:39AM (#658371) Journal

      https://letsencrypt.org/docs/faq/ [letsencrypt.org]

      Let’s Encrypt is a global Certificate Authority (CA). We let people and organizations around the world obtain, renew, and manage SSL/TLS certificates. Our certificates can be used by websites to enable secure HTTPS connections.

      Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.

      [...] We do not charge a fee for our certificates. Let’s Encrypt is a nonprofit, our mission is to create a more secure and privacy-respecting Web by promoting the widespread adoption of HTTPS. Our services are free and easy to use so that every website can deploy HTTPS.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 2) by Wootery on Tuesday March 27 2018, @01:37PM

        by Wootery (2341) on Tuesday March 27 2018, @01:37PM (#658957)

        How is it relevant to remind everyone of the existence of Let's Encrypt?

    • (Score: 2, Insightful) by Anonymous Coward on Monday March 26 2018, @12:20PM (3 children)

      by Anonymous Coward on Monday March 26 2018, @12:20PM (#658382)
      You whine about this, but what would you propose as an alternative? We need a way to not only encrypt communications but also to give strong authentication for preventing man in the middle attacks. There's the web of trust model, but what is that but just pushing the job of the certification authorities onto the user? It would degenerate into the equivalent of those infamous UAC dialogue boxes of Windows Vista.
      • (Score: 0) by Anonymous Coward on Monday March 26 2018, @03:18PM (1 child)

        by Anonymous Coward on Monday March 26 2018, @03:18PM (#658471)

        What is necessary, is lies and deception built into protocols. Undecidability and steganography. Protocols that have no origin and destination address. Distributed state machine systems. Parasitism. Look at botnets, bitcoin, DHT...

        Things like encryption imo, put a minimum currency amount on resources you must spend to break a key, favoring big and wealthy faggots.

        Also, encryption itself introduces an attack surface that nobody is qualified enough to inspect.

        Ofc, encryption is probably necessary, but in the current state of the things, encryption is worthless against the larger/competent adversaries?

        • (Score: 0) by Anonymous Coward on Monday March 26 2018, @10:39PM

          by Anonymous Coward on Monday March 26 2018, @10:39PM (#658683)

          It doesn't look like encryption is really worthless even against the larger/competent adversaries though. Why the hell do you think the NSA, which probably counts as the biggest and baddest kid on the block, is working so hard to break protocols and implementations instead (Project Bullrun), and why are the FBI and their ilk attempting to force people to use escrowed encryption? It looks more like that the mathematics of modern encryption is unassailable even by them, so they are looking for weaknesses in the protocols that use them as building blocks, and attempting to legislate their own back doors into the systems that use them.

          The "minimum currency amount" as you put it, to break even a 128-bit key by brute force is actually quite high. If you could compute at the Landauer limit, you would need at least (kT ln 2)2128, where k is Boltzmann's constant, and T is the temperature in kelvins, or about 265 terawatt-hours of energy at 293 K. To put that number into perspective, the average per-capita energy expenditure per person per year in the United States is 13,000 kWh, so 265 TWh (about a quadrillion BTUs) is something like the power consumption of 20 million Americans. That's more than the populations of New York, Los Angeles, Chicago, Houston, and Phoenix combined, and it would still take a year to break such a key. If the NSA's facility in Utah was busy breaking such a key, that much energy consumption and the power plants needed to generate it would be really noticeable, being approximately a tenth of the entire electrical generating capacity of the rest of the United States.

          When you do the same calculations for 256 bit keys, you get values in the range of 1054 joules, which is a literally cosmic-scale amount of energy, far beyond even supernovae (1044 joules), more in the range of energies associated with the supermassive black holes in the centres of quasars. It's about one-thousandth of the total visible mass-energy of the entire Milky Way (1058 joules).

          No, the only "rich and wealthy faggots" who could conceivably break a 256-bit key without exploiting some back door or other systemic weakness in the implementation would be galactic civilisations far more advanced than our own, which has computers that are, as Bruce Schneier puts it: "built from something other than matter and occupy something other than space." Which is why the NSA and the FBI are instead resorting to side-channels, back doors, and other underhanded techniques to get past encryption. I wouldn't put it past them or their agents to have tainted TLS 1.3 with some subtle vulnerability.

      • (Score: 0) by Anonymous Coward on Monday March 26 2018, @08:25PM

        by Anonymous Coward on Monday March 26 2018, @08:25PM (#658634)

        Perspectives had an alternative (which ran along side the CA system). It goes like this:

        * You visit site, they give you a certificate (potentially self-signed).
        * You ask the notaries (similar to CAs, but you get to choose who you trust rather than the site getting to choose).
        * The notaries send you what they have for the cert of that site (either cached or they can fetch it when asked).
        * Once enough notaries have reported back, you check that enough of them (you set threshold) agree with the cert you have gotten.
        * If so, you trust the cert (self signed or not) because either it is valid, or the entire trust network is compromised.

        The reason this system works, is that to compromise a site, you must issue your compromised cert to the entire internet (not just your target), this means that the original site owner can notice.

        The reason it doesn't work, is that the notaries have no way to get paid for their services.

    • (Score: 4, Insightful) by Wootery on Monday March 26 2018, @01:59PM (2 children)

      by Wootery (2341) on Monday March 26 2018, @01:59PM (#658420)

      That's... a bad website. Surprisingly bad, considering they seem be working with serious people.

      There's a lot of rambling about their ideology, but what are they actually looking to do? Build a competitor to IPv6 that does better with crypto and privacy? Or just improve the way things are done at the application level? Does this stuff work over the top of existing technologies, or is it clean-slate-only? Just how much of our existing networking technology are they planning on throwing out? Just the CAs? IP? The web? Or do they just want to replace proprietary software by FOSS? What have they really already achieved?

      Their 'project map' gives me the impression they lack any focus and want to attack all levels at once - and not just with technology, but with wider activism too.

      As a techie, that website is nothing but frustrating. If I weren't a techie, they'd have completely failed to get my interest.

      • (Score: 0) by Anonymous Coward on Monday March 26 2018, @07:46PM

        by Anonymous Coward on Monday March 26 2018, @07:46PM (#658614)

        i'm a pretty staunch GNU, but i have to agree. Will the New Internet burn my eyes out with fixed size fonts like it's 1998? give me a break!

      • (Score: 0) by Anonymous Coward on Monday March 26 2018, @09:59PM

        by Anonymous Coward on Monday March 26 2018, @09:59PM (#658675)

        Spot the total noob who clearly can’t use google or Wikipedia.

        Shut up and stop embarrassing yourself.

    • (Score: 2) by DannyB on Monday March 26 2018, @05:06PM (3 children)

      by DannyB (5839) Subscriber Badge on Monday March 26 2018, @05:06PM (#658524) Journal

      You can use HPKP [wikipedia.org] (not to be confused with HSTS [wikipedia.org]) in order to prevent Honest Achmed's Certificate Authority and Shoe Shine of Tehran Iran from issuing a cert for your domain. They won't have YOUR private key, and all browsers that have previously visited your site will be "locked" to your corresponding public key.

      Careful. Deploying HSTS and especially HPKP requires care and planning. You don't want to "brick" all your customer's web browsers from ever being able to connect to your website ever again when it comes time to renew your domain certificate.

      An organization that is not organizationally mature enough to renew their domain name on time, or their certificate on time, is definitely not ready to get anywhere near HPKP.

      Google can do one better for itself. The Chrome browser can know, for example, that Google doesn't buy its certificates from "Honest Achmed's". But this approach doesn't scale, and is not available to everyone else, unless you make web browsers.

      --
      The lower I set my standards the more accomplishments I have.
      • (Score: 1) by fustakrakich on Monday March 26 2018, @05:23PM (2 children)

        by fustakrakich (6150) on Monday March 26 2018, @05:23PM (#658538) Journal

        all browsers that have previously visited your site will be "locked" to your corresponding public key.

        Are these cookies oatmeal, or chocolate chip?

        --
        La politica e i criminali sono la stessa cosa..
        • (Score: 2) by DannyB on Monday March 26 2018, @05:53PM (1 child)

          by DannyB (5839) Subscriber Badge on Monday March 26 2018, @05:53PM (#658565) Journal

          Yeah, I think I read recently about a way to register 32 domains, each with an HPKP and then being able to use these as a 32-bit super cookie identifier. I would have to search for it, or re-think through the process in order to describe the details. IIRC, Apple was going to prevent this under certain circumstances when it looked like HPKP was used as a super cookie.

          --
          The lower I set my standards the more accomplishments I have.
          • (Score: 0) by Anonymous Coward on Monday March 26 2018, @09:09PM

            by Anonymous Coward on Monday March 26 2018, @09:09PM (#658665)

            Both HSTS and HPKP involve the clients saving information that is sent to them by a server (roughly: "have I visited domain X before?"). By design, browsers leak the state of these caches for those domains on subsequent connections.

            Since browsers can be directed to access essentially arbitrary domains by a web server (e.g., by sending a document full of HTTP image references), the server can direct different clients to access a collection of different domains.

            On a subsequent connection, the server can observe which domains were previously cached -- in HSTS, this can be done by directing the client to access a resource over HTTP -- if the domain is in cache, the client will not connect over HTTP but use HTTPS instead.

            With HPKP the server can change public keys and the client will likewise react differently depending on whether or not a key was previously pinned.

            If these features are enabled in a client, a server can craft documents with references to particular domains and use this information to associate that client to an earlier connection from the same client with high reliability. As far as I know all modern browsers wipe the HSTS and HPKP caches on exit if you enable private browsing mode (or if they don't they really should), which seriously limits the usefulness of these features.

    • (Score: 2) by Bot on Monday March 26 2018, @08:17PM

      by Bot (3902) on Monday March 26 2018, @08:17PM (#658629) Journal

      I would consider contributing to gnunet plus some sneakernettable protocol like ipfs. That is, start from the assumption that you wake up one day and 9_8qyn/)(N/RI"E NO CARRIER

      --
      Account abandoned.
  • (Score: 2) by VLM on Monday March 26 2018, @12:08PM (1 child)

    by VLM (445) on Monday March 26 2018, @12:08PM (#658376)

    Is 0-rtt still open to replay attacks or did they fix that? Something mumble appendix E.5 mumble.

    I'm curious if what I heard is 1) true and 2) for a previous revision

    • (Score: 2) by takyon on Monday March 26 2018, @12:50PM

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Monday March 26 2018, @12:50PM (#658398) Journal

      Reg article says:

      Another very important advantage to TLS 1.3 – but also one that some security experts are concerned about – is called "0-RTT Resumption" which effectively allows the client and server to remember if they have spoken before, and so forego all the checks, using previous keys to start talking immediately.

      That will make connections much faster but the concern of course is that someone malicious could get hold of the "0-RTT Resumption" information and pose as one of the parties. Although internet engineers are less concerned about this security risk – which would require getting access to a machine – than the TLS 1.2 system that allowed people to hijack and listen into a conversation.

      https://www.infosecurity-magazine.com/news/tls-protocol-13-approved/ [infosecurity-magazine.com]

      Specifically, the document stated: “This data is not a forward secret, as it is encrypted solely under keys derived using the offered PSK.

      “There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is provided via the server's Random value, but 0-RTT data does not depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol.”

      The document continued to say that 0-RTT data cannot be duplicated within a connection (i.e. the server will not process the same data twice for the same connection) and an attacker will not be able to make 0-RTT data appear to be 1-RTT data, because it is protected with different keys.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 2) by Bot on Monday March 26 2018, @12:47PM (2 children)

    by Bot (3902) on Monday March 26 2018, @12:47PM (#658394) Journal

    aka client certificates, aka the thing that you could theoretically obtain out of band to connect securely to a given site without needing a CA, are they still feasible? I know, it requires browser support other than protocol support.

    --
    Account abandoned.
    • (Score: 0) by Anonymous Coward on Monday March 26 2018, @02:36PM (1 child)

      by Anonymous Coward on Monday March 26 2018, @02:36PM (#658444)

      Client certificates are about authenticating the client to the server. They could, in priciple, replace password dialogs on websites. They don't replace CAs.

      Privacy concerns with client certificates together with very poor browser support limits adoption on web services.

      • (Score: 2) by isostatic on Monday March 26 2018, @08:01PM

        by isostatic (365) on Monday March 26 2018, @08:01PM (#658626) Journal

        We use client certs all the time, MDM deploys them to devices (phones, laptops etc) every couple of months. On the server side install an internal .deb and include a file in your apache/nginx config, works fine on firefox and chrome (linux and mac) and safari (mac and osx) and curl, powers the F5 vpn too.

        What's not to like?

  • (Score: 0) by Anonymous Coward on Monday March 26 2018, @02:31PM

    by Anonymous Coward on Monday March 26 2018, @02:31PM (#658439)

    "Forward secrecy," meaning hackers can't skim decryption keys from one exchange and use it to decrypt others later.

    Er, that's not what forward secrecy is. If the attacker obtains secret keys from key exchange then they can hijack future traffic as a man-in-the-middle. Forward secrecy is about protecting past traffic that was recorded (in encrypted form) before the attacker obtains any secrets.

    In TLS and most other protocols with forward secrecy, this works by using ephemeral per-session keys that cannot be recovered (by anyone) after they are deleted.

    This is not actually new in TLS 1.3, but is related to the third bullet. What's actually happened is that all modes without forward secrecy have been removed. But this doesn't mean very much because everyone is going to continue to support all the old versions for the forseeable future.

  • (Score: 4, Insightful) by bzipitidoo on Monday March 26 2018, @02:59PM (5 children)

    by bzipitidoo (4388) on Monday March 26 2018, @02:59PM (#658457) Journal

    Hey, IETF, what's with the continued use of 80 columns of text in a fixed width font? Is there source code in there? No? There are a few tables and diagrams in classic ASCII, but you know, we do have markup languages now.

    Does that format make people take the standard more seriously? Maybe it drives away the less technically inclined? Are you trying to show off your deep, decades long technical experience, and not how antiquated you are?

    • (Score: 2) by MichaelDavidCrawford on Monday March 26 2018, @03:21PM

      by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Monday March 26 2018, @03:21PM (#658473) Homepage Journal

      The keypunch machine I used in school didn't have lower case.

      It's gotta be rough, hand-transcribing the EMACS source code onto Hollerith cards then building it for a DEC-System 10.

      --
      Yes I Have No Bananas. [gofundme.com]
    • (Score: 2) by DannyB on Monday March 26 2018, @05:17PM (1 child)

      by DannyB (5839) Subscriber Badge on Monday March 26 2018, @05:17PM (#658531) Journal

      There are rich text formats. I know in ye olde days of yore the only rich text formats were proprietary. (eg, word processors, MacWrite, LisaWrite)

      But now there are open and standard formats. And best of all, you can expect them to be around for a very long time. For example, just plain ol' Html. That would give you basic things like headings, italics, bold, and preformatted monospace blocks, and tables, without even using anything more advanced than what was in 1999.

      And even if some day, Html is no longer commonly understood -- yet somehow your documents are still relevant, Html is easy to read with a plain text editor. It would be easy to strip the tags out and be back to plain text. Or to process the markup tags into whatever is in vogue come the year 9997.

      --
      The lower I set my standards the more accomplishments I have.
      • (Score: 1) by fustakrakich on Monday March 26 2018, @05:35PM

        by fustakrakich (6150) on Monday March 26 2018, @05:35PM (#658547) Journal

        anything more advanced than what was in 1999

        More like 1987 [archive.org]?

        --
        La politica e i criminali sono la stessa cosa..
    • (Score: 2) by termigator on Monday March 26 2018, @06:04PM

      by termigator (4271) on Monday March 26 2018, @06:04PM (#658572)

      Not sure why you are complaining. In the link provided in TFS, there are additional links to the XML and HTML versions of the document, which give a more stylistic rendering.

    • (Score: 4, Funny) by Bot on Monday March 26 2018, @08:30PM

      by Bot (3902) on Monday March 26 2018, @08:30PM (#658638) Journal

      History of 80 column text.
      In the seventies: could you fit more chars in there? I CAN'T WASTE 80 MEMORY LOCATIONS ON EVERY LINE PAL
      In the first eighties: wow you got an 80 column mode? YEP I LIKE BLURRING EVERYTHING IN THE TV SCREEN
      In the Nineties: i resize the window and it stays 80 column. why? NO IDEA PAL, WINDOWS BUG PROBABLY
      In the Zeroes: look at your puny 80 char window, while i am gaming on dual monitors! YES ACTUALLY I JUST PENETRATED YOUR SYSTEM
      Now: pal, that 80 columns do not fit! ROTATE YOUR FUCKING SMARTPHONE MORON

      --
      Account abandoned.
  • (Score: 2, Interesting) by fustakrakich on Monday March 26 2018, @05:18PM (1 child)

    by fustakrakich (6150) on Monday March 26 2018, @05:18PM (#658532) Journal

    Hell, there's your problem right there. There can be no secure way to communicate that way. This certificate thing is snake oil. What works on the LAN should stay on LAN. On the WAN the whole concept has to go away and be replaced with peer to peer. We just need a way to keep the lines open to everybody without a centralized service provider.

    --
    La politica e i criminali sono la stessa cosa..
    • (Score: 0) by Anonymous Coward on Monday March 26 2018, @07:56PM

      by Anonymous Coward on Monday March 26 2018, @07:56PM (#658621)

      i agree. we need decentralized/p2p and anon networking platforms and apps. take away the controllers' control vector before they completely finish us off.

(1)