7 ms·

Is it possible to write a program that connects to an HTTPS server and archives content, but it keeps track of the session keys and the encrypted data coming fr

Is it possible to write a program that connects to an HTTPS server and archives content, but it keeps track of the session keys and the encrypted data coming from the server, and then records all that session traffic in a file. Replaying the file will allow anyone to observe that the data truly did come from that specific server, because it's signed with the cert for that server. In other words, is it possible to get any HTTPS website to give you what is essentially a digitally signed copy of content you want to prove originated with that site? And is it true that that digital signature is easily verified to belong to the original website?

ajsfoux234 5y ago
TLSNotary tries to solve this problem: https://tlsnotary.org/ https://tlsnotary.org/ It was posted here a while ago: https://news.ycombinator.com/item?id=29090604 https://news.ycombinator.com/item?id=29090604
paxys 5y ago
The problem is when you are trying to verify the data down the line the original certificate (up to and including the root cert or even the authority itself) will have expired, so it won’t be possible to trust it.
- rentnorove 5y ago
  Wouldn't you want to validate it for the time at which it was served? In which case you'd just an archive of the CA roots at the time.
  - paxys 5y ago
    And how do you verify that the CA roots are authentic?
    - notriddle 5y ago
      The Hg history from Mozilla-Central?
      - paxys 5y ago
        Sure but that's still a third party dependency. And then you have to verify that the Firefox source is authentic. My point is there's no way to have a fully self verifying archive.
- duskwuff 5y ago
  You can still verify a signature from an expired certificate. With certificate transparency, you can even verify the issuance of that certificate.
kiwidrew 5y ago
Unfortunately it's not possible, because TLS negotiates a symmetric key which is then used to encrypt and authenticate the rest of the session. If you post the transcript of a TLS session in an attempt to "prove" that you retrieved a specific document, a third party can verify that you did in fact negotiate a symmetric key with the correct server; but since it's a symmetric key, anyone with knowledge of the key can arbitrarily modify the transcript of the session [well, the part of the session where the HTTP request and response happen]. This obviously includes the original prover, and so a TLS transcript proves nothing at all.
Fudgel 5y ago
Not sure if this is entirely what you're after, but check out https://github.com/WICG/webpackage https://github.com/WICG/webpackage

ajsfoux234 5y ago

TLSNotary tries to solve this problem: https://tlsnotary.org/ https://tlsnotary.org/ It was posted here a while ago: https://news.ycombinator.com/item?id=29090604 https://news.ycombinator.com/item?id=29090604

paxys 5y ago

The problem is when you are trying to verify the data down the line the original certificate (up to and including the root cert or even the authority itself) will have expired, so it won’t be possible to trust it.

rentnorove 5y ago
Wouldn't you want to validate it for the time at which it was served? In which case you'd just an archive of the CA roots at the time.
- paxys 5y ago
  And how do you verify that the CA roots are authentic?
  - notriddle 5y ago
    The Hg history from Mozilla-Central?
    - paxys 5y ago
      Sure but that's still a third party dependency. And then you have to verify that the Firefox source is authentic. My point is there's no way to have a fully self verifying archive.
duskwuff 5y ago
You can still verify a signature from an expired certificate. With certificate transparency, you can even verify the issuance of that certificate.

kiwidrew 5y ago

Unfortunately it's not possible, because TLS negotiates a symmetric key which is then used to encrypt and authenticate the rest of the session. If you post the transcript of a TLS session in an attempt to "prove" that you retrieved a specific document, a third party can verify that you did in fact negotiate a symmetric key with the correct server; but since it's a symmetric key, anyone with knowledge of the key can arbitrarily modify the transcript of the session [well, the part of the session where the HTTP request and response happen]. This obviously includes the original prover, and so a TLS transcript proves nothing at all.

Fudgel 5y ago

Not sure if this is entirely what you're after, but check out https://github.com/WICG/webpackage https://github.com/WICG/webpackage