[HN Gopher] How to Make HTTPS Verifiable
___________________________________________________________________
How to Make HTTPS Verifiable
Author : madhavanmalolan
Score : 23 points
Date : 2024-09-16 18:27 UTC (4 hours ago)
(HTM) web link (blog.reclaimprotocol.org)
(TXT) w3m dump (blog.reclaimprotocol.org)
| josephcsible wrote:
| This reminds me of https://news.ycombinator.com/item?id=29090604
| woodruffw wrote:
| 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?
| k__ wrote:
| Maybe the store has reasons to pretend they didn't sell you the
| sneakers.
| woodruffw wrote:
| What reasons would those be?
| ozim wrote:
| 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.
| easterncalculus wrote:
| 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.
| k__ wrote:
| 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.
| hobofan wrote:
| 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.
| Animats wrote:
| 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.
| timando wrote:
| Their email server likely signs their emails using DKIM.
| HPsquared wrote:
| People will use this kind of thing to authenticate social media
| screenshots.
| FriedPickles wrote:
| 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.
| mrbluecoat wrote:
| Amusing they say "this method breaks down at scale" and then
| propose as a solution "All data is routed through an HTTPS Proxy"
| botanical76 wrote:
| 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.
| wmf wrote:
| If you want to do something today not in ten years you use the
| existing protocols.
| throwaway89201 wrote:
| 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.
|
| 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.
| mholt wrote:
| 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.
| tristor wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-16 23:00 UTC)