Follow

Ya know what'd be great ?
An HTML/HTTP extension for encrypted (at rest) resources. Exact same thing as subresource integrity except instead of checking a hash, it decrypts.

As it stands, everyone's forced to choose between letting their TLS be MiTM'd or having no caching and exposure to DDoS.

· · Web · 1 · 0 · 1

@cjd
Not as useful as it initially sounds, but with per-file key for files available only to authenticated users, it'd make sense.

@Wolf480pl
Being able to encrypt form posts and key-stretch passwords on the client would also be great. Of course these things are possible now with js, but it would be nice if they were standards...

@cjd
I thought POSTs bypass cache anyway, and you're supposed to serve your cdn-MITMed content on a separate domain, right?

@Wolf480pl
Unfortunately, DDoS is such a reality right now that if you're hosting anything even marginally controversial, you need to either use a massive hosting provider (OVH, Amazon, Google), hide your IPs behind CF, or ideally both.

@cjd ok, but if the POST goes through the MITM, then so does the GET for the toplevel document, and the MITMer learns all the keys, making the whole exercise moot

@cjd ok, but what's the point of encrypting subresources then?
The toplevel document needs to provide keys with which the browser can decrypt the subresources, but since the DDoS protection company MITMs the toplevel document, it necessarily gets those keys as well, and can decrypt the subresources as well.

And why does DDoS protection require MITMing TLS anyway?

@Wolf480pl
Oh indeed (silly me)... so I guess it should be a key in the URL itself so that href tags can contain it as well...

@Wolf480pl
Argh, that reference makes me cringe because novaking and I used it first in ezcrypt but @sebsauvage was better at making it known... BTW Seb, did you know about ezcrypt when you did zerobin?

But anyway no, it would be better for the browser to do the decryption so you don't have to trust the js.

@Wolf480pl @sebsauvage
According to the git history, it looks like they were created within days of eachother. Just my memory was after we had the idea of doing that and we got ezcrypt up and working, suddenly there was a newspaper article about zerobin. Anyway, CryptPad took the technology another great step forward.

@cjd @Wolf480pl

I heard of ezcrypt after I created ZeroBin.

For the crypto key in the fragment part of the URL, I was inspired by FreeNet (which is a decentralized P2P client with a rather heavy Java client).

I was wondering if it would be possible to do the same without a specific client.

Originally, ZeroBin was juste a POC, for fun.

@sebsauvage @Wolf480pl
Oh interesting, I didn't know FreeNet was using the fragment, but then I probably spent more time reading about their routing algorithm than testing the implementation...

@cjd @Wolf480pl

Oh... there I found it.
My first version of ZeroBin was 2012-04-11.

I only put it on GitHub later on.

@sebsauvage @Wolf480pl
I have no idea when ezcrypt was first put together, the domain was registered in 2011-03-29 but I think NK registered it and held it because I don't think we were working on it until 2012...

@cjd @Wolf480pl
FreeNet is not using the fragment part, but the crypto key is definitely in the URI.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!