web-dev-qa-db-ja.com

この「キャプティブポータル」はHTTPリクエストをどのようにインターセプトおよび操作するのですか？

無料のWifiサービスを使用してインターネットにアクセスすることがあります。
このようなサービスのほとんど/すべてのプロバイダーと同様に、このサービスは キャプティブポータル を採用しています。そのため、ブラウザでHTTPリクエスト（Webページのリクエスト）を行おうとして、ネットワーク上で認証されていない場合、 "Welcome to Free"というページしか表示されません。 -wifiネットワーク。ここに私たちの用語などがあります... "
無料のwifiのためにサービスを悪用することに興味はありません-このサービスを使用するときに公開/安全でない情報（HTTPトランザクション）と、システムに加えられる永続的な変更（つまり非表示）を知りたいブラウザのCookie（匿名ホストを使用）。
それで、私は彼らのwifiアクセスポイントに接続しました。その時点で、彼らは私のコンピューターにIPアドレスやDNSサービスなどを割り当てました。

$ nmcli device show wlp2s0
IP4.ADDRESS[1]:                         192.168.12.199/22
IP4.GATEWAY:                            192.168.12.1
IP4.ROUTE[1]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]:                             123.123.xxx.xxx
IP4.DNS[2]:                             123.123.xxx.xxx

次に、HTTPリクエストを試行します。まだ承認されていないときに「Webページを参照」してみてください。 （HTTPであるため、この要求/応答は暗号化されず、要求を処理するサーバーでのIDチェックはありません[パブリック/プライベートキー署名によるSSL認証局の確認などを介して]）

$ curl 'http://placeimg.com/' -H 'Host: placeimg.com'  
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' 
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'  -v -L
*   Trying 216.243.142.217...
* Connected to placeimg.com (216.243.142.217) port 80 (#0)
> GET / HTTP/1.1
> Host: placeimg.com
>
< HTTP/1.1 302 Found
< Location: http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F357812412D8
<
* Ignoring the response-body
* Connection #0 to Host placeimg.com left intact
* Issue another request to this URL:  
       'http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F35792412D8'
* Connection 0 seems to be dead!
* Closing connection 0
*   Trying 1.1.2.1...
* Connected to 1.1.2.1 (1.1.2.1) port 80 (#1)
> GET /reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F8 HTTP/1.1
> Host: 1.1.2.1
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
>
< HTTP/1.1 200 OK
< Date: Mon, 08 Aug 2016 02:50:16 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
< Content-type: text/html; charset=utf-8
<
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta name="viewport" content="width=device-width"/>
        <title>Login</title>
        <h1>WiFi - Free Internet Access</h1>
This service is provided primarily for the purposes of accessing Email and light web browsing ..
....
</div>
</body>
</html>

私は出力を切り詰めて編集しましたが、本質的には、ブラウザー（curl）がネットワークが実際のDNSサーバーへのアクセスを提供しているリクエストを行うとき、サービスに接続しているときにこれを実行することでさらにテストしました。

$Dig +short google.com
203.118.141.95
203.118.141.123
... (basically real ip addresses for google.com)

つまり、サービスはDNSに関する真実の情報を提供しているようです。

しかし、私のブラウザーがアドレス指定しているIPアドレスが有効であるように見えても、返されるHTTP応答は、目的のサーバー（WiFiサービスによって挿入されたサーバー）からのものではありません。応答は

  • 302ブラウザーに1.1.2.1/reg.phpサーバーとURLに新しいリクエストを送信するよう指示する
  • そのサーバー/ URLからの応答は「キャプティブポータル」ページです。

HTTPSリクエストを行うとき

$ curl 'https://google.com/' -H 'Host: google.com' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -v -L
*   Trying 216.58.220.142...
* connect to 216.58.220.142 port 443 failed: Connection refused
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
* Failed to connect to google.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to google.com port 443: Connection refused

要求は完全に失敗します-私のコンピューターは認証できないリモートホストからの接続を受け入れないためと思いますか？
私の質問ですが、これはTCP/IPレベルでの「中間者」型の傍受ですか？言い換えると、私のコンピューターのネットワークスタックが3ウェイハンドシェイクを開始してplaceimg.comサーバーとのTCP接続を確立しようとすると、Wifiサービスゲートウェイまたはネットワークノードになります。私のSYNにACK/SYNで応答し、はい、あなたが話したいサーバーです-TCP接続次に、HTTPリダイレクトを自動的に送信するようにプログラムされたプログラムを確立すると、ブラウザが実際に1.1.2.1自体への次のリクエストを生成するため、すべての「おもしろいビジネス」は停止し、そのすべてそれ以降の通常のHTTP/HTML動作（つまり、通常のWebサイトで行うのと同じように、標準のフォーム入力と送信）
そうでない場合、「認証されていない」ユーザーであるときに、このゲートウェイはどのように私の要求を傍受して再ルーティングしますか？

wifiman-in-the-middletcp
29
the_velour_fog

だから私の質問は、これはTCP/IPレベルでの「中間者」型の傍受なのか？

はい、これは、インターネットへの接続の途中にあるため、アクセスポイントに簡単にアクセスできるミドルタイプのインターセプトの男性です。キャプチャポータルへのこのようなリダイレクトは、パケットフィルターを使用して簡単に実行できます。

通常の方法は、認証（ログイン、同意済みの条件など）を行うと、一時的なルールがアクセスポイントのパケットフィルターに追加され、リダイレクトルールが優先され、インターネットへの直接アクセスが許可されます。 。

33
Steffen Ullrich

HTTPSリクエストを行うときリクエストは完全に失敗します-私のコンピューターはリモートホストからの接続を受け入れないため、認証できません。

彼らはあなたのHTTPS接続を傍受しようとさえしておらず、代わりにそれを単にブロックしているようです。

一部のキャプティブポータルは、HTTPS接続をインターセプトしようとするため、クライアントで証明書エラーが発生します。

認証されていないユーザーでもHTTPを許可するいくつかのキャプティブポータルも見ました。

だから私の質問は、これはTCP/IPレベルでの「中間者」型の傍受なのか？言い換えると、私のコンピューターのネットワークスタックが、3方向のハンドシェイクを開始することによって、placeimg.comサーバーとのTCP接続を確立しようとすると、Wifiサービスゲートウェイまたはネットワークノードが応答します。私のSYNにACK/SYNを付けて「はい」と言って、あなたが話したいサーバーです-TCP接続を完了してから、HTTPリダイレクトと次に、私のブラウザが実際に1.1.2.1自体への次の要求を生成しているため、「おかしなビジネス」はすべて停止し、その時点からのすべての通常のHTTP/HTML動作（つまり、標準のフォーム入力と送信通常のウェブサイト）

うん、それはそれを行う通常の方法です。キャプティブポータルサーバーがLinuxベースの場合、「REDIRECT」または「DNAT」ターゲットを使用して、トラフィックをキャプティブポータルWebサーバーに転送し、リダイレクトを発行できます。他のステートフルファイアウォールシステムにも同様のオプションがある可能性があります。

これらのシステムは一般に非常に柔軟性が高いため、ポータルオペレーターが認証なしでインターネットの特定の部分（たとえば、支払いゲートウェイなど）へのアクセスを提供したい場合、簡単に行うことができます。

認証に成功すると、キャプティブポータルは、インターネットへの通常のアクセスを許可するリダイレクトルールを上書きするルールを設定できます。

アクセスしようとしたWebサイトに設定された（安全でない）Cookieはすべて、キャプティブポータルWebサーバーに送信されることに注意してください。キャプティブポータルを実際に操作するかどうかは、キャプティブポータルの実装者次第です。

9
Peter Green