>>957786
>can we not determine that the response is indeed from the possessor of the HTTPS certificate for that domain?
Hmm, you might be able to actually, I'd not thought about it. I'd need to review the handshake. The negotiated DHE session key (there are actually lots of potential ciphers, it's a hot mess) for the client might be under the client's control though, if so it might be worthless as proof. There's also the possibility of forcing the negotiation of a weaker form of SSL without it that would still be usable as proof but since POODLE I don't know how many servers still have old versions enabled. You might want to ask a crypto-specific group not on a chan.
If you could link them in a provable way, it'd need a lot of custom code to make that into something that could be easily shared in a way that people could understand the proof, though. It'd be a custom client, custom proof check, and custom extractor, not something that's recording a live browser session or a way to just hit it with a browser to replay it. I also don't think there's a way as a pure web app as there's no access to the raw stream let alone the session keys, which makes it a bit inconvenient.
>As you've mentioned with Blockchain, this is only useful to determine that a piece of data existed at a certain point in time (hash and commit), but it cannot prove authenticity/tamperlessness of a response - which is what I'm primarily interested in atm.
Yeah, I mentioned it as a separate thing. You'd ideally want both types of proof as it shows there was no way to have created the authenticated data after that point in time, like by hacking the server.
>Maybe timestamps are actually used somewhere in HTTPS key-exchanges
The cert itself has an expiration date but it's worthless because nothing prevents reusing an expired one to forge "old" data. Time really needs a third party to vouch for. There are commercial "e-notary" services that lawyers use for this that just sign a hash with the time, or you can ghetto the same thing up with buttcoin.