多くの場合、パブリックな保護されていないWiFiネットワークを介したWebサーフィンのセキュリティに関する議論と保護のための推奨事項を観察することができました（Habréを含む）。
少なくとも、可能な限りHTTPSを使用することをお勧めします。 多くの人々はTORおよび/またはVPNについて覚えています。 誰かが自分のサーバーよりもVPNを好む（ただし、接続ログを書き込まないことが保証されています！）、誰かがVPNを購入します。 それは起こる、彼らは景品について覚えている。 完全または限定（テスト用に1か月あたりxxx Mb。必要に応じて、お客様とお会いできることを嬉しく思います）。 特に、Expat ShieldやSecurityKISSなどの「ラベル」が使用されました。 条件は異なりますが、それはポイントではありません。 何らかの形で、制限の有無にかかわらず、これは無料です。 設定してみてください。
SecurityKISSは正常に接続し、外部IP 217.147.94.149（英国）を報告しました。
Ping、ブラウザの任意のサイト...すべてが機能しているようです。 特定のインターネットサーバーのポート25へのtelnet接続を確認します。このサーバーでは、実験時にトンネルなしで直接座っています。 サーバーの外部インターフェイスで実行されているTcpdumpは、接続の試行についてはサイレントであり、ポート25へのトラフィックはありません。 しかし、telnetは接続があることを保証します。 確かに、メーラーバナーはありません... EHLO 123を入力し、応答で抜け落ちます
421 SMTPサーバーxx.xx.xx.xx（xx.xx.xx.xx：25）に接続できません、接続タイムアウト
ここで、xx.xx.xx.xxはサーバーのIPです。
ご理解のとおり、これは私のサーバーxx.xx.xx.xxによって応答されず、「xx.xx.xx.xxへの接続...ポートYでこのホストへの接続を開くことができませんでした：接続に失敗しました」
80番目のポートで同じことを試みます。 接続がありますが、tcpdumpには何も表示されません。 しばらくしてから（かなり長い時間）GET /と入力します-TCP-SYNパケットを送信します（実際にはポート80はリッスンしていないため、サービスはありません）。
IP 217.147.94.149.8414> xx.xx.xx.xx.80：S 832655572：832655572（0）win 16384 <mss 1366、nop、nop、sackOK>
結論-できる限りすべてを透過的にプロキシします。
Expat Shieldを試す。
ポート25への接続は、トリックもバナーも必要ありません。 ポート80を試します。 SecurityKISSの場合と同じ効果。 そして、ここでメモの作者は舌をすべらせます。 GETの代わりに、GERを書き込みます。 セッションはこれで終わります
400 Bad Request
400 Bad Request
nginx/1.0.6
400 Bad Request
400 Bad Request
nginx/1.0.6
400 Bad Request
nginx/1.0.6
400 Bad Request
400 Bad Request
nginx/1.0.6
400 Bad Request
400 Bad Request
nginx/1.0.6
今回はより情報量の多いnginx / 1.0.6「グロー」。
これがそのようなセキュリティです。 もちろん、これらのサービスはゲストWiFiの場合にリスニングから保護しますが、固定有線接続の場合、認証データを公開したり、変更されたコンテンツを受信したりするリスクは、これらのトンネルを使用しない場合よりも桁違いに高くなります。
誰かが興味を持っている場合、3Gを介したインターネットのトピックについて、まだ少し好奇心があり、多少似たような資料があります。