GNOME Bugzilla – Bug 740917
HTTPS/FTP Proxy authentication
Last modified: 2021-06-10 20:52:51 UTC
Currently the authentication can only be set for HTTP, but not for HTTPS/FTP. My idea is: reusing the authentication from HTTP for HTTPS/FTP, if it is using the same proxy. Find a patch attached that attempts to implement this feature. The patch is not meant to be final, but for starting the discussion on how to set the proxy authentication. Note: I could not test the patch due to configure errors for the gnome-3-14 and master branches.
Sorry, I totally don't get what you're talking about. Could you please clarify? Are you sure you wanted to file a bug for *gnome-terminal*? By the way, you did not attach any patch.
Created attachment 292056 [details] [review] Reuse HTTP authentication for HTTPS/FTP if using the same proxy First of all: Yes, this is a patch for gnome terminal, especially terminal-util.c. Also: My bad, I totally forgot to attach the patch :-/ Currently gnome-terminal exports 4 environment variables, when a proxy is set in the settings: ftp_proxy http_proxy https_proxy no_proxy The gsettings scheme only allows setting the authentication for HTTP (keys "use-authentication", "authentication-user" and "authentication-password"). This means HTTPS and FTP (which likely need an authentication as well) cannot set it. This patch works around this by assuming the following: If the proxy is the same for FTP (or HTTPS), use the same authentication as HTTP.
Oh I see, thanks. Makes sense to me. Ideally we should get in touch with those who use these variables and make sure they all interpret the authentication bits consistently. In the mean time I'm wondering why there's such code in g-t at all. If setting these env vars is important then it should happen on desktop level, not for the terminal. g-t should already receive these when it's launched from the desktop.
I've taken a look at the Chromium source code on how they interpret the values. When looking at "use-authentication" they always check the HTTP scheme, no matter which protocol: https://code.google.com/p/chromium/codesearch#chromium/src/net/proxy/proxy_config_service_linux.cc&rcl=1417472422&l=667 "authentication-user" and "authentication-password" are not present in the code, i.e. they don't use these values and force the user to enter the values manually. The reason is that Chromium does not seem to support this feature yet (see https://code.google.com/p/chromium/issues/detail?id=16709). I also looked at the Firefox code and they ignore all 3 of them ("use-authentication", "authentication-user" and "authentication-password"). I wasn't able to figure out how Epiphany does it's network handling.
Egmont just pointed me to that feature request over in bug #747800. I think this "feature" should definitely not be implemented, if at all, then only on an opt-in basis with big fat warnings. a) Sorry for my harsh words, but automatically providing secret credentials in environment variables, seems to be an even more stupid idea than doing this manually on a by-case basis when one (hopefully knows) whether the credentials are safe there. b) It further happens all too easily, that environment variables are exported on in "child environments",.. now you may say that this is not a security issue for locally running processes (well you cannot really guarantee that, can you?), but you definitely have a security incident, when a user in such terminal then e.g. SSHs to a remote host. The environment variable (depending on the configuration) may be passed on and the remote end then knows about your credentials. Security-wise, definitely an absolute no-go. Cheers, Chris. btw: I don't want criticise too strongly, but that this is quite some security issue should IMHO not just be noted, because I accidentally stumble over that bug :-( I mean what happens next? GNOME exporting my gnupg secret key password that it somehow reads before, and exports it to all kinds of shell just to make things "more convenient and work out-of-the-box™"?!
I think you're way too paranoid here. As far as I can see, the auth password is already part of http_proxy; copying it to https_proxy too wouldn't make it any worse. I can't see why storing passwords in environment variables would be inheritently wrong or dangerous. ssh does not forward env variables, except for a few whitelisted ones. I doubt any distro ships with http_proxy and such being enabled. In fact it would make no sense whatsoever; when ssh'ing to a remote host it's a very bad assumption in generic that the same proxy would work over there. Anyone who sets a proxy password in gnome-settings _and_ enables forwarding http(s)_proxy via ssh, should really think about the consequences. (That being said, I agree that the current design is far from ideal. But addressing _this_ bug and setting https_proxy similarly to http_proxy which we already set wouldn't make it any worse.)
(In reply to Egmont Koblinger from comment #6) > As far as I can see, the auth password is already part of http_proxy; > copying it to https_proxy too wouldn't make it any worse. Well then we already have the security issue. > I can't see why storing passwords in environment variables would be > inheritently wrong or dangerous. Well I just gave you the example with SSH, this should already speak for itself. Apart from that, I think this is simply basic security ABC... just take a look at any sane program from the security area, they either strongly warn against using passwords in env vars, or intentionally don't implement something like that at all (e.g. gpg). > ssh does not forward env variables, except for a few whitelisted ones. Which doesn't mean that no user has changed that default. And since no one can expect that gnome-terminal/vte sets any sensitive data in env vars, why should one not do if it seems handy. > In fact it > would make no sense whatsoever; when ssh'ing to a remote host it's a very > bad assumption in generic that the same proxy would work over there. Sure but that's just the aspect that things then don't work (which is just what I wrote in the other bug)... here it's more about the leak of credentials... it doesn't matter that the remote system may not be able to use the proxy,... it then possesses the credentials which may also work for other services. > Anyone who sets a proxy password in gnome-settings _and_ enables forwarding > http(s)_proxy via ssh, should really think about the consequences. Why? Who should anyone expect that GNOME exports these values into the terminals? Since this is absolutely non-standard and unexpected behaviour, the responsibility here lays rather on the GNOME side. > (That being said, I agree that the current design is far from ideal. But > addressing _this_ bug and setting https_proxy similarly to http_proxy which > we already set wouldn't make it any worse.) Yeah, I mixed that a bit up, in that I've assumed that "use-authentication", "authentication-user" and "authentication-password" would only introduced alongside the https_proxy suggestion. But since they actually already exist, my security concerns should have gotten into a separate bug :-( *sry*
Let's continue this in bug 747800. Leave this bug for its original purpose.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7514.