hehe numes :) you seem so worried but form my point of view it's not so much bug.
i will surely readly try to understand why the behaviour, (funny) is to redirect to a wrong hidden service different from the one requested. by the way apart of solving the redirect to a wrong hidden issue, making it working properly won't be so easy. infact using tor2web for HTTPS is something that is totally different from the tor2web natural address translation that we apply since ever. let me clarify: when a user goes for both http:// and https:// antani.tor2web.org, tor2web opens a Tor socks to antani.onion:80 so what is happening now is that when accessing https:://facebook.tor2web.org tor2web opens a Tor sock to facebook.onion:80 that appear to google as the user is using HTTP, then facebook provide the user a redirect to a different port (https/443) and we provide the url to the user; but the next request by the user will be the same https:://facebook.tor2web.org and natural code flow of tor2web will continue to be opening the 80, not the 443. so we have to take a decision and all are not correct and contains problems as for what they fix they open other bugs: 1) instead of opening automatically a socksv5 to 80, portknock the 443, if it works open the 443 and use it; (and we can cache this to continue to use the 443, but what if an hidden service opens 80 and 443 for differnt reasons? wi will end always serving the 443 2) automatically try to follow the redirect Location: https://facebook.onion in a transparent way for the user. also this opens to possibility for tor2web to be forced to reload reload reload funny stuff attacking it (that will need to managed with a funny cylcle counter) this and other concern as currently stopping me to proceed fixing the issue. what do you think? maybe we wanna share this thinking on the tor-dev mailing list ciao! evilaliv3 _______________________________________________ Tor2web-talk mailing list [email protected] http://lists.globaleaks.org/mailman/listinfo/tor2web-talk
