Stop caps from leaking to phishing-filter servers

davidsarah commented

2010-01-16 17:47:22 +00:00

Owner

Some phishing filters send URLs to a filter on some other machine. That's a bad idea and probably not very effective at preventing phishing, but they do it anyway. However, they strip query parts before sending it to the filter (according to Tyler Close and the web calculus documentation).

The webapi accepts URLs of the form <http://host:port/uri?uri>=..., but it redirects to an URL of the form <http://host:port/uri/>.... We should prefer to put the cap in the query, and we should probably also allow the shorter form <http://host:port/>?....

Some phishing filters send URLs to a filter on some other machine. That's a bad idea and probably not very effective at preventing phishing, but they do it anyway. However, they strip query parts before sending it to the filter (according to Tyler Close and the web calculus documentation). The webapi accepts URLs of the form `<http://host:port/uri?uri>=...`, but it redirects to an URL of the form `<http://host:port/uri/>...`. We should prefer to put the cap in the query, and we should probably also allow the shorter form `<http://host:port/>?...`.

tahoe-lafs added the

labels 2010-01-16 17:47:22 +00:00

tahoe-lafs added this to the undecided milestone 2010-01-16 17:47:22 +00:00

tahoe-lafs changed title from ~~Stop caps from leaking to phishing filters~~ to Stop caps from leaking to phishing-filter servers

2010-01-16 17:52:48 +00:00

davidsarah commented

2010-01-18 02:40:00 +00:00

Author

Owner

Replying to davidsarah:

[filters]Phishing strip query parts before sending it to the filter (according to Tyler Close and the web calculus documentation).

http://waterken.sourceforge.net/web-key/#browser_how

The webapi accepts URLs of the form <http://host:port/uri?uri>=..., but it redirects to an URL of the form <http://host:port/uri/>.... We should prefer to put the cap in the query, and we should probably also allow the shorter form <http://host:port/>?....

Actually that would cause a regression in #52, because the query part isn't taken into account when resolving relative URLs. I don't know how to avoid that problem. Perhaps the answer is simply to document that users should turn phishing filters off.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/8412): > [filters]Phishing strip query parts before sending it to the filter (according to Tyler Close and the web calculus documentation). <http://waterken.sourceforge.net/web-key/#browser_how> > The webapi accepts URLs of the form `<http://host:port/uri?uri>=...`, but it redirects to an URL of the form `<http://host:port/uri/>...`. We should prefer to put the cap in the query, and we should probably also allow the shorter form `<http://host:port/>?...`. Actually that would cause a regression in #52, because the query part isn't taken into account when resolving relative URLs. I don't know how to avoid that problem. Perhaps the answer is simply to document that users should turn phishing filters off.

davidsarah commented

2010-02-02 02:01:01 +00:00

Author

Owner

Attachment phishing-leak-diff.txt (50433 bytes) added

Document leakage of cap URLs via phishing filters in known_issues.txt

**Attachment** phishing-leak-diff.txt (50433 bytes) added Document leakage of cap URLs via phishing filters in known_issues.txt

phishing-leak-diff.txt

49 KiB

zooko commented

2010-02-02 04:29:22 +00:00

Author

Owner

Applied in changeset:8a43361aaa7f1201. Thank you!

davidsarah commented

2010-02-02 06:34:32 +00:00

Author

Owner

Since this is now documented as a [known issue]source:docs/known_issues.rst (with instructions on how to disable IE's phishing filter), I'm downgrading it to minor.

tahoe-lafs added

minor

and removed

major

labels 2010-02-02 06:34:32 +00:00

tahoe-lafs modified the milestone from undecided to 2.0.0

2010-02-23 03:12:47 +00:00

davidsarah commented

2010-03-13 02:49:25 +00:00

Author

Owner

Bumping back up to major, because it appears that Firefox 3 does have a phishing filter that is enabled by default. The Firefox prefs UI does a poor job of labelling this as what it is: it's enabled by the "Block reported attack sites" and "Block reported web forgeries" options in the Tools | Options... | Security tab. The filter server provider is Google's "Safe browsing API".

Bumping back up to major, because it appears that Firefox 3 does have a phishing filter that is enabled by default. The Firefox prefs UI does a poor job of labelling this as what it is: it's enabled by the "Block reported attack sites" and "Block reported web forgeries" options in the Tools | Options... | Security tab. The filter server provider is Google's ["Safe browsing API"](http://code.google.com/apis/safebrowsing/safebrowsing_faq.html).

tahoe-lafs added

major

and removed

minor

labels 2010-03-13 02:49:25 +00:00

davidsarah commented

2010-03-13 05:01:39 +00:00

Author

Owner

It appears from the specification that the "safe browsing API" protocol is not vulnerable in a way that would affect Tahoe. 32 bits of information about any particular URL is potentially leaked, but that would not be enough to either guess a cap or apply a cryptanalytic attack.

It appears from the [specification](http://code.google.com/p/google-safe-browsing/wiki/SafeBrowsingDesign) that the "safe browsing API" protocol is not vulnerable in a way that would affect Tahoe. 32 bits of information about any particular URL is potentially leaked, but that would not be enough to either guess a cap or apply a cryptanalytic attack.

tahoe-lafs added

minor

and removed

major

labels 2010-03-13 05:01:39 +00:00

zooko commented

2010-04-01 19:26:42 +00:00

Author

Owner

Here's a news story about an accusation that Google Chrome sends back a lot of information about the URL to a remote server:

http://arstechnica.com/microsoft/news/2010/03/microsoft-google-chrome-doesn-your-privacy-microsoft-google-chrome-doesnt-respect-your-privacy.ars

Here's a news story about an accusation that Google Chrome sends back a lot of information about the URL to a remote server: <http://arstechnica.com/microsoft/news/2010/03/microsoft-google-chrome-doesn-your-privacy-microsoft-google-chrome-doesnt-respect-your-privacy.ars>

davidsarah commented

2010-04-04 00:44:35 +00:00

Author

Owner

Replying to zooko:

Here's a news story about an accusation that Google Chrome sends back a lot of information about the URL to a remote server:

http://arstechnica.com/microsoft/news/2010/03/microsoft-google-chrome-doesn-your-privacy-microsoft-google-chrome-doesnt-respect-your-privacy.ars

I cannot reproduce the alleged behaviour of the address bar search at all using Chrome 5.0.366.2 dev. Perhaps it has been fixed since Chrome 3.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/907#issuecomment-116433): > Here's a news story about an accusation that Google Chrome sends back a lot of information about the URL to a remote server: > > <http://arstechnica.com/microsoft/news/2010/03/microsoft-google-chrome-doesn-your-privacy-microsoft-google-chrome-doesnt-respect-your-privacy.ars> I cannot reproduce the alleged behaviour of the address bar search at all using Chrome 5.0.366.2 dev. Perhaps it has been fixed since Chrome 3.

tahoe-lafs modified the milestone from 2.0.0 to 1.8.0

2010-04-12 20:18:54 +00:00

davidsarah commented

2010-06-21 03:18:27 +00:00

Author

Owner

The documentation about this in docs/known_issues.txt (now source:docs/known_issues.rst) was updated in changeset:15b65ae54b199345.

tahoe-lafs modified the milestone from 1.8.0 to 1.9.0

2010-08-09 22:18:46 +00:00

tahoe-lafs modified the milestone from 1.9.0 to eventually

2011-05-28 19:38:28 +00:00

Stop caps from leaking to phishing-filter servers #907