How to Make HTTPS Verifiable

What you want is a receipt signed by the seller. Most sellers do send confirmation emails, but don't digitally sign them. Maybe they should. It would help with validating returns.

There's a startup in this. Maybe for B2B commerce.

Amusing they say "this method breaks down at scale" and then propose as a solution "All data is routed through an HTTPS Proxy"

I can't figure out why you would approach the problem this way. If you want arbitrary HTTPS connections to be verifiable and provable, why not just propose an edition to the spec which does this? This seems easier than the proposed solution, which is to introduce a trustworthy middle man to all of your online purchases. It also seems to imply the request query path is public data when this is encrypted under HTTPS afaik.

An earlier and much better documented approach is TLSNotary [1] that roughly solves the same problem in supposedly the same way and doesn't involve any spurious ledgers.

It's still quite unwieldy and requires trust in a set of notaries. IIRC a few years ago there was only efficient support for some TLS 1.2 ciphers [2], and TLS 1.3 was either very inefficient or non-functional.

[1] https://docs.tlsnotary.org/

[2] https://github.com/tlsnotary/tlsn/tree/main/tlsn/tlsn-core/s...

The sneakers example given seems pretty contrived: why wouldn't the store check its own sales records instead of asking you to submit a proof of webpage visitation?

This seems overly complex assuming you are trying to prove something when you control both aspects of the process, or are engaged with the party that does. It should be trivial to use backend records or a significantly less complex client side implementation that just verifies what the user saw/did via standard RUM tracing methods, without relying on a custom TLS implementation.

Additionally, some of the statements about the "public" values in HTTPS are false in this document, that combined with relying on their custom TLS implementation deeply concerns me from a security perspective. I'm being hard pressed to imagine a situation where I would pick "write my own TLS implementation to subtly modify the protocol" as the answer.

"Reclaim Protocol" == HTTPS MITM

And then that MITM is a trusted third party to verify towards other parties that the server sent you some data, such as an order confirmation, which that other party wants to act upon without needing to collaborate with the third party

This reminds me of https://news.ycombinator.com/item?id=29090604

I thought this would be a different proposal.

But on the topic of verified HTTP: something that I think you could do that would be pretty neat would be to allow first party assets to be offline-signed and then delivered over unencrypted HTTP (port 80).

This would mean that you could ship secure applications over HTTP (port 80) with guaranteed integrity even assuming that the server is or will become compromised.

FYI: The story title should be "Opensourcing Reclaim Protocol" not "How to make HTTPS verifiable"

> All data is routed through an HTTPS Proxy, which records the direction of data transfer without reading the encrypted content.

squints

> Certain parts of the request and response that are publicly known are revealed: For responses: HTTP response code and Date headers. For requests: Domain, Path, and Connection headers.

Um, domain (the Host header after establishing the connection), path, and headers (including Connection) are all encrypted. They claim this is public information but it's not.

I need more time to read into things but I'm skeptical thus far.

People will use this kind of thing to authenticate social media screenshots.

This could replace oracles in some cryptocurrency systems. E.g. a betting market could pay out based on a game winner verified directly from the league's website.

It seems to require changes to the server.

I was hoping for a proxy-based solution that would verify the source and time for any server.