But I’m writing about this on this forum to bring your attention to the fact that the Redirect app in private proxy mode sends the current YNH user’s password unencrypted in the Authorization header. There needs to be a way to disable this behavior or at least the UI needs to communicate to the end user better that this is what’s going to happen with their password in case they want to create a private proxy to an endpoint that they might not entirely trust.
Additionally, this makes it impossible to create a private proxy to an application that uses Basic HTTP Auth itself.
I’m unsure, but it looks like it’s the intended behavior of the SSO when logging in, to pass the credentials along to the apps? What do you think @Dev?
I was taken aback by this behavior, as the description of the Redirect app does not make it seem like the private_proxy is meant specifically for SSO-enabled apps. I’m just using it for apps that are outside of the yunohost ecosystem but I still want to protect access to them with a login screen
Security is a word only meaningful when defining a threat model. How likely is it that some of your friend or whoever would connect to your home network and snoop on the internet traffic ?
I think the threat model is where I want to put an untrusted app (running in a docker container, for example) behind an SSO and the SSO is revealed to the app
I don’t know what you mean. You ask if things are secure, to which I answer : security is meaningless without a proper threat model. Who do you want to be secured from ?
If you reverse-proxy an app and the basic auth header credentials are going through “in clear” over the local network, then it may be “unsecure” because you don’t trust people on your local network, or it may be “secure” because you are the only person on this local network.
sends the current YNH user’s password unencrypted in the