2

So, I was trying to browse a torrent website over https with a new ISP today. When I tried to open the page, it opened the following html content

<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0" /><style>body{margin:0px;padding:0px;}iframe{width:100%;height:100%}</style><iframe src="http://www.airtel.in/dot/?dpid=1&dpruleid=3&cat=107&dplanguage=-&url=http%3a%2f%2f1337x%2eto%2f" width="100%" height="100%" frameborder=0></iframe>

Now, in the iframe tag above, it says the website I visited was http:// address. I thought this might be a browser side redirect issue. I tried curl:

< HTTP/2 200 
< date: Tue, 24 Oct 2017 11:33:25 GMT
< content-type: text/html
< set-cookie: __cfduid=d1b602f2b9f113fd92311ca7bcd516e281508844805; expires=Wed, 24-Oct-18 11:33:25 GMT; path=/; domain=.1337x.to; HttpOnly
< pragma: no-cache
< cache-control: no-cache
< server: cloudflare-nginx
< cf-ray: 3b2c9f03bf0e2fed-MAA
< 
{ [323 bytes data]
* Curl_http_done: called premature == 0

100   323    0   323    0     0    349      0 --:--:-- --:--:-- --:--:--   349
* Connection #0 to host 1337x.to left intact
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0" /><style>body{margin:0px;padding:0px;}iframe{width:100%;height:100%}</style><iframe src="http://www.airtel.in/dot/?dpid=1&dpruleid=3&cat=107&dplanguage=-&url=http%3a%2f%2f1337x%2eto%2f" width="100%" height="100%" frameborder=0></iframe>

I searched more, and found the following threads:

which have conflicting replies. The SU thread says that they can log and interrupt all traffic, irrespective of http or https; whereas the security.se mentions that because of SNI, it would require them to block the traffic at IP level and not domain level. Since the website I tried to open is served via cloudflare proxy, I do not think that they would be banning whole of CloudFlare ranges.

My next thought was that they might be injecting their own SSL certificates to imitate the MITM, and tried

$ openssl s_client -showcerts -servername <domain-name>  -connect <domain-name>:443 2>&1 | curl -F 'sprunge=<-' http://sprunge.us

whose output can be seen at the returned paste link.

My question is, how does my ISP know that I tried to visit the page over HTTPS?


Traceroute outputs as suggested in comments:

traceroute to google.com (216.58.197.78), 30 hops max, 60 byte packets                                                                     
 1  domain.name.dlink.com (192.168.0.1)  3.053 ms  4.309 ms  4.414 ms                                                                                  
 2  60.243.246.225 (60.243.246.225)  5.519 ms  5.613 ms  5.629 ms
 3  202.88.156.1 (202.88.156.1)  6.169 ms  6.184 ms  7.783 ms
 4  202.88.156.70 (202.88.156.70)  5.914 ms  6.009 ms  6.024 ms
 5  202.88.156.61 (202.88.156.61)  6.412 ms  6.497 ms  7.096 ms
 6  202.88.157.29 (202.88.157.29)  14.422 ms  9.700 ms  10.318 ms
 7  202.88.152.69 (202.88.152.69)  10.199 ms  10.240 ms  10.187 ms
 8  209.85.252.188 (209.85.252.188)  10.149 ms  10.146 ms  12.658 ms
 9  209.85.250.67 (209.85.250.67)  10.415 ms  10.432 ms  10.292 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *

and for the <domain-name>:

traceroute to <domain-name> (104.31.17.3), 30 hops max, 60 byte packets
 1  domain.name.dlink.com (192.168.0.1)  1.077 ms  1.244 ms  1.247 ms
 2  60.243.246.225 (60.243.246.225)  2.131 ms  2.216 ms  2.232 ms
 3  202.88.156.1 (202.88.156.1)  4.674 ms  4.802 ms  4.800 ms
 4  202.88.156.70 (202.88.156.70)  4.740 ms  4.660 ms  4.727 ms
 5  202.88.156.61 (202.88.156.61)  4.796 ms  4.865 ms  4.828 ms
 6  10.241.1.6 (10.241.1.6)  4.806 ms  2.831 ms  3.001 ms
 7  10.240.254.100 (10.240.254.100)  2.007 ms  2.088 ms  2.126 ms
 8  10.240.254.1 (10.240.254.1)  4.330 ms  4.210 ms  4.556 ms
 9  10.241.1.1 (10.241.1.1)  3.193 ms  2.947 ms  3.289 ms
10  219.65.110.177.static-bangalore.vsnl.net.in (219.65.110.177)  4.799 ms 219.65.110.181.static-bangalore.vsnl.net.in (219.65.110.181)  5.675 ms 125.16.134.109 (125.16.134.109)  17.859 ms
11  * 182.79.255.149 (182.79.255.149)  41.278 ms 182.79.188.188 (182.79.188.188)  45.378 ms
12  103.29.44.3 (103.29.44.3)  32.153 ms  32.805 ms *
13  * * *
14  * * ae31-100-xcr1.mlu.cw.net (213.38.254.33)  134.952 ms
15  if-ae-13-2.tcore1.SVW-Singapore.as6453.net (180.87.36.83)  43.144 ms if-ae-3-3.tcore2.CXR-Chennai.as6453.net (180.87.36.6)  43.108 ms *
16  if-ae-6-2.tcore2.SVW-Singapore.as6453.net (180.87.37.14)  41.229 ms cloudflare-ic-306776-mno-b2.c.telia.net (213.248.94.54)  171.588 ms  172.281 ms
17  * * *
18  * * *
19  * 120.29.214.90 (120.29.214.90)  41.753 ms *
20  * * *
21  * * *
22  * * *

So, the network hops are clearly different.


Yes, I was using the ISP provided DNS. Changing my DNS endpoints instead to the Google ones (8.8.8.8 and 8.8.4.4), and trying to do a curl again results in the following errors (they alternate between each other):

  1. curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
  2. curl: (56) SSL read: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number, errno 0

PS: The snippets above do have the actual domain I tried to visit. I thought of redacting that data too, but maybe someone else can replicate and explain the behaviour using actual values of <domain-name>. So decided against it.

  • 2
    The answer is either SNI as explained in the security stack exchange answer you linked, and/or that you're using their DNS servers. – Twisty Impersonator Oct 24 '17 at 12:06
  • @TwistyImpersonator Changing DNS results in a new error now. See updated post – hjpotter92 Oct 25 '17 at 3:57
  • @Biswa Added output for traceroutes above – hjpotter92 Oct 25 '17 at 3:57
  • Does changing DNS works to surf internet? – Biswapriyo Oct 25 '17 at 4:56
  • @Biswa Changing DNS does not affect browsing other websites. Just the <domain> returns SSL3 error mentioned above. – hjpotter92 Oct 25 '17 at 4:57
2

When you use SNI over HTTPS, the URL that you are going to is not encrypted, so the ISP can determine it using deep packet inspection (but they can't see the content of the website, only the domain name) - and this is how they are seeing your traffic.

If you want to get around this problem, buy yourself a VPN service which is not blocked (or buy a Virtual Server and run your own VPN)

  • ok, but how are they able to inject custom response in that case? At best (in my understanding) they can drop all packets! – hjpotter92 Oct 25 '17 at 6:12
  • 1
    I imagine that they are intercepting the negotiation of the https site and injecting the backets at that stage. Simplifying somewhat - Browser connects to IP address and says (in plain text) I want to talk to encrypted site XXX. ISP responds with HTTP payload instead of server responding with OK, Here is that sites public key, lets negotiate a secure connection. – davidgo Oct 25 '17 at 6:29
  • but the SSL handshake was successful throughout. Simply put, here is that site's public key, lets negotiate a secure connection. The client will say okay, here is the session token, encrypted with your public key, decrypt with your private key and we can talk. How is the ISP going to do that? – hjpotter92 Oct 25 '17 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.