SNI 延命策５： SNI SSL OpenID まず、SNIってなんじゃ、ということですが、Server Name Indication の略で、 ようは、SSLで Name Based virtual hosting をする規格です。 HTTPのレイヤーではなく、SSLのレイヤーでやっているので、 原理的には、SSLを使っているなら、どんなアプリでも Name Basedになるような気がします。 たとえば、SSH の Name based virtual hosting とか、 わけのわからない展開も 多分、可能になるんだと思いますが、 実際はどーよ。 現在、サーバ側（ホスティング業者とか）における、IPアドレスの 需要の多くが、 SSL（＝HTTPS)の関係です。 SSLをやるには、いまのところ1ドメイン1IPアドレス必要なんですが、 これを解決するのがSNIで、IE7以降およびFF2以降で使えます。 いまのところ対応ブラウザの普及率の問題があるのでアレですが、 あと10年もすればなんとかなるでしょう。 それとも、いま（2008年）、 IE3とかをサポートする必要があると思いますか？ SNI非対応のIE6とかも、 これと同じく、いずれはサポートしなくていい レベルになるでしょう、多分。 もうひとつ、このからみでイケるかな、 というのは、OpenIDですね。 いま、（ミエならともかく）現実問題としてSSLを必要とする 用途って、 会員制サイトのID/PASSと、もうひとつ、 クレジットカードでの課金なんですが、 後者は、課金専用サイトを使えばいいんで、フツーのサイトでは問題なし。 （というか、IPアドレス問題よりも課金処理の信頼性維持のほうがよほど面倒）。 で、ID/PASS問題ですが、これ、実は、OpenIDを使えば、 SSLを使わなくてもセキュアに認証できるんですわ。 （OpenIDのプロじゃないので間違っていたらご指摘よろしく）。 正確には、サイトとOpenIDサーバはSSLですし、 ユーザとOpenIDサーバもSSLなんですが、 ユーザとサイトはノーマルでOKです。 当然、OpenIDサーバは独自IPアドレスが必須 （またはSNI対応ブラウザ前提）となりますが、 OpenIDサーバなんて数は非常に少ない（全世界でせいぜい数十万個）なんで、 ぜんぜん問題なし。 こまかいことをいうと、会員制サイトをOpenIDで認証して非SSLにすると、 クッキーが読み取られてセッションハイジャックされる リスクはあるかもしれないが、 この場合、IPアドレスの同一性も必要なことなどを勘考すれば、 金融、医療関係などを除けばどーでもいいとおもう。 まあ、どーしても気になるなら、 会員情報の変更とか、セキュリティ的に重要なところに関しては、 OpenIDで再度認証するんだね。で、その領域はクッキーの期限を短く切る。 これだけでもだいぶ安全になるでしょ、知らんけど。