Neil Harris wrote:
Ilmari Karonen wrote:
Tim Starling wrote:
There's a simple, non-invasive way to determine the IP address of an AOL client, which I've been looking into recently: use SSL sign-on. Make the login links go to https://secure.wikimedia.org, and redirect them back when they're logged in. SSL requests skip the proxy cluster. We would store the IP address at login in the session, and then continue to use that IP address for the user after they return to the unsecured part of the site. And of course there are security benefits for all users.
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
-- Neil
And, on re-reading, perhaps for AOL users only, the "my talk page" link could be an SSL link which would then auto-redirect to the appropriate IP address talk page, thus eliminating any need for a cookie.
A question: does the Foundation have a PKI certificate for the wikipedia.org domain?
-- Neil
Neil Harris wrote:
Neil Harris wrote:
Ilmari Karonen wrote:
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
It won't work for all of them, since some may tunnel SSL traffic through the proxy as well. There's very little we can do in that case without help from the user, and possibly not even then.
(From a technical viewpoint, the hardest situation is not a proxy, but a large number of users on RFC-1918 addresses behind a single NAT router. There's no way we can discover their internal IP address, and even if we could, it'd be all but useless to us.)
And, on re-reading, perhaps for AOL users only, the "my talk page" link could be an SSL link which would then auto-redirect to the appropriate IP address talk page, thus eliminating any need for a cookie.
Unregistered users don't _have_ a "my talk page" link, so the point is moot. They do, however, get those "You have new messages" notices, which is what I proposed the cookie for. I do agree with you that many if not most special pages, including Special:Mytalk, should also be served over SSL for those users.
On Mon, Mar 27, 2006 at 07:16:41PM +0300, Ilmari Karonen wrote:
(From a technical viewpoint, the hardest situation is not a proxy, but a large number of users on RFC-1918 addresses behind a single NAT router. There's no way we can discover their internal IP address, and even if we could, it'd be all but useless to us.)
True, but, rose.net notwithstanding, having multiple users not within ithe same administrative span of control be behind the same NAT is Not Best Practice anyway, and there's a limit, I think, to how bad of other people's practices any given site operator should be required to make allowances for.
Cheers, -- jra
Ilmari Karonen wrote:
Neil Harris wrote:
Neil Harris wrote:
Ilmari Karonen wrote:
If that really works, couldn't we just make AOL users _edit_ over SSL? Have http links with action=edit (or action=submit) redirect to an https URL if fetched from an AOL proxy.
This would break talk message notification for unregistered AOL users, but I suppose we could use a cookie for that. After all, talk pages are public, so there's no security issue even if someone fakes the cookie.
Now, that's an *excellent* idea.
1 the SSL overhead will be low, because edits are a tiny fraction of the overall traffic 2 If we only SSL the form submission, this limits the SSL overhead even further. 3 AOL browsing will still be proxied, so page-view load will not increase 4 AOL _browsing_ will still be completely anonymous 5 AOL IP editors will still be as anonymous as any other IP editors 6 Dynamic IP assignment should not be any more or less of a problem than with other ISPs
Are there any reasons why this should not work? Perhaps this could be the solution for all non-XFF-friendly ISPs?
It won't work for all of them, since some may tunnel SSL traffic through the proxy as well. There's very little we can do in that case without help from the user, and possibly not even then.
(From a technical viewpoint, the hardest situation is not a proxy, but a large number of users on RFC-1918 addresses behind a single NAT router. There's no way we can discover their internal IP address, and even if we could, it'd be all but useless to us.)
I agree: NAT, or transparent proxying without XFF is the worst case. However, I suspect that AOL users _do_ in general get assigned real routable IP addresses, it's just that their web traffic goes by default through transparent proxies.
The AOL FAQ for this (at http://webmaster.info.aol.com/proxyinfo.html) says:
"AOL members are assigned a dynamic IP address that is used for all requests not handled by the AOL proxy system. These IP addresses can be used to identify AOL members making requests to your site."
How about doing SSL via a non-standard port, which will miss the proxies _if_ the transparent proxying simply uses packet filtering at the network side to detect proxyable traffic?
For example:
https://en.wikipedia.org:32//w/index.php?title=Example article&action=submit
(32 being an officially unassigned port number)
Come to that, if they're just packet-filtering off the proxyable traffic, we may not even need to bother with the https: -- just use a non-standard port number for _all_ form submissions from AOL members, and set a cookie with that address so they can see their messages.
Of course, we can theorize forever about what AOL's network does or does not do... some actual experiments would be likely to find out what the actual state of affairs is.
Incidentally, if you go to https://en.wikipedia.org/, you get a slightly surprising result...
-- Neil
Neil Harris wrote:
How about doing SSL via a non-standard port, which will miss the proxies _if_ the transparent proxying simply uses packet filtering at the network side to detect proxyable traffic?
For example:
https://en.wikipedia.org:32//w/index.php?title=Example article&action=submit
(32 being an officially unassigned port number)
How about we worry about that when we actually see such a case?
Come to that, if they're just packet-filtering off the proxyable traffic, we may not even need to bother with the https: -- just use a non-standard port number for _all_ form submissions from AOL members, and set a cookie with that address so they can see their messages.
I tried that already, I sent an AOL user to my webserver on port 81, the request came via the proxy. I assume traffic is marked proxyable by the AOL client. Either that or 81 is filtered in the same way as 80, I didn't try it with a random port.
Of course, we can theorize forever about what AOL's network does or does not do... some actual experiments would be likely to find out what the actual state of affairs is.
I seem to be ahead of you here. SSL works, HTTP port 81 doesn't.
Incidentally, if you go to https://en.wikipedia.org/, you get a slightly surprising result...
Connection refused? Is that surprising?
-- Tim Starling
Neil Harris wrote:
How about doing SSL via a non-standard port, which will miss the proxies _if_ the transparent proxying simply uses packet filtering at the network side to detect proxyable traffic?
From reading between the lines, it seems AOL does _not_ use packet filtering; they've just configured their standard browser to use their proxies by default. This means that:
* Installing a different browser bypasses the proxies.
* HTTPS bypasses the proxies.
* Changing the browser configuration _might_ bypass the proxies (unless they've locked it down somehow; I don't really know).
* Using a nonstandard port for HTTP does _not_ bypass the proxies.
Perhaps a bit of a tangent, but I believe some AOL users have discovered a separate range (172-something, I believe) which is semi-static (at least, static for a single session, rather than changing in whatever way the others do) that can be utilized by avoiding the AOL browser, and instead using an "after-market" package (like Firefox, I assume). I'm sure we could find a description by searching en.wiki
Essjay
http://en.wikipedia.org/wiki/User:Essjay Wikipedia:The Free Encyclopedia http://www.wikipedia.org/
Ilmari Karonen wrote:
Neil Harris wrote:
How about doing SSL via a non-standard port, which will miss the proxies _if_ the transparent proxying simply uses packet filtering at the network side to detect proxyable traffic?
From reading between the lines, it seems AOL does _not_ use packet filtering; they've just configured their standard browser to use their proxies by default. This means that:
Installing a different browser bypasses the proxies.
HTTPS bypasses the proxies.
Changing the browser configuration _might_ bypass the proxies (unless
they've locked it down somehow; I don't really know).
- Using a nonstandard port for HTTP does _not_ bypass the proxies.
Essjay wrote:
Ilmari Karonen wrote:
From reading between the lines, it seems AOL does _not_ use packet filtering; they've just configured their standard browser to use their proxies by default. This means that:
- Installing a different browser bypasses the proxies.
- HTTPS bypasses the proxies.
- Changing the browser configuration _might_ bypass the proxies (unless
they've locked it down somehow; I don't really know).
- Using a nonstandard port for HTTP does _not_ bypass the proxies.
Perhaps a bit of a tangent, but I believe some AOL users have discovered a separate range (172-something, I believe) which is semi-static (at least, static for a single session, rather than changing in whatever way the others do) that can be utilized by avoiding the AOL browser, and instead using an "after-market" package (like Firefox, I assume). I'm sure we could find a description by searching en.wiki
That's what I wrote above, didn't I? Specifically, the ranges are listed at http://webmaster.info.aol.com/proxyinfo.html.
Sorry, I don't speak tech very well, so I didn't catch that it was the same. (I caught the part about using a different browser, that's what reminded me, but the HTTPS part lost me.) : - )
Anywho, great minds and all that....
Essjay
http://en.wikipedia.org/wiki/User:Essjay Wikipedia:The Free Encyclopedia http://www.wikipedia.org/
Ilmari Karonen wrote:
Essjay wrote:
Ilmari Karonen wrote:
From reading between the lines, it seems AOL does _not_ use packet filtering; they've just configured their standard browser to use their proxies by default. This means that:
- Installing a different browser bypasses the proxies.
- HTTPS bypasses the proxies.
- Changing the browser configuration _might_ bypass the proxies (unless
they've locked it down somehow; I don't really know).
- Using a nonstandard port for HTTP does _not_ bypass the proxies.
Perhaps a bit of a tangent, but I believe some AOL users have discovered a separate range (172-something, I believe) which is semi-static (at least, static for a single session, rather than changing in whatever way the others do) that can be utilized by avoiding the AOL browser, and instead using an "after-market" package (like Firefox, I assume). I'm sure we could find a description by searching en.wiki
That's what I wrote above, didn't I? Specifically, the ranges are listed at http://webmaster.info.aol.com/proxyinfo.html.
wikitech-l@lists.wikimedia.org