https 証明書と HTTPS を作成するにはどうすればよいですか?

1. HTTPS にアップグレードする必要があるのはなぜですか?

HTTPプロトコルは広く使用されており、インターネットの発展に多大な貢献をしてきました。インターネットは、初期のメディアとコンテンツのプラットフォームから、人々とサービスを結び付け、クローズドループのトランザクションエコシステムを完成させるプラットフォームへと進化しました。特に「インターネット+」の時代には、インターネット上でやりとりされるデータはよりプライベートで重要になり、HTTPは徐々にその欠点を露呈してきました。

HTTP プロトコルの通信プロセスはプレーンテキストで行われますが、TCP/IP プロトコルは基本的にストア アンド フォワード メカニズムに基づいて動作します。サーバー ポートからブラウザーへのデータ リンクでは、さまざまな中間リンク (プロキシ、ゲートウェイ、ルーター、WIFI ホットスポット、悪意のあるドライバー、悪意のあるブラウザー プラグインなど) が、通過するデータグラムを簡単に監視および変更できるため、情報漏洩や悪意のある改ざんにつながります。

HTTPプロトコルには、ユーザーやウェブサイトの認証機構がありません。ユーザーがブラウザに入力したURLがDNSに乗っ取られ、偽のウェブサイトに誘導される可能性があります。ユーザーは偽のサーバーと通信し、口座番号やパスワードなどの重要な情報を不正に取得される可能性があります。

HTTP 通信プロセスが悪意を持って乗っ取られ、改ざんされたとしても、一般ユーザーはその違いを見分けることができず、すべての問題をウェブサイトまたはアプリ開発者のせいにし、ウェブサイトとアプリの正常な動作とブランドに悪影響を及ぼします。

ハッカーは、HTTP 通信中に悪意のあるコードやウイルスを挿入して、双方向の侵入と攻撃を実行します。

あるSaaS製品を例に挙げてみましょう。2015年に、この製品の販売業者のPC側でページコンテンツのハイジャック事件が3件発生しました。ユーザーが使用中に、悪意を持って挿入された広告やJSコードがページに表示され、ページの正常な機能に影響を与え、販売業者のバックエンドシステムが正常に使用できなくなり、販売業者の業務プロセスに影響を与え、ユーザーからの苦情や返金につながりました。

統計によると、2015年第3四半期、この製品のユーザー側APPのハイジャック率は2〜3％でした。

HTTP ハイジャックに対処するにはどうすればいいですか?
フルサイト HTTPS ソリューションを選択するインターネット アプリケーションが増えています。世界的な観点から見ると、サイト全体の HTTPS は必須です。

インターネット金融、電子商取引、インターネット決済業界では、アプリケーションのセキュリティを向上させるために、長い間、フルサイト HTTPS を使用してきました。

2015 年 3 月、Baidu はフルサイト HTTPS の時代に入り、Baidu 検索へのすべてのアクセスが暗号化されることを発表しました。 Baidu は、ウェブサイト全体に HTTPS を採用した中国初のインターネット企業となりました。

2015 年 5 月、Baidu 検索エンジンは HTTPS サイトの組み込みを全面的にサポートし、ランキングで優先させました。

2015 年 7 月、アリババの Taobao と Tmall の Web サイトはすべて HTTPS を採用し、中国で Web サイト全体に HTTPS を採用した最初の電子商取引プラットフォームとなりました。

2016 年 6 月、Apple は、2017 年 1 月 1 日までに App Store のすべてのアプリで App Transport Security セキュリティ機能を有効にする必要があると発表しました。

App Transport Security (ATS) は、Apple が iOS 9 で導入したプライバシー保護機能です。プレーンテキストの HTTP リソースの読み込みをブロックし、より安全な HTTPS を経由した接続を要求します。

インターネットアプリケーションの基盤となるクラウドプラットフォームとして、過酷なインターネット環境に対応するために、クラウド製品においてテナントに便利で信頼性の高い HTTPS 機能を提供することは重要かつ必要です。

2. Baidu サイト全体に HTTPS を実装するにはどうすればよいですか?

HTTPS プロトコルの動作メカニズムを紹介する記事はすでにオンライン上に多数あるため、ここでは詳細には触れません。ここでは、Baidu のフルサイト HTTPS を例に、インターネット アプリケーションをフルサイト HTTPS にアップグレードするときに発生する問題と、いくつかの解決策を紹介します。

課題 1: 互換性への対応 1995 年に Netscape が SSL プロトコルをリリースして以来、HTTP プロトコルは 1.0 から HTTP1.1 へと普及し、HTTP2.0 も普及しつつあります。

セキュア トランスポート層プロトコルも、SSL v2.0、SSL v3.0、TLS 1.0、TLS 1.1、TLS 1.2 の 5 つのバージョンを経てきました。SSL v2.0、SSL v3.0、TLS 1.0 にはセキュリティ上の脆弱性が見つかっており、新しいオペレーティング システムや新しいブラウザーでは徐々に廃止されていますが、TLS1.3 はまもなくリリースされる予定です。

しかし、国の事情により、中国市場には依然として、こうした欠陥のある暗号化伝送プロトコルを使用している古いブラウザが少数（約 2%）存在しています。

課題 1 の解決策:

小規模なインターネット アプリケーションの場合、ユーザー数が比較的少ないため、古いバージョンのシステムやブラウザーのサポートを放棄し、ユーザーに推奨バージョンへのアップグレードを要求しても大きな問題にはなりません。ただし、1 日あたり 100 億 PV 近くに達する大規模な Web サイトやアプリケーションの場合、これらの古いブラウザーのサポートを放棄すると、明らかに膨大なトラフィック損失が発生します。

したがって、大規模なインターネット アプリケーションを HTTPS にアップグレードする場合は、下位バージョンのシステムとの互換性を考慮する必要があります。たとえば、サービスのダウングレードでは、上位バージョンの TLS をサポートしていないアクセスは、下位バージョンの HTTPS プロトコルを使用するようにダウングレードされます。アルゴリズムの互換性を向上させるために、SHA-1 と SHA-256 の両方がサポートされます。実際に HTTPS を使用できないユーザーの場合、アクセスは 302 リダイレクトでリダイレクトされ、通常の HTTP アクセスが復元されます。

課題2: 処理の遅延と同時実行性の低下への対処

DNS 解決プロセスを無視して、HTTP プロトコルでは、TCP のやり取りが 3 回完了すれば、リクエストの送信と結果の返信を開始できます。 HTTPS では証明書の検証やキーのネゴシエーションなどの複雑な手順が追加されるため、キャッシュ ヒットの状態に応じてインタラクションの回数が 3 ～ 7 倍に増加します。

最適化されていない場合、250〜500ミリ秒の遅延が発生し、品質の低いページでは500〜1200ミリ秒悪化する可能性があります。

同時に、さまざまな対称アルゴリズム、非対称アルゴリズム、ハッシュ アルゴリズムが計算時間を消費し、数十ミリ秒の遅延が発生します。 非対称暗号化と復号化は多くのコンピューティング リソースを消費するため、サーバーの同時実行パフォーマンスの低下にもつながります。

HTTP を使用すると、Web サイトの CPS が 20,000 を超える可能性があります。HTTPS を使用すると、CPS は約 2,000 ～ 3,000 に低下します。

課題2の解決策:

ユーザーエクスペリエンスに大きな影響を与えずにレイテンシとコンピューティング能力の急増に対処するために、大規模な Web サイトでは、通信プロトコル、暗号化アルゴリズム、バックエンド アーキテクチャ、トラフィック スケジューリング、フロントエンド ページ、運用および保守管理を最適化します。手順は次のとおりです。

1. プロトコル層では、互換性のあるクライアントに対して TCP ファストオープン (TFO RFC7413)、HSTS、セッションキャッシュ、セッションチケット、Ocsp ステープル、False start、SPDY/HTTP2 などのテクノロジを使用して、ハンドシェイクの数を減らし、ジャンプの数を減らし、接続の再利用率を高めます。

2. Web ページまたはクライアント ユーザーがアクセス要求を開始する前に、アプリケーション層で事前接続を行い、ハンドシェイク プロセスを事前に完了して、遅延を短縮します。

3. アルゴリズムに関しては、パフォーマンスの最適化には ECC が推奨されます。ここで使用される ECC キーの長さは、RSA キーと DH キーの長さよりも短くなります。

4. バックエンド アーキテクチャでは、SSL ハードウェア アクセラレーション クラスターを使用して SSL オフロードを実行できます。

次の図は、実験環境で SSL ハードウェア アクセラレーションを使用した場合と使用しない場合の、HTTPS アクセスを処理するサーバーのパフォーマンス比較です。ハードウェア アクセラレーションを使用すると、サーバーの同時実行性が数倍向上し、サーバーの CPU 負荷が軽減され、応答時間が大幅に短縮されることがわかります。

5. SSLハードウェアアクセラレーション効果実験

課題3: HTTPS攻撃への対処

1. プロトコルダウングレード攻撃を防ぐ

ダウングレード攻撃には、一般的に、暗号スイート ロールバックとプロトコル ダウングレード攻撃 (バージョン ロールバック) の 2 種類があります。

ダウングレード攻撃の原理は、攻撃者がクライアントの Hello メッセージを偽造または変更し、クライアントとサーバーがより弱い暗号化スイートまたはプロトコルを使用して通信するようにすることです。

解決策: ダウングレード攻撃に対処するために、サーバーとブラウザの間に SCSV 機能が実装されるようになりました (原理については https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 を参照してください)。

2. 再交渉攻撃を防ぐ

TLS 再ネゴシエーションには、暗号スイート再ネゴシエーションとプロトコル再ネゴシエーションの 2 種類があります。再交渉には 2 つの隠れた危険があります。

*再ネゴシエーション後は弱いセキュリティ アルゴリズムを使用します。その結果、送信されたコンテンツが簡単に漏洩する可能性があります。

*再ネゴシエーション プロセス中に完全なハンドシェイク要求が継続的に開始され、サーバーが高負荷の計算を実行し、サービスが拒否される原因になります。

解決策: 再ネゴシエーションの場合、最も直接的な保護手段は、クライアントが積極的に再ネゴシエーションを行うことを禁止することです。もちろん、特別なシナリオのニーズに応じて、サーバーが積極的に再ネゴシエーションを開始できるようにする必要があります。

課題4: フロントエンドページに関連するすべてのリソースはHTTPSをサポートする必要があります

HTTPS の目的は、送信プロセスのセキュリティを確保することです。メインドメイン名のみが HTTPS 上にあり、メインドメイン名によって読み込まれる js、css、画像などのリソースが HTTPS 上にない場合、ブラウザはユーザーに警告し、ユーザーがページにアクセスし続けるのを防ぎます。

ユーザーがアクセスを強制され続けると、js、css、画像が乗っ取られる可能性が依然としてあり、Webサイトの送信プロセスのセキュリティを確保するという目的が達成されません。これらのコンテンツが改ざん/盗聴されると、HTTPSの意味が失われます。

課題4の解決策:

実際、HTTPS の導入方法や難易度はサイトによって大きく異なります。

大規模なサイトの場合、Web サーバーが HTTPS をサポートできるようにし、Web サーバーの HTTPS プロトコル機能を最適化することは、移行作業の 20% ～ 40% しか占めない可能性があります。 CDN システム、フロントエンド リソース、テンプレート、サービス アドレスで HTTPS をサポートするのは、より時間と労力のかかる作業です。

6. フロントエンドページのHTTPS化のポイント

3. 中小規模のウェブサイトはどのようにして Baidu のメリットを無料で享受できるのでしょうか?

Baidu の実践を見て、サイト全体に HTTPS を実装するのは大変な作業で気が重いと感じますか?

これまで、Web アプリケーションを HTTPS に変換する場合、公開鍵と秘密鍵の生成、証明書アプリケーションの作成、証明書の申請、負荷分散、サーバー、CDN での HTTPS 機能の有効化、証明書と秘密鍵の展開、パフォーマンスの最適化などの面倒な手順を実行する必要がありました。

では、より安価でより速い、よりエレガントな方法はあるのでしょうか?

Baidu Open Cloud を試すことができます。次のような効果があると言われています。

Baidu Experienceの無料アプリケーションと無料再利用

ソースサイトを変更する必要はなく、1ステップで完了

動的に追加され、即時有効になります

テナント証明書の秘密鍵の送信と保管はすべて暗号化されています

HTTPリクエスト処理と互換性があるので安心

柔軟な公開、ソースへのSSLプロトコルバージョンを任意に切り替えることができます