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.
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.
Because with this approach, the entity making the statement doesn't have to cooperate. Even if they want to cooperate, there's a lot of chicken-and-egg problems in trust infrastructure that you sidestep by leveraging the existing Web TLS PKI. It would quite powerfully allow you to notarize and audit any statement by any domain.
Unfortunately (some would say fortunately) this isn't cleanly possible, so you still have to rely on witnesses and/or magic ledgers in the sky for trust.
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.
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?
It seems like this would only be useful for nonrepudiation, when people want to prove someone said something despite them denying it. The solution is to only deal with people that sign their statements to begin with, and you don't need a proxy for that.
How I understood that was that for example you sell shoe laces and want to give discounts to people who bought sneakers of brand x - but you don’t have any relation to the shoe seller. So receipt in pdf can be faked and they provide a solution so that buyer can prove they bought x and can claim your discount.
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.
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
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.
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.
I think that's what the "proxy" section is describing: A proxy which as long as it is trustworthy records direction of data transfer and with that makes any request going through it verifiable according to their scheme.
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.
Theres probably an open source library, probably not a startup. Who is really hair on fire about this?
Their email server likely signs their emails using DKIM.
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.
If you want to do something today not in ten years you use the existing protocols.
Because with this approach, the entity making the statement doesn't have to cooperate. Even if they want to cooperate, there's a lot of chicken-and-egg problems in trust infrastructure that you sidestep by leveraging the existing Web TLS PKI. It would quite powerfully allow you to notarize and audit any statement by any domain.
Unfortunately (some would say fortunately) this isn't cleanly possible, so you still have to rely on witnesses and/or magic ledgers in the sky for trust.
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?
It seems like this would only be useful for nonrepudiation, when people want to prove someone said something despite them denying it. The solution is to only deal with people that sign their statements to begin with, and you don't need a proxy for that.
How I understood that was that for example you sell shoe laces and want to give discounts to people who bought sneakers of brand x - but you don’t have any relation to the shoe seller. So receipt in pdf can be faked and they provide a solution so that buyer can prove they bought x and can claim your discount.
But still rather contrived.
Maybe the store has reasons to pretend they didn't sell you the sneakers.
What reasons would those be?
There is one "good" reason that comes to mind, but we best shouldn’t go there on HN, considering the implication.
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
At the HQ of reclaim:
Knock knock! Who's there? The patriot act.
This startup just asks to be given a national security letter.
Calling this gateway service a protocol is fraud at best and conspiracy at worst. This is just a glorified web archive service.
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.
I think that's what the "proxy" section is describing: A proxy which as long as it is trustworthy records direction of data transfer and with that makes any request going through it verifiable according to their scheme.
Ah, you mean the "server" SDK is actually for building the proxy?