0

Let's say I own a service and a client needs me (for the sake of this question) to provide an endpoint over HTTP (not HTTPS) that doesn't use cryptographically secure authentication. Further, there's no limit on who's authorized to call the endpoint.

This endpoint will accept some parameters in its request body and return digitally signed payloads in its response. The client would have my public key certificate prior to calling the endpoint.

What are the risks in returning digitally signed payloads over an insecure HTTP connection?

Improve this question
4
  • 4
    What does it need to be safe from? Obviously the data won't be encrypted, so anyone between client and server will be able to read it.
    – AndrolGenhald
    Feb 1, 2019 at 18:00
  • I've re-worded the question to inquire about the risks of such an approach.
    – Craig
    Feb 1, 2019 at 18:03
  • 2
    @Craig: AndrolGenhald already told you the main risk, i.e. that anybody could sniff the data since they are not encrypt although not modify since they are signed. There is not really another risk compared to HTTPS, i.e. all the other risks about misuse, DOS etc apply to HTTPS in the same way. And of course there is still the risk of improperly done signatures. It is thus not clear to me what kind of answer you expect. Also, the tag ipsec had nothing to do with your problem and thus I've removed it.
    – Steffen Ullrich
    Feb 1, 2019 at 18:19
  • 1
    It could be a lot easier for someone to harvest large amounts of data about usage patterns and behavior of your legitimate users.... depending on your service that data might be your actual most valuable asset and you're not protecting it.
    – Affe
    Feb 1, 2019 at 18:28

1 Answer 1

Reset to default
3

It depends on the requirements.

If you send public data on unauthenticated connections, and the only requirement is that the recipient can make sure that the data has not been tampered, then digital signature on the data is enough.

The pilars of security are Confidentiality, Integrity and Availability. Encryption helps for the C part, signature for the I part. As you do not use any encryption, nothing protect confidentiality, so you should not authenticate clients on such a system (the password could be intercepted), nor send confidential data.

An example use case could be the delivery of revocation lists.

Improve this answer
5
  • Could a man-in-the-middle modify the http headers themselves, thereby disrupting integrity?
    – Craig
    Feb 1, 2019 at 23:13
  • 1
    Yes, an active MitM can modify anything that isn't signed. If they have something that collides with the signed message's hash, they can also swap the message out without invalidating the signature. However, such an attack where you swap one message for another is very difficult to pull off, nearly impossible in real time, and it's possible that the only collisions that you can find of a given message will be incomprehensible garbage.
    – Ghedipunk
    Feb 1, 2019 at 23:31
  • 1
    @Craig: an attacker can also replace one signed message with a previously captured signed message.
    – Steffen Ullrich
    Feb 2, 2019 at 3:18
  • @SteffenUllrich If the signed message included a server time stamp, and the client enforced that only a packet newer than already received can be applied, does that defeat the replay attack?
    – Craig
    Feb 2, 2019 at 3:57
  • 1
    @Craig: the client only knows the packets it received itself. The attacker could replace the original response with the signed response sent to another client. In this case the rule just to get a response with a newer timestamp would not help. What could instead be done is that the client includes a random challenge in the request and the server must include this challenge as part of the signed response.
    – Steffen Ullrich
    Feb 2, 2019 at 5:58

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.