昔からのHTTPプロキシでは、HTTPSの場合、最初にクライアントからプロキシに HTTP (= 平文) でCONNECTメソッドのリクエストを送り、プロキシではHTTPSに接続を切り替えてUpgradeレスポンスを返す。
ただ、これだと少なくともHostが平文でネットワーク上を流れてしまう。
2019年1月時点のFirefox, Chrome, curl 7.52.0 以降では、ブラウザ/クライアントから、最初からHTTPSでプロキシにリクエストする "HTTPS" タイプのプロキシがサポートされている。
Firefox:
Chrome:
curl 7.52.0 以降
IE/Edge/Safari/Android/iOSでの対応状況は不明。
以前から SwitchyOmega や FoxyProxy など Chrome/Firefox用のプロキシ切り替え拡張で、プロキシの設定画面でschemaの他にタイプとして HTTP/HTTPS/SOCKS4/SOCKS5 あたりが選べるようになってて、「HTTPとSOCKSはわかるけど、HTTPSってなんじゃらほい・・・?」と不思議に思ってたのが、どうやらこれらしい。
どういう仕組で動いてるかは試したわけじゃないので確証は無いが、Chrome側の上記URLで、簡単に試すために通常のHTTPプロキシとして動作してるSquidに対してstunnelでSSLトンネリングしかければ、HTTPSでプロキシできるらしい。ということは Squid のCONNECT -> Upgrade の流れがそのままHTTPS(というかSSL)になっただけと思われる。SquidとしてはUpgrade返したあとは中の通信は素通しになるので、まぁ最初からHTTPSなら、Squid側としてはなんら変わることが無いのだろう。
Squid自体も https_port あたりの設定値でネイティブに HTTPS プロキシをサポートしているようなので、それで試しても良いかもしれない。
これ、httpスキーマについてもHTTPS プロキシで通せるのかな? クライアント <> プロキシ間はHTTPSで、プロキシ <> ディスティネーションサーバ間はHTTPになるイメージだけど。
もしそれも可能なら、プロキシの利用者を制限するためにプロキシ認証を使いたいけどプロキシ認証の通信経路は暗号化したいときに最適かもしれない。
最大の難点は対応ブラウザやクライアントが限られること。とはいえ、Chrome/Firefoxで現時点で普通に動くので、一般ユーザ向けであれば採用しやすいかもしれない。アプリ間通信に使うのはcurl以外の対応状況が不明なので厳しいかな?
あと、「これで通信先を完全に隠せる」かというと、そうは行かない気もする。多分 ブラウザ -> プロキシへの最初のHTTPSで、今なら普通にSNIを送るのではなかろうか?そうなると TLS Client Hello パケットの中に平分で最終ディスティネーションのホスト名がSNI拡張フィールドに含まれるため、盗聴されていればどこに接続しようとしているのか、までは見えてしまう。
以上、メモ。
コメント