信じられないことだが、TLS ServerName Indication (SNI) は13年前から存在している。このブログでは、edgeNEXUSの高度なロードバランサーがこの機能をどのようにサポートできるかを紹介します。SNIはSSL/TLS/HTTPSに関して多くの人が抱えている最大の問題の1つに対処するものだ。これは、SSL/TLSが、貴重なドメイン名の詳細を含むクライアントの最初のHTTPリクエストを検査する前に接続を保護するために必要です。
正しい証明書を確実に提供する唯一の方法は、IPアドレスごとに1つだけ提供し、DNSを使用して、特定のドメイン名へのリクエストが、そのドメインの正しい証明書を提供するホストのIPアドレスにルーティングされるようにすることです。私企業では、同じIPアドレスでも異なるポートを使うこともできるが、その場合、非標準のポートを使うことを全員に知らせる義務がある。これは、公共のインターネットにアクセス可能なサービスを扱う場合、実際には実行可能な選択肢ではない。
可能な限りすべてのサブドメイン（たとえば*.jetnexus.co.uk）を保護するワイルドカード証明書を使うこともできるが、セキュリティ・タイプに限らず、誰も好まない。情報セキュリティー界のNO！な人たちをどう思おうと、彼らの言うことにも一理あるだろう。デザイン上、ドメイン内の文字通りあらゆるものを表すものを信用するのは難しい。どれだけのデバイスが保存され、どれだけのスタッフが使用中の証明書と鍵にアクセスできるのか？
サーバー代替名(SAN)証明書も常に利用可能であるが、証明書生成時に、保護するドメイ ンごとの知識が必要である。ドメイン名を削除または追加する必要がある場合は、証明書を再生成し、関連するすべてのホストを更新する必要がある。
IPアドレスを燃やすか、（あらゆる意味で）妥協を受け入れるか。IPアドレスは有限のリソースであり、可用性は日々減少し、価値は日々上昇するからだ。幸運なことに、この長年の課題には長年解決策がありました。この解決策によって、私たちはあらゆる世界のベストを手に入れることができるのだが、最近までその影響はほとんどなかった。
SNIは、クライアントがサーバー（ここではjetNEXUS）に対して、接続を確立しているドメイン名を示す方法を提供する。これは、クライアントの最初のTLSパケット（hello）の拡張フィールドにドメイン名を入力することで行われる。これはサーバーがSSL/TLS証明書を送信する前に読めるように、「クリアな状態」で送信される。これによって、サーバーはどんなに多くの証明書が提供されたとしても、その中から期待される証明書を送ることができる。
このため、1 つの仮想サービス（および IP アドレス）に、提供したいドメイ ン名の数だけ SSL 証明書を設定できます。それぞれ専用の有効な SSL 証明書を持つことができ、クライアントから提供され たデータに基づいてエラーなしで正しく提供されます。同じIPアドレスでwww.jetnexus.co m、www.loadbalance.co.uk、両方に有効な証明書を提供します。妥協も手間もIPアドレスの無駄もありません。
それだけでなく、GUI を数回クリックするだけで、仮想サービ スがサポートするドメインのリストをいつでも変更できます。証明書を追加または削除して、仮想サービスがサポートするドメインを追加または削除します。同時に DNS を更新することを忘れないでください。1 つまたは 2 つの高価値ドメインに異なるリアルサーバーを使用したい 場合も問題ありません。HTTP圧縮、URL書き換え、その他必要なことも同様です。複数のドメインに単一の仮想サービスとIPアドレスを使用することは非常に望ましいことですが、異なるドメインのトラフィックに適用したい独自の処理を制限する必要はありません。
という声が聞こえてきそうだ。SNIがこれほど長い間存在していながら、ロードバランシングやその他の製品に使われるようになったのはそのためだ。その理由とは？クライアントのサポートだ。絶大な人気を誇るWindows XPとIE6の組み合わせが長続きしているため、SNIをサポートしておらず、ほとんどのクライアントがSNIを使うことができない。誰も自分たちの利用者の10〜20％を切り捨てるようなことはしたくないのだ。
ウィンドウズXPのサポートは終了し、IE6のウェブ上での使用率は1％未満となり、ウィンドウズ10への無償アップグレードは急速に普及している。SNIを導入しても、顧客やビジネスに影響を与えることはないと、ようやく確信できるようになりました。IE 7以降（Vista以降）、および最も古いChrome、Firefox、Safariを除くほぼすべてのバージョンがSNIをサポートしています。特定のユーザーベースについて確認したい場合は、そのためのflightPATHルールもあります。
クライアントはプレーンテキストで情報を提供している。クライアントはプレーンテキストで情報を提供している。クライアントも接続する前にプレーンテキストのDNSクエリーを行います。それをコントロールすることはできないので、この情報を後で2度目に公開することはリスクとはみなされない。おそらく、SNIのドメイン名がHTTPのHostヘッダーにあるものと一致するかどうか、flightPATHルールでチェックしたいかもしれません。これはセキュリティ上の問題を示唆しているのだろうか？いずれにせよ、クライアントは接続されており、接続は安全です。ドメイン名に基づいてセキュリティ・ポリシーを適用しているのでなければ（適用すべきではない）、問題はない。
もっと詳しく知りたければ、オリジナルの RFC3546(3.1節)、後のRFC6066(3節)、そして信頼できるのであれば、それを見てください：WikipediのServer Name Indicationをご覧ください。アプリケーションレベルのセキュリティが必要な場合、edgeNEXUS WAFは業界をリードする堅牢なアプリケーションファイアウォール技術に基づいています。edgeNEXUSアプリケーションファイアウォールは、PCI-DSSやOWASPのコンプライアンス要件を満たす包括的なセキュリティ保護を提供します。以前のブログ記事で紹介したように、flightPATHはedgeNEXUSが開発した動的なイベントベースのルールエンジンで、負荷分散されたIP、HTTP、HTTPSトラフィックをインテリジェントに操作し、ルーティングします。flightPATHのトラフィック管理の詳細についてはこちらを、利用可能なルールを最大限に活用する方法についてはedgeNEXUSユーザーガイドをご覧ください。
1 つの仮想サービス（および IP アドレス）に、提供したいドメイン名 の数だけ SSL 証明書を設定できます。それぞれ専用の有効な SSL 証明書を持つことができ、クライアントから提供された データに基づいて、エラーなしで正しく提供されます。
