Imagine a web application in which two computers can communicate with each other by transferring files, through the server linked with some unique password.

Every file sent between the clients are sent through the server, means that the server just connects them and acts like a middleman, so he can see all data that is sent.

Due to privacy reasons, I would like to prevent the server from reading the contents of any sent file, so any client can trust that the server will never know what's in the file.

So asymmetric encryption solves it as-long as the server really follows the protocol, but that does not prevent the server from tricking the protocol.

For example:

enter image description here

A has the public key of B

B has the public key of A

Now both can use their public keys to encrypt the data and send it over to the server.

But there is an issue

When A sends the public key to B, it uses the server in order for B to receive it. But what if the server saves that public key for itself, and sends B its own public key, and B will trust it that it's A's public key and use it to encrypt the data?

The server will receive the data and unlock it using his own private key and save the file locally, and afterwards use the real A's public key to encrypt the file and send it to A as it was sent from B.

This completely tricks it, and I think that Certificate Authority also can not really fix this issue that in worst-case if the server wants, it can always trick it because everything that goes to client B from A will always reach the server first and the server can remember any data, keys and pass anything to the other side.

Maybe I am missing something and don't really understand the solution of CA/signatures

Also I cannot use peer-to-peer connections, not even just to pass keys.

  • I think everything hinges on your belief that a CA won't work. Why do you think that?
    – schroeder
    Sep 15, 2021 at 14:45
  • Probably I understand it incorrectly Sep 15, 2021 at 14:47
  • This whole post boils down to this one point, though. So, what do you understand about CAs and why won't they help? If you don't talk about that, we'll just post a link to Wikipedia on the topic.
    – schroeder
    Sep 15, 2021 at 14:51
  • I think because that since the server is the one who is in charge for the client's communication, he can see and send whatever it wants. It can even give both a certificate he requested from the trusted authority for himself and send that one to the clients, the client cant really know if the server gives him a real certificate from the other client because it has no direct contact to the other client, everything is through the server Sep 15, 2021 at 14:55
  • @benberizovsky See signal.org/blog/safety-number-updates for how Signal solves this problem without using CA's.
    – mti2935
    Sep 15, 2021 at 18:15

1 Answer 1


There is a fundamental rule here: in order to create a secure channel through an untrusted network, both ends of the channel must both possess some prior information that has been pre-shared through a trusted mechanism. The function of a Certificate Authority is to provide this shared trust without the two communicating entities needing any prior knowledge of each other in particular.

First, consider how you might set up a secure channel between two people exchanging messages over a long wire. If the two people know nothing about each other, they have no way to prove that the person on the other end is who they say they are, and no way to prove that a message sent from one end was not tampered with before it got to the other end. Since they share no common information, they cannot encrypt their messages either. This is a fundamental problem that cannot be bypassed.

If the two people communicating met in person, beforehand, they could share some secret information that allows them to verify the authenticity of messages, e.g. by agreeing upon a password and using that to generate encryption and authenticity keys. This is called a "pre-shared key", or PSK for short.

If the two people can't meet in person, they might establish a PSK using an existing channel that they both trust. For example, they could talk to each other on the phone if the types of attackers they're worried about aren't able to tap phones. This is known as an out-of-band (OOB) channel.

Certificate Authorities effectively act as a trusted out-of-band channel, but instead of using them to share keys directly (which doesn't scale and is problematic from a security perspective) they instead use the CA as a root of trust that provides each user with enough trusted information to build secure channels with each other, without needing a PSK or having to share any actual messages with the CA. In this way, CAs are effectively proxies for trust - if Alice trusts the CA, and the CA has validated Bob's identity, then Alice can trust that she is communicating with Bob.

If you think about a client connecting to a server over the internet, there are a ton of routers along the way that are untrusted. The server knows nothing about the client beforehand, and the client knows nothing about the server other than its name. However, the client has a trusted set of CA certificates installed on their system, and the server's certificate is signed by one of those CAs. As such, the client can trust that they are communicating with the real server, and not someone else. In practice, the "trust" is implemented and enforced using cryptography.

In your example, both clients could communicate securely by using a trusted CA, assuming that the CA performs their job properly and does not incorrectly issue a certificate to the wrong person.

Here's an example:

  1. Alice and Bob both generate an asymmetric (public/private) key pair, and a certificate signing request (CSR).
  2. They send the CSR to the CA, along with proof of identity. The CA verifies that the name on the CSR matches the name on the proof of identity, and issues a certificate to each of them. This certificate is signed using the CA's private key, and contains the user's name and public key.
  3. Alice and Bob both register their certificates with the server.
  4. Alice tells the server that she would like to talk to Bob. The server sends over Bob's certificate. Alice can look at the certificate and verify it against the CA's trusted certificate. If the name on the certificate says "Bob", and the signature is valid, she knows that this is an authentic copy of Bob's certificate.
  5. Alice encrypts a message using Bob's public key, from the certificate. (In practice a hybrid cryptosystem is used, but that's an implementation detail.) She signs the encrypted message with her private key. She asks the server to send it to Bob.
  6. The server sends the message to Bob, and says "this came from Alice".
  7. Bob asks the server for Alice's certificate, and the server sends it.
  8. Bob looks at the certificate, checks that the name on it says "Alice", and verifies its authenticity using the trusted CA certificate. If it is properly signed, he knows that this is a legitimate copy of Alice's certificate.
  9. Bob uses the public key from Alice's certificate to validate the signature on the message that was delivered from Alice. If it matches, he knows that the message was not tampered with.
  10. Bob now uses his private key to decrypt the message from Alice. He now has the message.

The server at no point has access to the plaintext message. If the server sends its own certificate instead of the real one for Alice or Bob, the user can see that the name on the certificate either does not match the name of the person they were expecting to talk to, or that the certificate was not properly signed by the CA. If the server attempts to modify the message in transit, it cannot falsify the signature, because it does not have access to the user's private key.

This does not completely protect the channel from attack, though. The server can still substitute previous legitimate messages into the conversation, using a replay attack. Since the previous messages are properly signed, and the server is not modifying the message itself - just substituting the message for a different one - this allows the server to change the meaning of the conversation without changing the content of the individual messages. Consider this chat:

Bob: How much did your car repairs cost?

Alice: $1300

Bob: Damn, that's a lot.

Alice: Yeah :(

[conversation continues]

Bob: Hey, the contractor is asking for more money than I expected, how much are we supposed to be paying them?

Alice: Huh? We already paid them in full.

Since all messages are legitimately signed, the server can take any previous message and substitute it in place, as long as it is going from and to the same people, in the same direction:

Bob: How much did your car repairs cost?

Alice: $1300

Bob: Damn, that's a lot.

Alice: Yeah :(

[conversation continues]

Bob: Hey, the contractor is asking for more money than I expected, how much are we supposed to be paying them?

Alice: $1300

The server has not forged any signatures, but it has changed the meaning of the conversation.

This can be resolved in a number of ways, such as by the client including a random message ID at the start of every new conversation, then incrementing that ID after each message. This ID is inside the encrypted message itself, which is signed by the user's certificate, so the server cannot see the ID or tamper with it. If the server tries to replay a message out of order, the client can detect that this happened:

[350785249] Bob: How much did your car repairs cost?

[540582471] Alice: $1300

[350785250] Bob: Damn, that's a lot.

[540582472] Alice: Yeah :(

[350785251] Bob: Hey, the contractor is asking for more money than I expected, how much are we supposed to be paying them?

[540582471] Alice: $1300

Notice how the message IDs for Bob go in order: 350785249, 350785250, 350785251. But, for Alice, the message IDs go: 540582471, 540582472, 540582471. This allows Bob to detect that Alice's previous message was replayed.

This also protects against omission, i.e. the server removing a message from the conversation by choosing not to deliver it. When the next message comes along, the message IDs will not be in sequence because a message was not delivered.

In practice this is usually implemented in a more secure way than just ID numbers, but this illustrates the point more clearly than a full technical description of replay protection.

The security of this system hinges on both users trusting the CA to only issue certificates to legitimate users who have been properly identified. The mutual trust in the CA is what allows them to create a secure channel.

An alternative is for the users to pre-share their certificates or public keys through a trusted out-of-band system. This is how email encryption works, for the most part. Users may publish their public keys on social media, on a USB stick through the mail, via email in an encrypted ZIP archive with a password shared over the phone, or even directly in person, depending on what level of security they require. All that changes here is the mechanism of establishing prior trust.

  • Hey thanks a lot for the answer, I have a question - What if Alice asks the server to talk to Bob, and the server does the same procedure - generates an asymmetric key pair and an CSR and creates a certificate using some name through the CA and sends that certificate to Alice, how can Alice be sure that this is Bob? The server did the exact same thing that Bob did to get his certificate.. Sep 15, 2021 at 20:30
  • The server can do literally anything, there is no pre-set string or password that is set on both clients that the server does not know of, server will always know anything that both has besides their private keys Sep 15, 2021 at 20:31
  • The whole point of having a CA is that they have rules and procedures about who they will issue a certificate to. In this example context that would mean something like the CA requiring a copy of the person's photo ID. In reality, CAs generate certificates for websites. They usually validate the legitimacy of the request by requiring that the server owner sets a DNS record containing a certain value, or serves a file from the web server containing some specific text. This proves that the person asking for the certificate for that server has control over the server.
    – Polynomial
    Sep 15, 2021 at 20:36
  • In the example I gave, the server couldn't impersonate Bob because it wouldn't have access to his photo ID, so the request to the CA would be denied.
    – Polynomial
    Sep 15, 2021 at 20:37
  • I just don't understand the part of which why the server can't just act as if it's a client and request a certificate from the authority and pass it to one of the clients saying hey did is Bob's certificate Sep 15, 2021 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.