4
$\begingroup$

(This is probably a basic question, and may be a duplicate; if so, just let me know.)

Suppose there are two clients A and B, and some server C. Suppose B and C establish an HTTPS tunnel, and C sends a response to B. And suppose B records the response, and sends it to A.

  • Can A verify that the alleged response from C was actually sent by C?

This is essentially equivalent to "Are HTTPS responses non-repudiable?". As far as I am aware, HTTPS only provides a secure channel, but does not provide digitally signed traffic.

Motivation

I'm tentatively planning to create a social network add-on which would allow users to flag other users who have sent them offensive material via private messages. I would hypothetically run a web service which would receive flag requests, and in order to avoid spam flags, I would need some way for the flagger to voluntarily send me a minimum but sufficient amount of information to verify that the private message actually exists.

In this scheme, I am A, the flagger is B, and the social network is C.

Is there any sane way to do this, without compromising the flagger's security?

Improve this question
$\endgroup$
3
  • $\begingroup$ May we assume the session between B and C to be mutually authenticated (-> client certificates)? If so I think the answer will be "yes", otherwise "no" as anyone could record such a session and there would be no proof that the actual B was involved. $\endgroup$
    – SEJPM
    Commented Oct 10, 2015 at 18:03
  • $\begingroup$ @SEJPM: Thanks, and sadly I don't think client certificates are involved. Would restricting to "verify the server response actually happened", rather than the entire web session, make things easier? Ultimately, I only need to verify that the social network sent a page showing a conversation between B and the other person. Verifying that the page was actually received by B is not necessary. I edited the question accordingly. $\endgroup$
    – DumpsterDoofus
    Commented Oct 10, 2015 at 18:34
  • $\begingroup$ Dupe of crypto.stackexchange.com/questions/5455/… $\endgroup$
    – dave_thompson_085
    Commented Dec 13, 2015 at 2:02

1 Answer 1

Reset to default
4
$\begingroup$

No you can't prove that C sent something.
The only thing you can reliably prove to somebody is that somebody at some point had a HTTPS connection to C, by presenting the key exchange.

You can't prove that C send something because the record layer is symmetrical, meaning everything C sent, could be forged by B as he has to have the neccessary keys.

To understand, let's quickly recap how TLS (the security layer behind HTTPS) works:
The server and the client negotiate a shared secret using the key-exchange which also proves to the client that he is communicating with the correct server. Both parties derive four keys (2x authentication and 2x encryption). The data you consider is symmetrically encrypted and then symmetrically authenticated meaning the receiving party can as well construct this exact message using the symmetric methods (by encrypting and authenticating the message with the appropriate keys). If the user presents you with a full transcript of his side of the key-exchange and communication you can't be sure if he forged the claimed message or if the server sent it legitimately as he must have the keys for that or he couldn't have received the message in the first place.

Improve this answer
$\endgroup$
2
  • $\begingroup$ So since the bulk exchange is symmetric, it can't be verified by an outside observer (since symmetric traffic doesn't establish identity), and only the existence of the initial handshake used to establish the symmetric key can be verified? Darn. Do you have any suggestions for weaker but usable workarounds, or perhaps a different approach altogether? $\endgroup$
    – DumpsterDoofus
    Commented Oct 10, 2015 at 21:31
  • $\begingroup$ @DumpsterDoofus, yes that's a pretty good summary of what you know :) The ultimative approach would be of course to just let the network sign those messages / allow access to them for verification, but I guess that's impossible. Sadly I don't have any other ideas on how to approach your problem :( $\endgroup$
    – SEJPM
    Commented Oct 10, 2015 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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