Yandex.BrowserのWiFiを保護します。 HTTPSをまだ使用していない人の保護について

今日は、パブリックWiFiの使用時にトラフィックを保護する新しいYandex.Browserテクノロジーについてお話ししたいと思います。 そして、近い将来、ZeroNightsカンファレンスの競争の一環として、誰でもその脆弱性の発見を試みることができます。 しかし、まず最初に。







安全でないWiFi



オープンまたは安全でないWiFiがもたらすリスクについては、Habréに通知しないことも可能です。 Wi-Fiネットワークでの信頼性の低いWEPプロトコルの使用が主な原因で、何百万ものクレジットカード番号の損失が可能になった、史上最大の銀行データリークを思い出すだけで十分です。 それから10年が経過しましたが、状況は改善されていません。現在、暗号化なしでどこでもドットに囲まれているからです。 カフェ、空港、さらにはバス停でも見つけることができます。 同時に、スニファーを持っている学生は誰でもこのようなWiFiの傍受を習得できます。 そして、最も単純なハッキングデバイス一般にインターネット上で数ドルで販売されています。





詐欺師が「Free WiFi」という形式の名前で公共の場所に自分のオープンWiFiポイントを作成する必要がある場合、なぜ何かをハッキングします。 さらに、彼女の名前が広く使用されている別の名前と一致する場合、スマートフォンは範囲内にあるとすぐにそのようなポイントに自動的に接続できます。 その結果、詐欺師はすべての暗号化されていないデータを傍受します。 または、DNSをすべての結果に置き換えます。 実際、彼らはこのストリームに衝撃的な広告や偽の許可を埋め込むことができます。



データ傍受のリスクはよく知られています。 そのため、HTTPSの使用は、機密データを扱うサイトにとって暗黙のルールです。 ブラウザ業界は、HTTPSラベル付けから安全でないHTTPサイトに関する恐ろしい警告への移行のアイデアについても議論しています。 しかし、変化はそれほど速く起きていません。 たとえば、データによると、ブラウザに読み込まれたすべてのページの68%がまだHTTPを使用しています。 そして、ユーザーは、ほとんどの場合、アドレスバーのロックに注意を払っていません。





クロム実験



ある時点で、サポートコールを分析して、ブラウザ側でトラフィックの暗号化を有効にする必要があるかどうか疑問に思いました。 さらに、プロキシサーバーが既にあり、ターボテクノロジーが作業を行っており、ページとビデオの最適化を担当しています。 それはただのターボモードであり、一般的な考えに反して、トラフィックを暗号化する方法を知りませんでした。 Turboテクノロジーの現在の古いバージョンがブラウザでどのように機能したかについてのいくつかの言葉。



ターボ1.0



Turboのサーバーコンポーネントは、 Pikeのように非常に狭い範囲で広く知られている言語でOperaによって記述されたことがあります。 したがって、私たちはあなたがあなたがどんな戒めを知っているかを思い出して、再びサーバーに触れないようにしました。



クライアントとのデータ交換は、TLSなしのSPDYのすでに古いバージョンを介して実行されました。 ブラウザのクライアントコードは、最初は圧縮(ON / OFF)で動作する最も単純なモードに焦点を合わせ、新しいチップで大きくなりすぎました。 速度に応じて自動的にオンにするように彼に教えました。 さらに、人がブレーキを感じる前に加速を含めるために、最も近いIPアドレスからの他のユーザーの統計も考慮されました。 そして、ストリーミングビデオ圧縮などのクールな機能を統合しました。 何らかの理由で、これらすべてのコードが簡単になることはありませんでしたが、私は本当にやりたかったのです。



つまり、そもそもプロキシテクノロジ全体を更新する必要がありました。 幸い、スリッパがありました。



スリッパプロジェクト



Sneaker(TAPOCはAdvanced Page Optimizer and Compressor)は、Yandex.Browser開発チーム内のプロジェクトであり、最初は数人の個人的なイニシアチブから生まれました。 スニーカーの目標は、Turboコードを更新し、最新の要件を満たすことでした。 少なくとも、一般的な技術を使用してサーバー部分を書き換える必要がありました。 これにより、より積極的な開発が可能になります。 さらに、クライアントをクリーンアップする必要があり、テストがますます困難になりました。 そしてもう一つの些細なこと:何も壊さないことが重要でした。







幸いなことに、Slipperは(良い方法で)飛行し、計画は過剰に実行されました。 サーバー側は、カーネルとしてnginxを使用して、少し一般的なC ++で書き直されました。 さらに、古いコードの代わりに、オープンソースライブラリのPageSpeed Optimizationを使用してページを圧縮することにしました。 これにより、Turboモードは、CSS / JS / HTMLを圧縮するだけでなく、CSS / JS / HTMLを縮小することを学びました。 彼らは自分自身から何かを追加しましたが。 たとえば、重いアニメーションGIFをWebPに変換します。 自転車はクライアントで生成されなくなり、データ削減プロキシ(これはコンテンツも圧縮されているGoogleサーバーです)との通信を担当するChromiumに既に存在するコードを最大限に使用しました。 必要なのは、ビデオ圧縮やその他のYandex.Browser関数を使用してこのコードを友達にすることだけでした。



しかし、最良の部分は、ブラウザーとサーバー間の接続がHTTP / 2で機能するようになったことです。 これには、トラフィックの暗号化、ストリームの優先順位付け、重要なリソースのサーバープッシュサポートが含まれます(ちなみに、Chromiumプロジェクトはやがてそれらを支援しました)。



安全な無線LAN



暗号化の問題は解決されました(同時に、コンテンツを圧縮するためのテクノロジー全体が更新されました)。 これにより、ユーザーのHTTPトラフィックがDNSによって傍受およびスプーフィングされるのを防ぎました(HTTPSは私たちがいなくても証明書によって保護されています)。 しかし、私たちの目標はより具体的だったので、私たちはそこで止まりませんでした。 WiFi保護を覚えていますか?



このストーリーの最初から、ユーザーデータを保護したかったのですが、ユーザーデータに干渉したくはありませんでした。 最適化と圧縮なしで動作します。 そのため、ターボを再構築する段階で、「ボンネットの下」に「圧縮なし」特殊モードを追加しました。 有効にすると、すべてのHTTPトラフィックがプロキシサーバーを介して暗号化されますが、コンテンツ自体は変更されません。 しかし、これでは十分ではありません。



ブラウザに接続を分析し、本当に必要な場合にのみセーフWiFiモードを有効にするように教えました。 WPAおよびWPA2プロトコルを使用した最新の暗号化は非常に信頼できます。 WEPまたはパスワードをまったく必要としないポイントについて言えないこと。 セーフWiFiモードが自動的にオンになるのは彼らのためです。 次の特性のいずれかが変更されるたびに、接続チェックが再度実行されます:IP、ルーターのMacアドレス、ESSID。 ところで、チェックにはイントラネットの検出が含まれているため、インターネットにアクセスせずにプロキシを介したトラフィックを許可しようとはしません。







インターセプトからのWiFi保護がYandex.Browser for Windows、OS XおよびAndroidで利用可能になりました。 私たちのチームは現在も改善を続けているので、あなたのフィードバックは非常に役立つでしょう。



ZeroNightsのYandexブラウザー



隔離された環境ではセキュリティに取り組むことができないことを理解しています。 そのため、間もなくYandex.Browserは、特別なコンテストの一環としてエラーや脆弱性を検索できるようになります。 これは、伝統的にセキュリティの専門家を惹きつけるZeroNights会議の主催者と一緒に開催されます。 受賞者には賞金が贈られます。 ニュースをフォローしてください!



All Articles