web-dev-qa-db-ja.com

ISPは、https経由でトレントWebサイトを閲覧したいことをどのように認識していますか。

それで、私は今日、新しいISPでhttpsを介してトレントWebサイトを閲覧しようとしていました。このページを開こうとすると、次の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>

さて、上のiframeタグには、私がアクセスしたWebサイトがhttp://アドレスであることが示されています。これはブラウザ側のリダイレクトの問題かもしれないと思いました。私はカールを試しました:

< 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>

さらに検索したところ、次のスレッドが見つかりました。

矛盾する応答があります。 SUスレッドは、httpまたはhttpsに関係なく、すべてのトラフィックをログに記録して中断できると述べています。一方、security.seは、SNIのために、ドメインレベルではなくIPレベルでトラフィックをブロックする必要があると述べています。私が開こうとしたウェブサイトはcloudflareプロキシ経由で提供されているので、CloudFlareの全範囲を禁止することになるとは思いません。

私の次の考えは、彼らが模倣するために独自のSSL証明書を挿入している可能性があるということでした MITM 、そして試しました

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

その出力は 返された貼り付けリンク で見ることができます。

私の質問は、HTTPS経由でページにアクセスしようとしたことをISPがどのようにして知るのかということです。


コメントで提案されているTracerouteの出力:

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  * * *

<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  * * *

したがって、ネットワークホップは明らかに異なります。


はい、ISPが提供するDNSを使用していました。 DNSエンドポイントを代わりにGoogleのもの(8.8.8.8および8.8.4.4)に変更し、カールを再度実行しようとすると、次のエラー(それらは互いに交互になります):

  1. curl:(35)エラー:1408F10B:SSLルーチン:SSL3_GET_RECORD:バージョン番号が間違っています
  2. curl:(56)SSL読み取り:エラー:1408F10B:SSLルーチン:SSL3_GET_RECORD:バージョン番号が間違っています、errno 0

PS:上記のスニペットには、私がアクセスしようとした実際のドメインが含まれています。そのデータも編集することを考えましたが、他の誰かが<domain-name>の実際の値を使用して動作を複製して説明できるかもしれません。だからそれに反対することにした。

2
hjpotter92

SNI over HTTPSを使用する場合、アクセスするURLは暗号化されないため、ISPはディープパケットインスペクションを使用してURLを判別できます(ただし、Webサイトのコンテンツは表示されず、ドメイン名のみが表示されます)。彼らがあなたのトラフィックをどのように見ているか。

この問題を回避したい場合は、ブロックされていないVPNサービスを自分で購入してください(または仮想サーバーを購入して独自のVPNを実行してください)

2
davidgo