Então, eu estava tentando navegar em um site de torrent por link com um novo ISP hoje. Quando tentei abrir a página, ela abriu o seguinte conteúdo html
<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>
Agora, na tag iframe acima, o site que visitei era http:// address. Eu pensei que isso poderia ser um problema de redirecionamento do lado do navegador. Eu tentei enrolar:
< 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>
Pesquisei mais e encontrei os seguintes tópicos:
que têm respostas conflitantes. O segmento SU diz que eles podem registrar e interromper todo o tráfego, independentemente de http ou https; enquanto a segurança menciona que, por causa do SNI, seria necessário bloquear o tráfego em nível IP e não em nível de domínio. Como o site que tentei abrir é exibido por meio do proxy do cloudflare, não acho que eles estariam proibindo toda a extensão do CloudFlare.
Meu próximo pensamento foi que eles podem estar injetando seus próprios certificados SSL para imitar o MITM. e tentou$ openssl s_client -showcerts -servername <domain-name> -connect <domain-name>:443 2>&1 | curl -F 'sprunge=<-' http://sprunge.us
cujo resultado pode ser visto no link para colar retornado .
A minha pergunta é: como é que o meu ISP sabe que tentei visitar a página através de HTTPS?
Traceroute outputs como sugerido nos comentários:
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 * * *
e para o <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 * * *
Assim, os saltos da rede são claramente diferentes.
Sim, eu estava usando o DNS fornecido pelo ISP. Alterar meus pontos de extremidade do DNS para os do Google (8.8.8.8 e 8.8.4.4) e tentar fazer um curl novamente resulta nos seguintes erros (eles alternam entre si):
- curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
- curl: (56) SSL read: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number, errno 0
PS: os snippets acima têm o domínio real que tentei visitar. Pensei em redigir esses dados também, mas talvez outra pessoa possa replicar e explicar o comportamento usando valores reais de <domain-name> . Então decidimos contra isso.
Quando você usa SNI por HTTPS, o URL para o qual você está indo não é criptografado, então o ISP pode determiná-lo usando inspeção profunda de pacotes (mas eles não podem ver o conteúdo do site, apenas o nome de domínio) - e é assim que eles veem seu tráfego.
Se você quiser contornar este problema, compre um serviço VPN que não esteja bloqueado (ou compre um servidor virtual e execute sua própria VPN)
Tags networking security firewall https isp