Shadowsocks stopped working after switching on Automatic HTTPS Rewrites

#1

Dear all,
I am using VPS for my webpage (boyan.press) and also for Shadowsocks ( as VPN connection), both works fine until I switched on “Automatic HTTPS Rewrites” in Crypto settings… the SS (shadowsocks) does not work any more, am I right by guessing it has to do with HTTPS rewrites?
If so, is there any way to fix/ reverse it?

Boyan

0 Likes

#2

Rewriting happens on the server side, so as long as your SOCKS application enables you access to other SSL sites (e.g. https://www.google.com) - your site through Cloudflare shouldn’t be different…

I am of course assuming that the SOCKS is what you run on your PC, not on the server. If it’s more complicated, perhaps I did not understand your topology… can you elaborate on how exactly is it set up?

Also, when it “doesn’t work”, what do you see?

0 Likes

#3

Hi Shimi,
Thanks for the response, I have set up my webpage (boyan.press) and Shadowsocks Server on the same VPS, therefore using the same IP address. Both are working fine before I switched on the Automatic HTTPS Rewrites option under Crypto. I did this because I hoped my website could look like a “secure” site. But then I found Shadowsocks stopped functioning both on my PC and Android Phone (I was using Shadowsocks as VPN to access the sites blocked in my region), which gave me the reason to doubt some change had happened on the VPS,(to allow the site being called “safe” site)

Boyan

0 Likes

#4

Unfortunately I do not understand the situation better with your latest response, so I’ll try to explain from the other side what does this do, etc.

Normally, when you enable a site to work as HTTPS, Cloudflare just proxies the site over a secure connection (to Cloudflare, Cloudflare presenting their own TLS certificate to the users of the site). This works if you go to https://boyan.press and your domain goes through Cloudflare, and the DNS record in Cloduflare’s configuration is set to proxy all requests (orange cloud next to the relevant DNS record).

The way this works is by Cloudflare serving in the DNS response their IP, instead of your servers’ IP, and when someone browses to your site, Cloudflare on the background connects to your server, either securely or not (latter option available only if your SSL mode is set to “Flexible”), and whatever it gets in response to the background request, it returns to the originating client.

So what does “Automatic HTTPS Rewrites” do? Well, sometimes people are unable, or unwilling, to make sure that all the references to other files (images, CSS, JS) within their site are either relative to the current path (like …/images/file.png or /file.png), so they’ll load at the same protocol as the whole page was loaded (HTTP if the page was HTTP, and HTTPS if it was HTTPS), and they have internal links that start with “HTTP” even if the page is loaded as “HTTPS”. When that happens, the page is said to have “mixed content”, which is a security issue, and as such will display with a broken padlock. There are two solutions to that issue - either fixing the links to be either relative or explicitly begin with “https://”, OR, for those who can’t or can’t be bothered, Cloudflare has the option of “Automatic HTTPS Rewrites”, which basically means that once your HTML pages pass through Cloudflare’s network, they will, on-the-fly, make those corrections in the URLs, and convert “http://” to “https://” for any URL that is under your domain. For other domains they can’t do that because they have no idea if the other domains support SSL (yours, they do know, after all, they’re serving your domain through SSL…). So for any remote content, you should still have Mixed-Content even with this on.

Now to your site:

Your domain, assuming it is “boyan.press” like you say, does not even have Cloudflare’s servers set up on the domain WHOIS record. The DNS servers for this domain right now are DNS1.REGISTRAR-SERVERS.COM and DNS2.REGISTRAR-SERVERS.COM. This means that there’s NO WAY that any of your traffic passes through Cloudflare, because the very first prerequisite - having Cloudflare control the traffic by pointing the nameservers for the domain to them, is not set up. You were told to set it up when you added the domain to Cloudflare (and probably also in a follow-up e-mail).

Since your traffic does not fly through Cloudflare network, it doesn’t matter what change you’ll configure in Cloudflare’s dashboard - Cloudflare cannot affect your traffic until it is pointed to them; As such, the change you made (“Automatic HTTPS Rewrites”) had no effect on anything.

2 Likes

#5

Are you accessing using domain name or IP address?
For SS/SSR, try using IP, not domain name.

0 Likes

#6

Hi Shimi,
Thanks again! Apologies! I should have mentioned that I had removed two CloudFlare nameserver addresses from ISP in attempts to looking for the reason of the problem. I also thought that “now the requests are not passing CloudFlare, then the ShadowSocks at least should work.” But to my surprise, even after 24 hours (then days), the SS clilent on both PC and Android remained zero data flow when connected. (Sorry again about I didn’t mention that, because I did not want to make a too long description of the problem. )
By the way, when I was using “flexible” SSL without using “Automatic HTTPS Rewrite”, SS (Shadowsocks) clients are functioning.

0 Likes

#7

Thank you dawnfantasy,
I did use IP address in SS client on both of PC and Android phone. The system on VPS is Ubuntu 14, and I restarted 2 times the SS server to make sure it was running on the server end.

0 Likes

#8

If you were using the IP address of the server in your SS client, then again you did not pass through Cloudflare - Cloudflare cannot control random traffic on the Internet, only what’s directed at them by using nameservers. By the way, there’s no reason to switch nameservers to stop traffic from flying through Cloudflare - merely clicking the orange cloud to make it grey does that (and it’s much easier to switch back and forth)

The only thing I can think of is that maybe the VPN you used were listening on port 443 (not a good idea) and when Cloudflare tried to connect to it, something was broken (due to a bug in SS; that should never happen). If that’s the case, I would switch SS to listen on another port. You’ll want your web server to also listen on 443 (with HTTPS) anyway, so you could have secure traffic end-to-end, not just client to Cloudflare, but also Cloudflare to you.

Anyway, I think you should use tools like ‘netstat -pltn’ on your server to verify that SS is listening, and perhaps tcpdump on the server to capture the traffic to see what’s going on when you try to connect from your PC/Android. Either way, if you’re using IP (and not a hostname which is your domain! because that’s something Cloudflare DOES change in hostnames that has orange cloud next to them), Cloudflare simply cannot interfere; after all the domain you pass through them is just not involved in any way…

1 Like

#9

Thanks shimi, that is good advice and indeed give me the direction to continue to research… I will report when I get somewhere.

0 Likes

closed #10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

0 Likes