this post was submitted on 17 Nov 2023
-6 points (20.0% liked)

Security

674 readers
2 users here now

A community for discussion about cybersecurity, hacking, cybersecurity news, exploits, bounties etc.

Rules :

  1. All instance-wide rules apply.
  2. Keep it totally legal.
  3. Remember the human, be civil.
  4. Be helpful, don't be rude.

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
LinearArray
-6
WTF website certificates chain of trust... (self.security)
submitted 1 year ago* (last edited 1 year ago) by Rick_C137 to c/security
11 comments fedilink hide all child comments
 

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 SSLBecause actually httpS now use TLS not anymore ssl https://en.wikipedia.org/wiki/Transport_Layer_Security

you are viewing a single comment's thread
view the rest of the comments
[–] Rick_C137 1 points 1 year ago* (last edited 1 year ago) (3 children)

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 1 points 1 year ago (1 children)

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_C137 0 points 1 year 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 ?

load more comments (1 replies)