#2268 Force Plugins to Obey Proxy Settings

[Photon Metrication]

Hi there! Over in an issue on GitHub for the Favicon Downloader plugin, a few of us determined to our surprise that the plugin does not obey the proxy rules set by the user in the KeyPass advanced config. Instead, it seems to just bypass it entirely and use the regular system internet settings.

Favicons are not a mission-critical security issue, but the fact that any given portion of a program might or might not obey the internet access rules you've laid out is. Bosses watching your internet usage, countries where website access is dangerous, people not wanting websites themselves to know they are using keypass, or even wanting to route all keypass traffic through a proxy to avoid any of the aforementioned knowing you're using it. These are just off the top of my head; there are any number of reasons a person wouldn't want KeePass accessing every web site for which you have a membership.

It is an extremely basic assumption that if you set a proxy rule for internet access in a program, another piece of that program will not simply ignore it. Open-source projects with differnet people programming plugins obviously compliates this, but does not change the correct behavior.

Can a restriction be placed in KeePass to force all plugins to use the configured proxy?

I understand some bypass this for various reasons, but this should be an option in the plugin, or at the very laest, something the user is warned about. The comparative lack of importance of favicons aside, this is a broad security issue that should be corrected, addresssed, and explicated to uers. Thanks!

[KeePass-Favicon-Downloader: Issue 15: Add Proxy Support]

[David Lechner]

Plugins can basically do whatever they want. There is no way for KeePass to restrict them. The only thing you could do is make a guide of recommendations for plugins and hope that the plugin authors follow them.

[Dominik Reichl]

I agree with David. The plugin architecture has been designed such that plugins run with the same rights as KeePass and have access to basically all KeePass data (which allows powerful plugins); KeePass cannot restrict the way how plugins communicate.

KeePass already features a convenient way for Internet access with all the user's settings (including proxy configuration), through the IOConnection class; plugins just need to use it.

Best regards,
Dominik

[darkdragon]

If you want plugins to use KeePass' proxy settings, you should make KeePassLib.Serialization.IOConnection.GetWebProxy() public.

I added a corresponding patch: https://sourceforge.net/p/keepass/patches/107/

[Dominik Reichl]

No, this method intentionally is private. Plugins should use the public methods of the IOConnection class. With this, proxy settings and other connection-related settings (like the option for forcing to accept invalid SSL certificates) are used.

Best regards,
Dominik

[darkdragon]

Can you publish some example code?

Most of the solutions which come to my mind seem like a lot of duplicate code. Most plugin developers just want to retrieve some data from the internet and do not care how it works. So an easy solutions is much appreciated...

[Dominik Reichl]

Sure, here's an example that downloads the http://keepass.info/help/base/cmdline.html help page to a byte[]:

IOConnectionInfo ioc = IOConnectionInfo.FromPath(
    "http://keepass.info/help/base/cmdline.html");
byte[] pbData = IOConnection.ReadFile(ioc);

If you prefer to get a Stream to read the data (incrementally), use the IOConnection.OpenRead method instead.

Best regards,
Dominik

[darkdragon]

Where can I find / How can I generate documentation for these classes?
Does it support redirects (HTTP 302 and META)?

[Dominik Reichl]

The public methods of the IOConnection class should be obvious, but if you're interested in what they're doing internally, you can have a look into the IOConnection.cs file.

For HTTP requests, the HttpWebRequest class of the .NET Framework is used, which does support redirects (the AllowAutoRedirect property is true by default). I'm not sure what you mean by "META".

Best regards,
Dominik

[darkdragon]

I mean the HTTP meta tag to specify a redirect location:
<meta http-equiv="refresh" content="0;url=http://example.com/">

How can I set HttpWebRequest properties (namely UserAgent, CookieContainer, Accept, Headers)?
Do I just have to add them via IOConnection.Properties.Set()? What about non-string attributes like CookieContainer? What about the Headers list?

[Dominik Reichl]

I'm not sure, but I think that the HttpWebRequest class supports 3xx HTTP redirects only; it probably doesn't parse HTML files.

The user agent for a HTTP request can indeed be set via the Properties of an IOConnectionInfo: call the Set method with IocKnownProperties.UserAgent and the user agent string as parameters.

Why do you need the other properties? Although I can imagine a way how your plugin can set these, it'd be rather complicated (similar to my IOProtocolExt plugin).

Best regards,
Dominik

[darkdragon]

Accept to set priorities of content-types
Header for language preferences
CookieContainer Some sites require Cookies. They need to set a cookie, redirect and then read the cookie.

Further, how can I process the whole response?
Precisely, I need status-code, content-type and location after redirects.

[Dominik Reichl]

The IOConnection class does not directly provide the whole response to callers. It typically only provides the content, if it can be retrieved successfully. In general, the IOConnection class has been designed to easily download and upload files, without exposing protocol details.

There is a way how callers can process the whole response with IOConnection (by implementing a custom protocol handler, like the IOProtocolExt plugin), but realizing this would be more complicated than using .NET's HTTP classes. I don't know what your plugin is supposed to do, but if you really need such low level HTTP processing, using .NET's HTTP classes is probably the better way to go.

If you're going to use .NET's HTTP classes and need the proxy information that the user entered in KeePass: you can query it from the configuration via the Program.Config.Integration.Proxy* properties.

Best regards,
Dominik