Hi,

If you don’t know how work the chain of trust for the httpS

You might want to watch this video https://invidious.privacydev.net/watch?v=qXLD2UHq2vk ( if you know a better one I’m all ears )

So in my point of view this system have some huge concerns !

  1. You need to relies to a preinstalled store certificate in your system or browser… Yeah but do you know those peoples ??!! it might seem weird, but actually you should TRUST people that YOU TRUST/KNOW !!

Here an extract from the certificate store om Firefox on Windows.

I do not know ( personally ) any of those COMMERCIAL company !

  1. Of course we could use Self-certificate but this is not protecting against Man-in-the-middle_attack . Instead of using a chain (so few 3th party involved , so increasing the attack surface ! ) why not using something simpler !? like for example
  • a DNS record that hold the HASH of the public key of the certificate of the website !
  • a decentralized or federated system where the browser could check those hash ?

Really I don’t understand why we are still using a chain of trust that is

  1. not trusted
  2. increase the surface of attack
  3. super complex compare to my proposals ?

Cheers,

Why I don't use the term SSL

Because actually httpS now use TLS not anymore ssl https://en.wikipedia.org/wiki/Transport_Layer_Security

  • @[email protected]
    link
    fedilink
    97 months ago
    1. How would you verify the DNS records? Dnssec?
    2. How would a federated or decentralized system be able to establish trust?

    Your proposals aren’t thought through. I’m not a huge fan of the current system, especially government mandated certificates without a public certificate transparency log, but if you think a different decentralized system will somehow be more trustworthy then I have a bridge to sell you.

    • @Rick_C137OP
      link
      -27 months ago

      Thanks for you reaction @[email protected]

      1. Yes trough Dnssec, or something else ?

      2. Maybe we should go toward a blockchain ? but maybe it’s overkill ?

      • @fettuccinecode
        link
        17 months ago

        Just promote DANE. You could even use self-signed certificates considered as trusted because they are set in a DNSSEC-signed TLSA Resource Record for a host, protocol and port. Unfortunately, end-user software adoption is not the best currently.

  • @RonSijm
    link
    67 months ago

    Really I don’t understand why we are still using a chain of trust that is

    It would basically be mutually assured destruction if one of these trusted root certificates would hand out false certificates. If evidence comes to light that a Root Certificate Authority creates false certificates or can’t be trusted somehow, they get delisted. For example, look up “TrustCor” - they were too closely tied to US intelligence that everyone (Mozilla, Microsoft, Google, Apple) removed them as trusted CAs

    a DNS record that hold the HASH of the public key of the certificate of the website !

    How are you getting that record safely, over the internet? There’s DNS cache poisoning and other attack vectors on DNS related services that would still let you MITM https.

    Systems that rely on you to go on the internet to check if the internet is safe can just as well be compromised. How do you ensure the “internet based trust lookup” can be trusted?

    • @Rick_C137OP
      link
      English
      -27 months ago

      So maybe the solution relies trough a blockchain ?

      or something that from scratch mind privacy, and decentralization ? Like TOR

      • @RonSijm
        link
        27 months ago

        So maybe the solution relies trough a blockchain ?

        I don’t really see how that would help - but maybe you can elaborate how a blockchain solution would help?

        • @v9CYKjLeia10dZpz88iU
          link
          -2
          edit-2
          7 months ago

          Domains depend on cryptographic keys instead of a group of trusted companies. There are blockchain solutions that exist already. [Ethereum Name Service, Namecoin, etc] The problem becomes determining if the client has the correct blockchain or has enough proof that the retrieved records from the blockchain are accurate.

          They’re not really necessary though, as the current system has worked very well.

  • @Rick_C137OP
    link
    English
    1
    edit-2
    7 months ago

    and what about something like this.

    1. The visitor connect on the website
    2. he receive the public key
    3. The key ( it’s hash ) is compared with at least two “verification” server , if they all return a positive match, the visitor can use the pub key to initiate.

    The “verification servers” grab the public key directly from the Web server.

    Any suggestions, ideas ?

    • @RonSijm
      link
      17 months ago

      How do you stop this? (Sorry I only have paint on this machine)

      1. Computer/Network is compromised

      2. User requests public key from Server

      3. Hacker intercepts it, sends his own public key

      4. User tries to connect with “verification” servers

      5. Requests get redirected to compromised servers to OK the verification

      6. User sends request to Server via Hacker with Hacker PubKey

      7. Hacker decrypts it, re-signs it with Server PubKey

      8. Sends it to server, gets response

      9. Hacker decrypts server response, re-encrypts it with Hacker Private Key

      10. Users receives message, can decrypt it with Hacker PubKey, everything looks normal

      You’re just substituting a local “Chain of Trust” with a server based trust system… Why would you trust that you can securely call the verification servers, and even if you can, why trust the verification servers?

      • @Rick_C137OP
        link
        07 months ago

        If the computer of the Visitor is already compromised ! your simulation can stop there I think…

        My scenario assume that the visitor computer is not compromised.

        But let say his traffic get intercepted. Sure a hacker can send his PubKey (2) but in (3) the visitor (should) have already the PubKey of one (or few) verification server. So it should not be possible for an hacker to interfer with the communication (3) right ?

    • @v9CYKjLeia10dZpz88iU
      link
      -3
      edit-2
      7 months ago

      Blockchains are a good solution for this problem. [*] One of the most popular/experimental solutions available right now are Ethereum Name Service domains. Though, in the past, there have been other attempts with much less functionality like Namecoin’s domains.

      [*] I don’t actually see it as a problem excluding concerns of government MITM attacks. The current chain of trust system has worked very well.