Skip to main content
Information Security

Return to Answer

added 469 characters in body
Source Link
mentallurg
mentallurg
  • 12.6k
  • 5
  • 38
  • 51

Here are some questions to think about:

  1. "client sends signed request with e.g. pre-registered ed25519 to some server" - If you don't use TLS, how will client know that it talks to the server and to a man-in-the-middle?

  2. How will your server know who is trying to pre-register? How will server distinguish real clients from the man-in-the-middle?

  3. "Server response must also be signed." - How will clients know, if the signature belongs to your server and not to the man-in-the-middle? In case of TLS it is trivial. How are you going to address that?

  4. If your server was compromised (configuration error, social engineering, bug in software, etc.), how will clients know that the old signature should not be trusted any more? In case of TLS it is trivial. How are you going to address that?

  5. You don't write any word about encryption. Does it mean you are not going to encrypt the traffic? If you want to encrypt it, how are you going to share the encryption key?

  6. How about Perfect Forward Secrecy? It seems you are not going to implement it. In particular this means that if an attacker obtains server keys, it will be possible to decrypt any previous traffic that was intercepted. Where as in case of TLS there is no way to decrypt any previously captured traffic, even if you know server keys.

Here are some questions to think about:

  1. "client sends signed request with e.g. pre-registered ed25519 to some server" - If you don't use TLS, how will client know that it talks to the server and to a man-in-the-middle?

  2. How will your server know who is trying to pre-register? How will server distinguish real clients from the man-in-the-middle?

  3. "Server response must also be signed." - How will clients know, if the signature belongs to your server and not to the man-in-the-middle?

  4. If your server was compromised (configuration error, social engineering, bug in software, etc.), how will clients know that the old signature should not be trusted any more?

  5. You don't write any word about encryption. Does it mean you are not going to encrypt the traffic? If you want to encrypt it, how are you going to share the encryption key?

Here are some questions to think about:

  1. "client sends signed request with e.g. pre-registered ed25519 to some server" - If you don't use TLS, how will client know that it talks to the server and to a man-in-the-middle?

  2. How will your server know who is trying to pre-register? How will server distinguish real clients from the man-in-the-middle?

  3. "Server response must also be signed." - How will clients know, if the signature belongs to your server and not to the man-in-the-middle? In case of TLS it is trivial. How are you going to address that?

  4. If your server was compromised (configuration error, social engineering, bug in software, etc.), how will clients know that the old signature should not be trusted any more? In case of TLS it is trivial. How are you going to address that?

  5. You don't write any word about encryption. Does it mean you are not going to encrypt the traffic? If you want to encrypt it, how are you going to share the encryption key?

  6. How about Perfect Forward Secrecy? It seems you are not going to implement it. In particular this means that if an attacker obtains server keys, it will be possible to decrypt any previous traffic that was intercepted. Where as in case of TLS there is no way to decrypt any previously captured traffic, even if you know server keys.

Source Link
mentallurg
mentallurg
  • 12.6k
  • 5
  • 38
  • 51

Here are some questions to think about:

  1. "client sends signed request with e.g. pre-registered ed25519 to some server" - If you don't use TLS, how will client know that it talks to the server and to a man-in-the-middle?

  2. How will your server know who is trying to pre-register? How will server distinguish real clients from the man-in-the-middle?

  3. "Server response must also be signed." - How will clients know, if the signature belongs to your server and not to the man-in-the-middle?

  4. If your server was compromised (configuration error, social engineering, bug in software, etc.), how will clients know that the old signature should not be trusted any more?

  5. You don't write any word about encryption. Does it mean you are not going to encrypt the traffic? If you want to encrypt it, how are you going to share the encryption key?