SSL/TLS で Namebase のバーチャルホスト 2009

加藤泰文

この資料は 2008 年 7 月 12 日にまっちゃ139勉強会の LT でお話したものを少し更新したものです．

自己紹介

• 加藤泰文 (かとうやすふみ)
• こんなシグネチャ，アイコンで出ています．
• wassr:@tenforward
• twitter: @ten_forward
• Plamo Linux メンテナ
• Asterisk ユーザ会 (大阪で勉強会やってます!!)
• Jetspeed-2 ドキュメント翻訳
• SD 誌 12 月号に少し記事を書きました．

今日のネタ

• SSL でネームベースのバーチャルホストをやる方法の紹介．
• ネット上を検索したら情報たくさんあります．
• 間違い，補足どんどんしてください．

今は昔

• 「SSL でネームベースのヴァーチャルホスト」は Apache-Users ML なんかの FAQ だったような．
• 「卵が先か鶏が先か」
• HTTP 1.1 の Host ヘッダ (or Request-URI) を送るときには，既に SSL/TLS の証明書は送られた後．
• どうにかならないの?

解決法

1. ワイルドカード証明書
2. subjectAltName
3. Server Name Indication (RFC 5246, draft-ietf-tls-rfc4366-bis-06)
4. Upgrading to TLS (RFC 2817)

ワイルドカード証明書(1)

• 昔からありました．でも...
• 実はきちんとした規格がない．実装結構バラバラ．
  • RFC 2595 (Using TLS with IMAP, POP3 and ACAP)
    

    - A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.

  • RFC 2818 (HTTP Over TLS)

    Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

  • RFC 4513 (Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms)

    The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.

ワイルドカード証明書(2)

• 肝心の RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)
  • 記述ありません．(ヲイ)
  • かすかに

    the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification.

    という記述で subjectAltName の所に「取り扱わない」と．:-p (肝心の Subject は?)

ワイルドカード証明書(3)

• JPNIC News & Views vol.536【臨時号】2008.4.9に「第71回IETF報告 [第4弾] セキュリティ関連WG報告」として，

  Stefan Santesson氏(Microsoft社)が発表を行いました。 Netscapeがきっかけを作ったワイルドカード証明書への対応ですが、IEをはじめとして利用できる プラットホームが増えるとともに、著名なCAサービス(認証局)がワイルドカード証明書を発行する ようになっている状況の一方で、ワイルドカード証明書をPKIX標準としては認めていないという現 状が報告されました。 このような状況を鑑み、Santesson氏は i. Informational RFCを発行する ii. 3280bis(がRFC化された後に修正し)ワイルドカードの存在を認める のどちらかを行うべきだと提案しました。 :(略) この議論に関しては、ML上などで継続されることになりました。

ワイルドカード証明書(4)

• ワイルドカード証明書を発行するサービスは結構ある．
  • 発行してくれるものとしては "*.example.com" というような，組織のホスト名部分がワイルドカードになっているもの．
  • 当然，複数のドメインをカバーする証明書を発行してくれる所はない (と思う)．
  • 規格はないけど，別に Subject (の CommonName) が "*" とか "*.com" とかの証明書も発行しようと思えば出来る．
  • でもそんないい加減な証明書も，その証明書を発行する CA も信頼したくないよねー
  • そんないい加減な証明書，ブラウザでちゃんと検証通る?

ワイルドカード証明書(5)

• 試しにオレオレ認証局で，その手のいい加減な証明書を作成し，ブラウザが受け入れてくれるか試してみました．
• 調べたもの (偏っててすみません)
  • Firefox 2 (Linux)
  • Firefox 3 (Linux)
  • Opera 9 (Linux)
  • Internet Explorer 6 (Windows 2000)
• Firefox と Opera は同じような動き．
• IE は独特．

ワイルドカード証明書(6)

• 検証方法:
  matcha139.oreore.test というホストに対する証明書として，色々なパターンの CommonName を持つ証明書を作成し，各ブラウザでアクセス．
• 結果:

  	*	*.test	*.oreore.test	m*.oreore.test	*9.oreore.test
  IE6	x	x	○	○	x
  Firefox3	○	○	○	○	○
  Firefox2	○	○	○	○	○
  Opera9.27	○	○	○	○	○

ワイルドカード証明書(7)

• 各ブラウザの実装
  • IE
    http://support.microsoft.com/kb/258858/en-us/

    As described in RFC 2595, Microsoft's implementation allows a * in the leftmost element of the server's CN only. Within that leftmost element, there can be text to the left of the * but not to the right.

  • Firefox, Opera
    なんでもアリ．(動きを見る限りは)

Subject Alternative Name

• X.509 v3 証明書拡張に定義 (RFC 5280)
• RFC 2818 (HTTP Over TLS) で

  If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

• subjectAltName を定義した証明書を発行してくれるサービスは?
  • CSP SSL (http://cspssl.jp/)というサービスが発行してくれるようです．(複数の CN も設定してくれる模様)
  • グローバルサイン の SSL 証明書は，www.example.com と example.com の両方で使えるように subjectAltName を設定してくれるっぽい．

Server Name Indication(1)

• RFC5246 (TLS 1.2) で定義．ただし，SNI の定義自体は draft-ietf-tls-rfc4366-bis-06.txt に．
• TLS ハンドシェイク中でクライアント側からサーバ名を送る (ClientHello メッセージ中)．
• クライアント
  • Firefox 2 以上
  • Opera 8 以上 (8 台は設定で TLS1.1 を有効にする必要あり．Wii, Mobile は非対応)
  • IE 7 以上(Vista以降)
  • Safari (Mac OS X 10.5.6 以降, Windows Vista 以降)
  • Google Chrome (Windows 版の 6 以降は Windows のバージョンに関わらず対応)
  • curl 7.18.1 以降

Server Name Indication(2)

• ツールキット
  • GnuTLS
  • OpenSSL
    • 0.9.8f 以降．(0.9.8h より前は SNI 関係の脆弱性あり)
    • config 時に enable-tlsext オプションを指定する必要あり．(0.9.8j 以降デフォルトオン)

Server Name Indication(3)

• サーバ
  • mod_gnutls
  • Apache 2.2.12 以降 (それ以前用パッチあり)
  • stone
• Apache 2.2.12 での設定例．
  

    Listen 443
    NameVirtualHost *:443
    SSLStrictSNIVHostCheck off
  
    <VirtualHost *:443>
      SSLEngine On
      ServerName kirk:443
      DocumentRoot /var/www/html/kirk
      SSLCertificateFile /etc/httpd/certs/kirk.crt
      SSLCertificateKeyFile /etc/httpd/private/kirk.key
    </VirtualHost>
  
    <VirtualHost *:443>
      SSLEngine On
      ServerName spock:443
      DocumentRoot /var/www/html/spock
      SSLCertificateFile /etc/httpd/certs/spock.crt
      SSLCertificateKeyFile /etc/httpd/private/spock.key
    </VirtualHost>
      
      

Upgrading to TLS (1)

• Upgrading to TLS Within HTTP/1.1 (RFC 2817)
• STARTTLS みたいなもの (?)．
• 普通に http でアクセスした後，TLS に Upgrade するので，TLS に移行する前に VirtualHost の選択可能．
• ブラウザの対応はまだ．
• サーバ側，Apache 2.2 は対応済．

Upgrading to TLS (2)

• Apache 2.2 での設定例
  

  NameVirtualHost *:80
  <VirtualHost *:80>
    ServerName  test.example.com
  
    SSLEngine   Optional
  
    SSLCertificateFile /etc/httpd/server.crt
    SSLCertificateKeyFile /etc/httpd/server.key
  
    <Directory /var/www/rfc2817>
       SSLRequireSSL
    </Directory>
  </VirtualHost>    
      

Upgrading to TLS (3)

• これでブラウザでアクセスすると．．．
  

  HTTP/1.x 426 Upgrade Required Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.8e PHP/5.2.3 Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade, Keep-Alive Keep-Alive: timeout=5, max=100

  という感じで応答が返ってきてました．
• それっぽく動いているが，合っているのかは謎．(^_^;)
• KeepAlive の有無とか，色々動き複雑そう...

まとめ

• 色々やってみました．
• 現時点で一番すっきりしているのは subjectAltName．
• 将来的には SNI or subjectAltName がわかりやすそうですね．
• Upgrading to TLS はなんか動き複雑そう．
• ワイルドカード証明書は規格化されてないのでイマイチすっきりしないですね．
• 今後の動向を注意しておきましょう．

参考文献

• Name-based SSL virtual hosts: how to tackle the problem
  http://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
• 名前ベースのVirtualHostでそれぞれのSSLサーバ証明書を使う (Takayuki Nakamura's blog)
  http://websec-memo.blogspot.com/2007/07/virtualhostssl.html
• stone に に Server Name Indication (TLS 拡張) 機能を実装 (仙石浩明の日記)
  http://blog.gcd.org/archives/51007168.html
• Upgrading to TLS(RFC2817)の設定をApache2.2にしてみる (でびぞー徒然日記)
  http://debz-di.kabocha.to/archives/2007/06/20070616212947.html
• SNI in 2.2.9? (Re: 2.2.9 status)
  http://marc.info/?l=apache-httpd-dev&m=121250416924708&w=2

参考文献(2)

• RFC 2817 和訳 (IPA)
  http://www.ipa.go.jp/security/rfc/RFC2817JA.html
• RFC3546 和訳
  http://www21.ocn.ne.jp/~k-west/SSLandTLS/draft-ietf-tls-extensions-05-Ja.txt
• ウェブブラウザの SNI 対応 - doda の日記
  http://slashdot.jp/~doda/journal/495893
• defiantの日記
  http://d.hatena.ne.jp/defiant/
• Use SSLClientSocketNSS on Windows (Chromium Project)
  http://code.google.com/p/chromium/issues/detail?id=28744
• その他 "SNI SSL" とか "subjectAltName" とかそれらしいキーワードで検索するとたくさん出てきます．

ご清聴ありがとうございました．