7

I want to prove that some file I retrieved using HTTPS was indeed sent by the server. I tried searching online, but I didn't find what I want.

How to easily prove that some HTTPS server sent some file? It should not require special permissions and preferably be done with only well-known free software. The proof should be valid as long as the server's certificate is valid. The proof should be able to be validated without internet access.

An example is that the contents of a web page depends on the geographical location of the client. It's something funny when requested from my IP address such as this one. I want to show it to someone else. If I give him the link, he won't get the same page. If I give him the page retrieved from my computer, he'll think I have changed the page. Fortunately, the page is retrieved from the server using HTTPS. If the connection uses a key exchange algorithm in which the server signs the random bytes in ClientHello and ServerHello, I can show him the traffic between the server and my computer. Then he'll believe it's indeed that server which has sent me the page, because only a server that has the private key to the certificate can sign the random bytes.

Or how to easily prove the authenticity of an SSL server to someone else?

|improve this question
  • 3
    Can you elaborate a bit more? I still don't understand what you're after. Are you talking about verifying the identity of the other endpoint in a communication channel (making sure you're talking to the right server and not an imposter), or do you actually want proof that a file you have on your machine originated from a specific machine on the internet? – Pascal Nov 23 '16 at 12:22
  • 1
    Also keep in mind that SSL termination may occur long before the actual web server. There's no rule that says the SSL terminator must be the final HTTP endpoint, and many real-world setups front-load SSL termination onto separate systems. – a CVn Nov 23 '16 at 12:58
  • 1
    I would think you could do this with wireshark + capturing session keys locally. Then give the pcap + session key file to the other person to load into WireShark? I think that would let them inspect the server cert and extract the content, but I haven't done it recently enough to remember if I'm forgetting key steps. – Joe Nov 23 '16 at 17:40
  • 1
    Do you control the server in question (eg can you add additional behaviour) or do you have to work with what an existing server provides? – Pascal Nov 23 '16 at 18:25
  • 2
    OP+@Joe: given the session master, you can easily keep the true keyexchange (with server signature for EC/DHE) and fake the rest of the pcap with anything you want. If 'someone' doesn't trust your page file, they can't trust your pcap either. If only your IP is enough to demo the whatever, not your browser/OS/etc, you could set up a VPN or more simply a transport relay and let them do an HTTPS exchange via your IP to the host, which only they can decrypt (and encrypt). – dave_thompson_085 Nov 24 '16 at 7:02
4

I assume you want cryptographic proof that the server really sent this exact response. If the server signed the TLS response with the private key, for example, this would give proof that the server really sent this response.

Unfortunately, this is not what happens with TLS. The server signs something (the ServerKeyExchange message) or the client encrypts something (the premaster secret) to proof that the server knows the private key. After that, the master secret is determined by both client and server and they use symmetric encryption for the communication. You could store this to show to someone else later, but you can just as well decrypt it and change it, so it wouldn't be much evidence that it is really what you received from the server.

|improve this answer
2

It seems like you're looking for a way to protect and prove file integrity and authenticity. Basically, if SSL works properly, it's integrity should be fine and authenticity is as good as much you trust remote server.

On the other hand, you could just sign file and verify signature locally.

|improve this answer
  • 1
    /;Basically, if SSL works properly, it's integrity should be fine and authenticity is as good as much you trust remote server./; not really... what about a man in the middle? – Limit Nov 23 '16 at 14:38
  • 1
    Not what I'm looking for. I've added an example in my question, maybe it helps to understand what I want. – v7d8dpo4 Nov 23 '16 at 14:46
  • @Limit If SSL/TLS works properly, it prevents a man in the middle. That is in fact, explicitly what it is designed to do. – Xander Nov 29 '16 at 21:20
  • @Xander so that depends on your definition of working correctly. You can have a company providing a man in the middle proxy to the internet... If you don't find it as a correct working. Then yes, you're right. – Limit Nov 29 '16 at 21:24
0

Based on the example you gave, it may be easier to get the other person to connect to your computer (via webex or some open source alternative) and view it there or get the other person to connect through a VPN near your location and then navigate to the webpage.

If you want to go down the route of verifying the traffic, you can use something like wireshark to record the traffic between your computer and the server, decrypt the traffic, then extract the files you are looking for and then compare to what you saved by hashing the two files. I expect the hashing may not work due to the differences in saving a webpage in a browser and carving a file out of wireshark

|improve this answer

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.