I guess we can all agree that a screenshot of a website proves nothing; one can edit the HTML as much as one likes, take a screenshot and show a website displaying false information.

As far as I know, the way HTTPS works is it uses asymmetric cryptography in order to exchange symmetric keys, for performance reasons. This means that such symmetric key is signed by the host of the website and sent to the user, but the host isn't signing every single piece of content it serves.

The question then is, is there any way one can prove some content came from a website?

  • 2
    Archive.org? Google cache?
    – schroeder
    Commented Nov 23, 2015 at 1:01
  • 6
    Ask a reputable third party to do it (like an attorney) who will swear to its authenticity.
    – Johnny
    Commented Nov 23, 2015 at 1:28
  • 3
    You want unfalsifiable, mathematical proof that data has not been altered from the original, when you have no control over the original? Like Archive.org, Google cache, or a reputable 3rd party, the best you can hope for is a low-collusion scenario.
    – schroeder
    Commented Nov 23, 2015 at 4:39
  • 3
    Related question: Does SSL/TLS provides non-repudiation service? Commented Nov 23, 2015 at 7:01
  • 3
    @iismathwizard: On the contrary. This question is all about holding the other party accountable (not allowing them to repudiate) for content they previously generated. Commented Nov 23, 2015 at 16:10

7 Answers 7


The question then is, is there any way one can prove some content came from a website?

Not using SSL. As you mentioned, the actual content is encrypted using a shared symmetric key. Therefore either you or the other party could have created the cypher-text.

A trustworthy 3rd party such as Google cache or archive.org should be sufficient in most contexts, as mentioned in the comments.

There are plenty of cryptographic techniques which can be used for this purpose, but in this context you'd need the site to cooperate by signing the actual content using their private key (which is contrary to how SSL works).


Try http://www.icanprove.de. You can remote control a browser and all screenshots and logs are signed digitally. If more is at stake contact a notary...

  • This is a very interesting service, and it's good to know it exists. Still, I wish I could have the content signed (even if indirectly) by the same site that posted the content and not rely on a trusted third party. Probably not possible without the cooperation of the first party itself, though =(
    – user986730
    Commented Jan 2, 2019 at 14:54

Hypothetically, this is very much possible on a single end-user machine.

But there is a 'but'...

On first connection, HTTPS uses asymmetric encryption only to establish symmetric encryption. This step either assumes your computer is accepting (hence, 'KNOWS from server' symmetric key) or your computer CREATES a symmetric key. Either way it knows the symmetric key.

Now if we hypothetically catch the whole https session, or even part where part of page is transmitted - we will catch an exchange of symmetric keys that is signed by the keypair from the server and the same server accepted ACK from your machine.

Only the HTTPS server in question can use the private key of said server in question. I can see someone with knowhow, can:

  1. start catching packets (tcpdump or similar)
  2. Catch symmetric key exchange that happens inside of web browser. Which is definitely possible, but I don't know how, and it may not be trivial (it might be easier if you use something simple, maybe a text-based browser)
  3. Decode the browser session with the symmetric key (it should be very similar to typical port 80 HTTP traffic once decoded) - to show the content provided.
  4. Decode negotiation of HTTPS session that uses server's key pair to negotiate symmetric key for rest of session.

Technically some plugin or something similar in web browser can merge the first and second points.

All data given to 3rd party (who needs to arbiter situation) can be verified by using the public key of the server that supposedly did repudiation + session key negotiated between the server and your machine + record of data transmitted.

If those 3 match - we no doubt know someone with private ssl/tls key of website in question did provide this specific information.

  • 2
    Wireshark can do all the capture and even the decryption (key exchange doesn't happen in the browser). But none of this will result in something that can prove that the content came from the source. There are too many ways to break this scenario and you would have to prove that the client didn't modify the stream. This is all an interesting theory, but it won't work.
    – schroeder
    Commented Feb 5, 2023 at 23:59
  • See crypto.stackexchange.com/questions/5455/… for some interesting reading on why a packet capture of a TLS session cannot be used to prove that a server sent a particular message to a client.
    – mti2935
    Commented Feb 6, 2023 at 0:14
  • I don't need to read the link, i realized that you can modify 2 way communication data if you have asymmetric key you can modify both way communication. " you would have to prove that the client didn't modify the stream." - this nailed it. All the same thank and I shall read it.
    – user57766
    Commented Feb 6, 2023 at 19:08

The only really unfalsifiable proof would be making the site sign each chunk of data it emits, then verify them on client. However, this requires parties to either pre-share public keys via some protected channel, or trusting them to a third party to validate their authenticity.

You can see where it's going - it's almost like SSL, but authenticating every piece of data instead of session endpoint. It can be built with virtually any modern asymmetric encryption system, I see more problems with establishing trust between parties.


You can create a service that pulls the details of the site on a regular basis and archives the result. For example the site NewsDiffs.org captures major news sites state and publishes the details of their articles as they change over time.

Obviously you have to know in advance what you are attempting to study for provenance. In other words, you would have to place the site under surveillance.

Otherwise, no.


I used WordPress to create my small business website and blog. I use a free/paid WordPress plugin named WordProof.

For each web page and blog post addition and revision, WordProof calculates the hash value of the page and records it with a timestamp on the blockchain. A verifiable timestamp certificate is attached to the bottom of each web page or blog post.

This is used primarily to create an evidence log that I am the original author of the content, to prevent theft of my work and copyright infringement. It shows the specific URL of the source content and includes my business name as the copyright owner.

If I make a revision, that is also recorded with a new hash value and timestamp.

I recently added my PGP public key ID to my Contact Us page. That web page is also scanned by WordProof and timestamped on the blockchain to link the website with my PGP key ID.

  • I think the question is about the client proving that the content came from the website, not the host. Commented Mar 11, 2023 at 5:21
  • WordProof calculates the hash value of the page title and html content and records the hash value, time of publication, and URL source on the blockchain. If the web page is altered or tampered with, or a hacker or web server substitutes different content, or the data on the web server is corrupted, the content returned will have a different hash value, and should be rejected by the user as not valid. If the hash value is correct, that confirms the URL source of the content and the date/time of publication.
    – user290212
    Commented Mar 11, 2023 at 17:48

The property you are looking for is called "non-repudiation", which might be a useful starting point for additional research. However, as the link in StackzOfZtuff's comment highlights, this is NOT something that TLS provides (for the reasons given in the answers above, which remain true even now, 7.5 years later).

In general, there are two ways to achieve non-repudiation:

  • The originating party cryptographically signs the data with a private key that only they know, but for which any other party can use the corresponding public key to verify the signature. However, inherently, this only proves that the originating party signed the data; to prove anything else (like when and whether it was sent, and to whom) you'd have to sign that metadata as well.
  • A trusted receiving party (who can be yourself, but usually you want it to be a third party whom all concerned agree is trustworthy) receives the data, verifying that it comes from the originating party, adds metadata to this effect (and usually also when it was received), and applies their own cryptographic signature with their own private key to this data-and-metadata. Then, anybody with this trusted party's public key can verify the signature and - assuming they trust the signer - use that to be sure of the data's origin.

There are several third parties who do things somewhat like this. Certificate authorities are one such; they take some data from you (a Certificate Signing Request) and authenticate you (or your domain), and then add some metadata and their own digital signature to the CSR (turning it into a certificate). Anybody can take the certificate, read the metadata on it (such as who issued it), look up that CA's public key, and verify that this certificate belongs to the named subject, to the extent that they trust the issuing CA to have authenticated the CSR's subject correctly. This is the core of the Public Key Infrastructure that underlies all of TLS, among other things. Incidentally, since the signed certificate does identify the authenticated party (the subject or bearer of the certificate), it itself can't be repudiated; you can stop using the certificate at any time, but anybody can pull it out and prove that you requested the CA sign it, and they did so.

Another such category of trusted third party entity is timestamping services. These services (which may be run by people who also run CAs) take some data - generally a cryptographic hash of some larger data - and append some metadata (a timestamp and a signer) and sign the resulting blob with their private key. Any third party who has the timestamping service's public key, and trusts the timestamping service, can thus verify that at the time in the timestamp, the signed data already existed.

To protect data transmitted over a network from repudiation, you'd need a slightly different sort of service, though. ICanProve, linked above, appears to be attempting to be that service. However, this is only useful to the extent that every relevant party trusts ICanProve to be correctly authenticating the remote end of the session, not allowing tampering with the site before signing, not allowing anybody else access to their private key (which could be used to make fraudulent signatures), and (if relevant) to have an accurate clock for the timestamps. If you do trust them for all that, though, that's exactly the kind of thing you need!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .