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

    --
    To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (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.

      --
      To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
      • (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.