SNI に関するさまざまな情報を見つけることができます ( Wikipediaを参照) が、ブラウザーでの実際のサポートに関する統計は見つかりません。
私が知る限り、Windows XP SP3 で動作するはずです。
SNIが実際に実際に使用できるかどうかは誰にもわかりませんか?
SNI に関するさまざまな情報を見つけることができます ( Wikipediaを参照) が、ブラウザーでの実際のサポートに関する統計は見つかりません。
私が知る限り、Windows XP SP3 で動作するはずです。
SNIが実際に実際に使用できるかどうかは誰にもわかりませんか?
仮想ホスティング環境 (サーバーごとに複数のドメイン) の証明書ごとに 1 つの IP から、すべてのドメインに対して 1 つの IP を使用する負荷分散環境に切り替えるための私の経験とアプローチを共有できます。
アナリティクス (1 か月あたり 100 万人を超えるユニーク ユーザー) を調べたところ、2014 年 3 月 8 日に、ユーザーの約 4% が Internet Explorer を使用して Windows XP を使用していることがわかりました。他は軽微でした -- 最悪の場合、SNI をサポートしないことにより、総ユーザーの 4.5 % が影響を受ける可能性があります)。これらのユーザーを「制御」することはできないため、ブラウザーを切り替えるように指示することはできません。この割合も、少なくとも米国ではかなり急速に低下しています。
最初に、SNI をサポートしていないお客様が SNI をサポートしているお客様とは多少異なる体験をしても「OK」であると判断しました。
私たちのアプローチは、ブラウザー/オペレーティング システムの組み合わせが SNI をサポートしていないサーバー側 (UA 文字列を使用) を検出することでした (他の人が言及したように: SNI サポートに関するウィキペディアの記事)。すべてのドメイン (~ 120) には、負荷分散された単一の IP を指す A レコードがあります。generic-autoparts.com と呼ぶことができるドメイン用に 2 つ目の IP (これも負荷分散) がありました。
したがって、セットアップは [以下の例で使用するドメインには関連付けられていません]:
mikesautoparts.com --> IP X
のネームサーバー レコード dansautoparts.com --> IP X jensautoparts.com のネームサーバー レコード --> IP X
のネームサーバー レコード
... など
generic-autoparts.com --> IP Y のネームサーバー レコード
顧客がhttp://www.dansautoparts.comにアクセスし、SNI をサポートしている場合、何も起こりません。彼は dansautoparts.com をブラウズし、チェックアウトするときはhttps://www.dansautoparts.comを使用します。
顧客がhttp://www.dansautoparts.comにアクセスし、その顧客が SNI をサポートしていないことが検出された場合、直ちに顧客をhttp://generic-autoparts.com/dansautoparts.comにリダイレクトします。彼はそこで買い物をし、チェックアウト時にhttps://generic-autoparts.com/dansautoparts.comを使用します。
ここで、顧客がhttps://www.dansautoparts.com (電子メールのリンク、検索エンジンのインデックス付きページ) に直接アクセスした場合、あなたは運が悪い. 彼らは厄介な証明書エラーを受け取ります。私たちの場合、システムが送信するすべての電子メールが https を使用していないことを確認しました。また、検索エンジンが https ページをインデックス化していないこともわかっていました。
各環境には、さまざまな課題と潜在的なトレードオフがあります。私たちの場合、これはうまく機能し、顧客はhttp://generic-autoparts.com/[ORIGINAL DOMAIN].com にリダイレクトされることを「受け入れる」(または気付かない) ことがわかりました。また、generic-autoparts.com を通じてチェックアウトを安全に保ちました。
非 SNI ユーザーの 20% がリダイレクトに気付き、怪しげに見え、離れたとしましょう。私たちの場合、それはユーザーの 0.8 ~ 0.9 % (2014 年 3 月 8 日の数字に基づく) であり、私たちはそれを「受け入れる」つもりでした。現時点で具体的なデータはありませんが、全体の売上は安定しています。[2014 年 3 月 28 日編集: 顧客の 100% を切り替えた後、売上への影響は見られませんでした]
実装の更新 2014 年 7 月 8 日
サーバー上ですべての UA Agent 文字列を静的に検出することは不可能であることがわかりました。ブラウザの SNI 機能を検出するために、次の JavaScript を実装しました。一般的なアプローチは、SNI を必要とするドメインに対して JSONP リクエストを実行することです (Apache は「SSLStrictSNIVHostCheck on」を通じてこれをサポートします)。JSONP リクエストがタイムアウトして失敗した場合、お客様を nonSNI ドメインにリダイレクトします。
さらに複雑なことに、SNI_TEST_DOMAIN がダウンしているという理由だけで全員をリダイレクトしたくはありません。JSONP リクエストが失敗した場合 (JSONP の失敗を直接検出する方法がないため、タイムアウトにより)、HTTP の「ヘルスチェック」リクエストを実行して、サーバーが利用可能であることを確認します。さらに、ページの読み込みごとにこの JavaScript コードを実行したくありません。これにより、奇妙なタイムアウトが発生し、多くの顧客が誤ってリダイレクトされる可能性が高くなるため、SNI チェックが完了したらセッション変数を設定して、それが起こらないようにします。顧客がサイトをナビゲートすると、再び。
JSONP タイムアウトが信頼できないために失敗する特定の誤ったチェックが発生することはわかっていますが、これを実装して以来、顧客からの苦情はありません。
var redirect='http://REPLACE_WITH_NON_SNI_URL';
var sni_https_timeout, sni_http_timeout;
var https_req = $.ajax({
url : 'https://SNI_TEST_DOMAIN.com/snitest.php',
dataType : "jsonp",
}).done(function() {
window.clearTimeout(sni_https_timeout);
var request = $.ajax({
url: "index.php?ua=sni_check_done",
type: "POST"
});
})
sni_https_timeout = window.setTimeout(function() {
var http_req = $.ajax({
url : 'http://SNI_TEST_DOMAIN/sni_healthcheck.php',
dataType : "jsonp"
}).done(function()
{
window.clearTimeout(sni_http_timeout);
window.setTimeout(function()
{
window.location = redirect;
},
200);
});
sni_http_timeout = window.setTimeout(function() { sni_http_fail(); }, 8000);
}, 8000);
function sni_http_fail() {
var request = $.ajax({
url: "index.php?ua=sni_check_done",
type: "POST"
});
}
snitest.php / sni_healthcheck.php:
<?php
if (array_key_exists('callback', $_GET))
{
header( 'Content-type: application/javascript' );
echo "{$_GET['callback']}();\n";
}
問題は、Windows XP クライアントと Android < 3.0 クライアントです。残念なことに、それらを合わせても、当社の多くの Web サイトへの訪問者のほぼ 10% にとどまっています。さらに、Blackberry ユーザーは数は少ないですが、当社の有料顧客の一部です。XP、Blackberry、および Gingerbread を組み合わせると、現時点 (2015 年 2 月) のほとんどの Web サイトで SNI が受け入れられなくなります。この問題は、約 1 ~ 2 年で解消されると思います。
2016 年 11 月の更新 (21 か月後): 1 か月あたりのアクセス数が ~ 10,000 のかなり標準的なサイトにアクセスします。2013 年 1 月 ~10% 非 SNI。2014 年 1 月 ~6%、2015 年 1 月 <2%、2016 年 1 月 ~0.5%、2016 年 11 月 ~0.1% (1,000 分の 1)。カットオーバーは 2015 年 11 月または 12 月に行いました。ただし、特定の市場ではこれらのユーザーの数が多い場合があります。Google アナリティクスでカスタム オーディエンスを作成したので、効果を簡単に確認できます。OS名で定義するだけで、バージョンはで始まり、XPの場合、ブラウザはIEです。
Windows XP 上の Internet Explorer (すべてのバージョン、6、7、および 8) は SNI をサポートしていません。他のすべてが機能します。XP で何人のユーザーが Internet Explorer を使用しているかはわかりませんが、それは SNI を使用できないユーザーの魔法の数です。
モバイル サポート :
Android default browser on Honeycomb or newer
Windows Phone 7
MobileSafari in Apple iOS 4.0 or later
XP から SNI を使用して SSL 接続をサポートすることはできません。ただし、XP クライアントの接続を許可することは、一部の標準に準拠していないため、他の理由でこれらのユーザーを削除する必要がある場合があります。
2016 年にはわずか数パーセントであり、低下しています。SSL を使用してすべてのユーザーをサポートする必要がある場合は、動的に切り替える必要がありますが、大多数だけが必要な場合は ... 確かに.
私はこれに答えるのが遅れていますが、この種の解決策に興味があるかもしれないすべての読者のために. サーバー側の機能を使用してブラウザーと OS を検出し、訪問者に「Chrome や Firefox などのオンライン ショッピング用の安全なブラウザーをインストールして使用し、ダウンロードしてインストールするためのリンクを提供してください」と伝えるだけです。
これは、お客様のショッピングを安全にする最善の方法であり、SNI 対応の SSL の使用と、お客様の「安全なショッピング」という 2 つの目的に役立ちます。サーバーが SNI 対応の SSL を使用しているかどうかに関係なく、XP の古いブラウザーは実際には安全ではないためです。
XP で古いバージョンの IE を使用しているユーザーの割合は、米国では 5% 未満であり、他の国では無視できるか、またはゼロであるため、これを危険にさらす可能性があります。実際、他の国の人々はオープン ソース ブラウザに慣れています。
私自身の経験では、私は自分自身と多くのクライアントのために多くの Web サイトをホストしており、専用 IP を使用せずに SNI テクノロジを使用してすべての Web サイトに SSL を使用しており、多くの国で人々がクロムまたはファイアフォックスに移行していることを確信しています。米国では、それらの 95% です。
不正確な情報をお許しください。
http://caniuse.com/#feat=sniによると、現在 SNI は 97.6% のブラウザーでサポートされています。