1

I have a website with verified SSL. Everything is ok except one thing. In our country there is a mobile internet provider whose clients can't access our website. When they try to access my website through their mobile network, they can't. After their report I tried it myself, and same result. FTP, :80, SSL 10000 ports are OK. But only SSL 443 gives timeout. No access to my server. I have checked server logs, and found no log entries from those IP-s, so it means that their request doesn't reach my server. Just timeout after some seconds trying. I contacted the mobile provider's support, they investigated and assured me that they haven't blocked any port or hostname for my dedicated server. And one more strange fact: only 60-70% their clients can't connect to my ssl website, other 30-40% connect without any trouble. Is there any way to find the real reason of problem? telnet, ping, traceroute, dns and network structure checking didn't give any result. If the problem lies in the mobile provider's network, I have to prove it to them, else they reject their fault and advise me to check my server structure again.

Tilman Schmidt
  • 4,101
  • 12
  • 27
Elvin Haci
  • 111
  • 6
  • Test your domain in https://www.ssllabs.com/ssltest/. Or give us the domain so we can take a look. – ceejayoz Sep 14 '15 at 16:33
  • i have checked it. also you can: bilikli.net – Elvin Haci Sep 14 '15 at 16:40
  • See https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack and https://weakdh.org/sysadmin.html – Federico Sierra Sep 14 '15 at 16:50
  • Federico, do you believe that timeout error can be related with SSL3 Poodle attack problem? It seems that they don't have any relation. But if they do, please tell me – Elvin Haci Sep 14 '15 at 16:53
  • AFAIK unless only sslv3 was available it would not stop clients accessing the site, and then only some clients. As tls is available it would be selected (providing the browser supports tls) – Drifter104 Sep 14 '15 at 16:56
  • I'd assume that the connection attempts should leave some trace in the server log in that case. – Tilman Schmidt Sep 14 '15 at 16:57
  • Do you have any DDoS mitigation service in front of your web site by any chance? – dtoubelis Sep 15 '15 at 04:14
  • No dtoubelis, i don't. I haven't installed any additional services. I use default Debian+webmin_virtualmin install. – Elvin Haci Sep 15 '15 at 04:25

2 Answers2

1

Generalized Problems

The CRL specified in the trust chain is timing out. See SLL LABS. There is also an anchor problem. Some browser addons may block based on this. Both Mac OS X and IOS have options to block of the CRL/OCSP is not reachable.

You should reach out to Comodo or your SSL cert reseller and ask for help. Give them the SSL Labs link.

Mobile Provider Debugging

Mobile providers almost always go through their carriers proxy. This is usaully transparent to the mobile subscribers, as a cert is installed on their devices to trust the carrier's proxies. Their customers would have to contact that provider and ask for them to look into it. Their proxy logs will have more details. It is also possible the mobile provider has blocked access to your hosting provider, or vice versa.

Aaron
  • 2,859
  • 2
  • 12
  • 30
  • 1. It can't be related to browser. As same browsers(tested with 3-4 different devices and OS-es) successfully load my webpages via wifi or via another mobile providers' connections. The problem is only with one mobile provider. 2. They assured me that they haven't blocked my server. 30-40% of their clients can open my website without any trouble. But another 60-70% can't. + ftp, http and even ssl with 10000 port load OK. Only 443 is problematic. And in my server there is not any blacklist or blocking firewall. – Elvin Haci Sep 15 '15 at 07:13
  • At this point I believe you would need to debug the issue with a few of the people that can reproduce the problem. There are too many rabbit holes for us to venture down without more information, in my opinion. – Aaron Sep 15 '15 at 15:43
0

You may try to pinpoint the problem using tcptraceroute or tracetcp which will trace the route using TCP connection attempts on a given port, so they'll be sensitive to problems affecting only one port.

Also check whether the mobile provider in question has a mandatory or transparent web proxy in place. Some providers use this to compress graphics in order to reduce bandwidth consumption on the mobile network.

Tilman Schmidt
  • 4,101
  • 12
  • 27
  • When i try to traceroute ANY website with their mobile network, it gives such strange result: https://www.dropbox.com/s/3ok4h5gvwfmcoa0/Screenshot%20from%202015-09-14%2017%3A35%3A32.png?dl=0 With other connections i get normal trace reports. – Elvin Haci Sep 14 '15 at 17:08
  • This is a "regular" traceroute which works through UDP and as such is frequently blocked. The screenshot also shows that this mobile provider is employing CGNAT. So my advice stands: try tcptraceroute or tracetcp, and try to find out whether the mobile provider has a proxy in place. – Tilman Schmidt Sep 14 '15 at 17:14
  • They said me that "You can't use such tools as your mobile provider IP is dynamic. You should buy static IP to monitor traces." i am not sure if they are right or not. So, here is 2 results, first one is the result with my normal eth0 internet, second one is one with mobile internet. 1st one took 2-3 seconds, 2nd took 2-3 MINUTES(!). https://www.dropbox.com/s/iltac81alb3ivm8/Screenshot%20from%202015-09-15%2012%3A28%3A21.png?dl=0 – Elvin Haci Sep 15 '15 at 07:29
  • Well, "you can't use such tools" is obviously incorrect since you just did. :-) How to interpret the results is of course another matter. Unfortunately you didn't use `tcptraceroute` correctly. `-p` sets the *source* port but you need to set the *destination* port. Please repeat the test with destination port 443, ie. `tcptraceroute bilikli.net 443`. (without `-p`) – Tilman Schmidt Sep 15 '15 at 11:10
  • Opps sorry :) Here are the results: 1st with eth0 normal connection, 2nd with mobile connection: https://www.dropbox.com/s/co0bu0ahnfm9gba/Screenshot%20from%202015-09-15%2016%3A24%3A38.png?dl=0 – Elvin Haci Sep 15 '15 at 11:27
  • That sure looks like there is "something" at 10.10.10.4 in the mobile provider's network which is processing HTTP and HTTPS connections in a way that's different from simple routing. I would suspect a transparent web proxy. For additional data points you could check with `tcptraceroute bilikli.net 22` whether other ports are routed normally, and with `openssl s_client -connect bilikli.net:443` how an actual SSL connection is handled. But ultimately you'll have to show these results to the mobile provider and hope they'll accept them as evidence that the ball is in their field. – Tilman Schmidt Sep 15 '15 at 11:49
  • Thank you . i have sent mail to them with screenshots. Let's see what they will respond. Thank you for your help. I will be back when they respond. – Elvin Haci Sep 15 '15 at 12:08