内部ネットワークの一部のユーザーに対して特定の URL をブロックしたいと考えています。この目的のために、redirect_program を使用した squid ベースの明示的プロキシを使用しています。クライアントは、https URL に pac ファイルを使用するように構成されており、これにより、クライアントは https 要求を明示的プロキシにルーティングします。
問題は、https URL の CONNECT 要求をブロックされたページ URL にリダイレクトすると失敗するということです。http ベースと https ベースの両方のブロックされたページ URL を試しましたが、うまくいきませんでした。何らかの理由で、SSL バンピングで透過プロキシを使用したくありません。
Safari で「Safari はページを開けません。エラーは「Web プロキシ サーバーを介した安全なトンネルの確立中に問題が発生しました」でした」というエラーが表示されます。
Chrome で「このウェブページは利用できません。ERR_TUNNEL_CONNECTION_FAILED」というエラーが表示されます。
以下はaccess.logからの抜粋です。https://www.yahoo.com。
2015年10月7日:01:41:29 -0500 74 172.0.0.9 TCP_REDIRECT/302 253 CONNECT www.yahoo.com:443 - HIER_NONE/- -
どこかで読んだのですが、ブラウザは接続要求後に SSL/TLS ハンドシェイクを開始することを期待しており、それが失敗の原因だそうです。以下は、squid リダイレクタのドキュメントからの引用です。
「URL の変更、特にリダイレクトは特定のメソッドでのみ可能であり、POST や CONNECT などの一部のメソッドでは特別な注意が必要です。」
CONNECT メソッドではリダイレクトが不可能とは書かれていません。ただし、POST と CONNECT (私は特に CONNECT に興味があります) をリダイレクトする方法についてはどこにも記載されておらず、例も示されていません。
https 接続要求をブロックされたページにリダイレクトする方法を教えてください。これが不可能な場合、明示的なプロキシを使用して回避策はありますか? ありがとうございます。
私はUbuntuでsquid 3.5.4を使用しています。
答え1
残念ながら、最初に SSL 接続をバンプ (復号化) しなければ、これは不可能です。ブラウザは設計上、失敗した CONNECT 要求からの追加のペイロード/リダイレクトを拒否します。より正式な説明については、次を参照してください -http://docs.diladele.com/faq/squid/cannot_connect_to_site_using_https.html。
もし、あんたがするSSL 復号化を実行することにした場合、最初に CONNECT 要求を成功させ、後でこの確立された接続トンネルを通過する次の HTTP 要求をブロック/リダイレクトすることが可能です。一部のアプリケーションでは独自のプロトコルに CONNECT プロキシ トンネリングを使用するため (Skype など)、HTTP ではない可能性もあることに注意してください。
また、留意すべき点として、アプリケーションがプロキシへの CONNECT 要求を行う際に「SSL ピンニング」手法を使用した場合、復号化された接続での動作が拒否されます。