Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.

TLS Security: Past, Present and Future

posted by Fnord666 on Monday July 03 2017, @11:56PM   Printer-friendly
from the reflections dept.

MrPlow writes:

Submitted via IRC for TheMightyBuzzard

Since the early days of the SSL/TLS protocols, the security community has been struggling with various attacks that have made many press headlines.

[...] The Transport Layer Security (TLS) protocol as it stands today has evolved from the Secure Sockets Layer (SSL) protocol from Netscape Communications and the Private Communication Technology (PCT) protocol from Microsoft that were developed in the 1990s, mainly to secure credit card transactions over the Internet.

It soon became clear that a unified standard was required, and an IETF TLS WG was tasked. As a result, TLS 1.0 was specified in 1999, TLS 1.1 in 2006, TLS 1.2 in 2008, and TLS 1.3 will hopefully be released soon. Each protocol version tried to improve its predecessor and mitigated some specific attacks.

As is usually the case in security, there is a "cops and robbers" game going between the designers and developers of the TLS protocol and the people who try to break it (be it from the hacker community or from academia). Unfortunately, this game is open-ended, meaning that it will never end and has no winner.

Not precisely news but it's good to stop, reflect, and look forward now and then.

Source: https://www.helpnetsecurity.com/2017/07/03/tls-security/

Original Submission

 
This discussion has been archived. No new comments can be posted.
TLS Security: Past, Present and Future | Log In/Create an Account | Top | 12 comments | Search Discussion
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 Pino P on Wednesday July 05 2017, @04:32PM (3 children)

    by Pino P (4721) on Wednesday July 05 2017, @04:32PM (#535254) Journal

    All that work spent improving the strongest part of the chain, while doing absolutely nothing about the weakest link - the reliance on Certificate Authorities

    Then what's the alternative to the CA model that doesn't involve physically visiting each partner with whom you wish to communicate?

    Before you say "build a web of trust through key signing parties", that isn't practical for at least two reasons.

    Trust isn't necessarily transitive
    Just because you can vouch for someone's identity doesn't mean you can vouch for that person's ability to vouch for third parties' identities. You haven't seen that person's behavior at key signing parties other than the one you attended.
    International key signing logistics are complicated
    Key signing parties are a great way to make the web of trust dense within a single city. But if a web of trust is to include both you and the person with whom you communicate, there needs to be some way to make this web dense outside of your own city. As you traverse the web of trust to people who live far from your own city, you'll end up needing to rely on signatures from the "jet set". These are introducers who have attended key signing parties in several different countries. But the growing load of security theater associated with travel to or from the United States since the fourth quarter of 2001 has made casual international travel far less convenient. This makes the jet set smaller, and when the jet set is thin enough, it may prove impossible to find multiple independent paths between you and the recipient. A single key may even be a single point of failure for reaching users in a city.

    How would these web of trust problems be fixed without re-creating problems with the CA system?

    anyone can create a certificate for any domain.

    Certificate Transparency is one countermeasure against this attack. It's already required for EV certificates and certificates issued by CAs that have been put in a penalty box. HTTP Public Key Pinning is another countermeasure that works on a client's subsequent visits to a site. DANE is supposed to do the same through DNS lookups, but it hasn't been deployed widely for a couple reasons: the DNSSEC root zone signing key was historically too short (1024-bit RSA until nine months ago [verisign.com]), and some domain registrars (such as GoDaddy) have charged extra to manage DNSSEC.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by Justin Case on Wednesday July 05 2017, @04:52PM (2 children)

    by Justin Case (4239) on Wednesday July 05 2017, @04:52PM (#535265) Journal

    Then what's the alternative to the CA model

    Choices:
    1. One bad CA can pwn the world.
    2. MyBank.ru has certificates from 8 CAs I trust, 20 I've never heard of, and 5 I despise. Is it still MyBank.ru?
    3. MyHackedBank.ru has certificates from 20 I've never heard of, and 5 I despise. Is it still MyBank.ru?

    • (Score: 2) by Pino P on Saturday July 08 2017, @09:16PM (1 child)

      by Pino P (4721) on Saturday July 08 2017, @09:16PM (#536641) Journal

      How are members of the general public, as opposed to information security professionals, supposed to determine which CAs are trustworthy?

      • (Score: 2) by Justin Case on Sunday July 09 2017, @02:37PM

        by Justin Case (4239) on Sunday July 09 2017, @02:37PM (#536835) Journal

        I'm not part of the crowd claiming that the big bad Internet can be made safe for the ignorant masses.

        But even if they default to the (admittedly bad) assumption "trust them all" they'd be no worse off than where we are today.