Can't access to website Iran ISP

Help
1

Our users reported that they can’t access to site over HTTPS , from Iran’s ISP’s especially Cellular operators , But they can access without HTTPS ,
We’ve checked and debugged and found that the TLS handshake process Only pass the second one and then connection closes
I know not matter which server config we use , but
Server in Nginx , Certificate LE
and add this one that we have tested with another domain on same server IP and configuration and affected users can access this domain over HTTPS

Is there anything else that we can check ?

2

You might want to look at this thread

to see if you can find any similarities to your situation (or if any of the people who participated in that thread would like to take a look at your situation for comparison).

1 Like
3

Yes friend , I have read all other threads like this , but all of them finished and closed without any solution :frowning:

4

I’m sorry to hear that! Often if the explanation is intentional network censorship, your options in response are very limited. :frowning:

1 Like
5

As I know this is not so much related to censorship, because censored domain usually redirected to another page that warn user that this Domain or IP was blocked , but in this case we Have ping to domain , we have Traceroute success reply , but the only thing we have issue is the Handshake process , I want to know if is there any way to change something here to solve this

6

A hostile network that is manipulating traffic flows is indistinguishable from censorship. It doesn’t really matter about the intent or whether your site is “collateral damage”. There’s nothing that anybody on this forum can do to fix it - you have to hide your traffic (TLS isn’t really “hidden”) or choose a different network path.

FWIW from my investigation in that linked thread, I’m 99% sure it’s intentional manipulation even if it’s not clear why.

2 Likes
7

OK , So I think it’s better to hope a world without borders and censorship for each other and wait for some beautiful day , and for now it is better we buy a piece of farm land and make a small farm for growing potato’s and carrots , this way finally we have a warm soup at the end of the day :slight_smile:

2 Likes
8

Can you share some of those specific details?

Also, perhaps client and server can be checked to ensure both are capable of similar encryption.

1 Like
9

This is the only report that we have:
* Rebuilt URL to: https://www.Domain.com/
* Trying xxx.xx.xxx.xx…
* TCP_NODELAY set
* Connected to www.Domain.com (xxx.xx.xxx.xx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):

10

This information is not really useful to solve the problem.

11

I’m agree with you . Our solution to solve this problem is some where outside the web
Have a good day

1 Like
12

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