libravatar-fans team mailing list archive

[Sheogorath <ubuntu@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hello Christian,

On Tue, 2020-03-10 at 17:14 +0100, Christian Weiske wrote:
> > another idea, that came up a few days ago, was the addition of a
> > proxy
> > parameter to the libravatar CDN requests or general backend of
> > libravatar.
> 
> I had such a requirement years ago: A libravatar proxy server
> that one could use as a drop-in replacement for gravatar.
> I ditched that idea because there was no way to determine the
> upstream
> avatar server from the default hash.
> 
> You solve that by adding the "p" parameter (I'd call it "d" for
> "domain").
> 
> You write
> > When the parameter is specified, the libravatar server is supposed
> > to
> > do a regular libravatar domain lookup
> 
> I would not like to see this requirement on "normal" avatar servers
> that work fine with a completely static configuration.
> This should only be a recommended parameter for avatar image proxy
> servers.
> 

Yes, this should be an optional feature. I considered this to be the
case, since we see most implementation, including my own[1], to only
support a reduced feature set. But we can definitely make this more
explicit.

> > From a security and privacy perspective it was important to prevent
> > data leaks to untrusted parties. Starting with the mail address or
> > OpenID handle itself. Therefore, to prevent usage in web frontends,
> > the proxy parameter will throw an error when typical web-browser
> > headers are set. This will hopefully prevent web developers to
> > expose
> > user domains to external users, who don't already know the user's
> > email address or OpenID domain.
> 
> My original demand was that the avatar proxy server should be
> usable by directly linking images from it. But domain exposure is
> indeed a problem, and thus would make it unusable for public sites
> unfortunately.
> 
> But the only other solution to the exposure problem is encrypting the
> domain in a way that only the server can decrypt, which would mean
> that
> the server could also get the full email address.
> 
> ----
> 
> Your solution would mean that server-side code would need to do the
> request to the avatar proxy, and that the images would go through 2
> intermediates until they reach the browser user:
> 
> [browser user] --> [application] --> [avatar proxy] --> [example.com]
> 
> 1. browser requests application web site
> 2. application returns website with an avatar image URL pointing to
> the
>    application itself.
> 3. browser renders page and fetches appication avatar image url
> 4. application fetches image from avatar proxy
> 5. application sends image back to browser
> 
> 
> To cut out the application for image delivery, the avatar proxy could
> return a "Location" redirect with the final cached image:
> 
> 1. application sends avatar request with "d" parameter to proxy
> 2. proxy responds with "HTTP redirect" response and a Location header
>    URL that points to the image at the proxy itself
> 3. Application sends the proxy image url to browser
> 4. Browser fetches image from proxy
> 
> This is something that would be more performant than the application
> tunneling that I understand is needed by your idea.
> 

I think that's actually a good idea. But we have to make sure that we
have unique URLs for all proxied pictures because otherwise one could
poison the non-namespaced proxy cache.

The only way to protect the domain name properly that would prevent
exposure of the domain information, even in hashed form would be a
double-hashed avatar handle.

For this I would propose a sha256 of <avatar-hash>@<proxy paramter
domain>. Means for the email "me@xxxxxxxxxxx" the regular sha256 would
be 855c94f3498940b241d6b5e78bb6f9293b941953b2799f8b925bd25180571d77.
For the proxied cache it would become the hash of
855c94f3498940b241d6b5e78bb6f9293b941953b2799f8b925bd25180571d77@exampl
e.org, means:
180d85d19c978edcd61cbcc47a388bd2d3cd1b5946292db9736b5df7632f92dd

This should of course have an own urlpath, since we have gravatarproxy
already, this could probably be libravatarproxy.

Means the url could look like this: 
https://avatars.example.com/libravatarproxy/180d85d19c978edcd61cbcc47a388bd2d3cd1b5946292db9736b5df7632f92dd

I think that is a way better solution that the 403.

Thanks!

--  
Signed
Sheogorath

OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt