More Related Content
Similar to Node-v0.12のTLSを256倍使いこなす方法 (20)
More from shigeki_ohtsu (15)
Node-v0.12のTLSを256倍使いこなす方法
- 2. 自己紹介
• 名前: 大津 繁樹
• 所属: 株式会社インターネットイニシアティブ(IIJ) アプリケーション開発部
• Twitter: @jovi0608
• ブログ: ぼちぼち日記 http://d.hatena.ne.jp/jovi0608/
• GitHub: https://github.com/shigeki/
• 新技術の検証・評価を行ってます。 (Node.js, SPDY, HTTP/2,HTML5)
• iij-http2の開発を通じてIETFのHTTP/2標準化作業に参画中
• Node-v0.11.x へのパッチ提出はわずか。でもほとんどTLS関連です。
- 3. TLS (Transport Layer Security)の利用状況
TLS通信
認証、暗号化、
改ざん防止
図参照 https://plus.google.com/+IlyaGrigorik/posts/7VSuQ66qA3C
GoogleによるChromeの統計調査
から、ここ2年間でhttpsサイトへ
のナビゲーションは28%から58%
に増加
- 5. 発表内容
• NodeのTLSモジュール大改造
• TLSSocket
• AES-NI
• PFS (Perfect Forward Secrecy)
• TLS False Start
• TLS Ticket
• OCSP Stapling
• TLS Dynamic Record
• SPDY, HTTP/2
• SPDYのメリットが一番よくわかるデモ
Node-v0.12でTLSを使うために有用な情報をお伝えします。
(でも256個もないです)
(注1: Node-v0.12はまだ未リリースですが、2014/11/10時点のv0.12ブランチHEADを対象としています。)
(注2: Node-v0.11.xはまだPOODLE対策がされていません。SSLv3を無効化するために、
secureOptions: require(‘constants’).SSL_OP_NO_SSLv3) をサーバオプションに追加しましょう。)
- 9. TLSSocket
• Node-v0.10までの CleartextStream の替わり
• CleartextStreamのAPIの互換保持
• ちゃんと net.Socketを継承し、APIを完備
• TLS周りの通信に関する新規機能のAPIを追加
より直観的でわかり易くなった。
EventEmitter
Stream
Readable Writable
Duplex
Socket
TLSSocket
- 10. AES-NI (Advanced Encryption Standard New Instructions)
• Intel, AMDのCPUに搭載されているAES暗号の処理機能
• 最近のモデルには多く搭載されている。/proc/cpuinfo で確認
• openssl-1.0系に実装済。Node-v0.10.x, v0.11.xでも使える
• 環境変数でAES-NIの有効・無効化してNodeのcryptoのベンチ比較
AES-NI有効時 AES-NI無効時
22.8469
Gbit/sec
9.51245
Gbit/sec
AES-NI付きCPUのサーバを選んで使いましょう
AES-NIで2.4倍に性能向上!
- 11. PFS(Perfect Forward Secrecy)
• セッション毎に一時的に有効な公開鍵を交換して暗号鍵を共有す
る方式
• 証明書の秘密鍵が危殆化しても過去の通信データを復号化できな
い。今後主流となる鍵交換方式。
• Node-v0.12から ECDHE, DHE の2種類が利用可能
• ECDHEの方が性能が良いのでそっちを優先指定(デフォルト)
• ECDHEはデフォルトで何もせず利用できる。(prime256v1)
• DHEの利用dhparamファイルを生成と指定が必要。現状十分な強
度を持つには2048bit長以上で生成すること。
- 16. OCSP Stapling
• OCSP (Online Certificate Status Protocol):
• 証明書が失効していないか確認するプロトコル
• TLS初期接続時にクライアントが認証局サーバに確認。オーバヘッド
• OCSP Stapling:
• TLSサーバがOCSPレスポンスを証明書とともにクライアントに送信
• クライアントが認証局に確認する必要がない。Web表示の高速化
OCSP
Response
証明書+OCSP
Response
ClientHello +
status_request_v2 ext.
- 17. NodeでOCSP Staplingを使う
• Node-v0.12では OCSPRequest イベントを新設
• コールバックの引数にOCSPレスポンスデータ
を渡し、クライアントに送信
• 認証局のOCSPサーバにリクエストするのは結
構面倒なので、opensslで事前にリクエスト
データを作成すると良い
• OSCPレスポンスデータのキャッシュ管理も必
要。更新日時を取得するasn.1パーサも必要。
エラー時の処理判断も大切。
• 別途cronでOCSPレスポンスデータを管理する
手もある
server.on('OCSPRequest', function(cert, issuer, cb) {
var now = Date.now();
if (now > cache.nextUpdate && !cache.lock) {
cache.lock = true;
cache.der = null;
HandleOCSPrequest(cb);
} else {
var msg = cache.der ? 'cache hit!': 'terminated';
console.log( 'OCSP Response:', msg);
cb(null, cache.der);
}
});
ソースは、https://gist.github.com/shigeki/de5748cc0deb980bcb35
結果は openssl s_client –status –connect site:443 で確認
- 18. Dynamic TLS record (setMaxSendFragment)
• GoogleのIlya Grigorik氏が推奨しているTLSパラメータのチューニング手法
• 通常TLSに書き込まれるデータ長は、レコードサイズ最大の16Kであることが多い。
• 最初のレスポンスデータの取得は、16Kバイトを受信してからになる。
• 最初のデータを復号化するには10個のTCPパケット(1.5K)を受信が必要。
• TLSのレコードサイズをTCPの1セグメントのサイズに収まるように小さくすれば受信した1個目か
らデータの復号化が可能になる。
• よって受信したデータの1バイト目が表示される時間の短縮が図られる。
1.5K 1.5K
16K
これ一つで
復号可能よ
16K全部受信しな
いと復号できない
- 19. NodeでTLS Dynamic Recordをやるには
• Googleサーバでのチューニング方法(ATSで採用済)
• 最初は 1.3Kのレコードサイズ (1500 - 40 (IP) - 20 (TCP) - 40 (TCP options) - TLS overhead (60-100))
• 1Mバイト送信したらデフォルトの16Kに変更。
• 書き込みのアイドルが1秒以上になったら1.3Kに戻す。
• Nodeでは自動的にレコードサイズをチューニングする方法は不採用に
• 替わりに固定的に変更するAPI(setMaxSendFragment)を新設
• 1.3Kで固定すると大きいデータで分割オーバヘッドが高くなる可能性も。
server.on('secureConnection', function(tlsSocket) {
tlsSocket.setMaxSendFragment(1300);
});
- 21. SPDY, HTTP/2
• SPDY
• Googleが開発したWebの表示を高速化するプロトコル(TLSのみ)
• Google/Twitter/Facebook/Yahoo.comで使用中
• Chrome/Firefox/IE10/Safari 多数のブラウザでサポート中
• Nodeで使うなら node-spdy を使いましょう
• HTTP/2
• SPDYをベースとした次期HTTP仕様(TLS利用が中心)
• HTTP/1.1のセマンティクスを互換保持
• 現在仕様化作業の大詰め。来年前半には完了予定
• 現在Firefoxとのテストで利用中のnode-http2が使える
• 注意事項:
• node-v0.10で利用するとTLS要求仕様(AEAD+PFS)が合わず接続できない場合があります。node-v0.12を使いま
しょう。
• ただ開発は0.10系でやっているので未サポート
• ALPNはまだopensslのベータなためnodeでは使えません。
• 使う場合には私のfork版があります。 https://github.com/shigeki/node/tree/alpn_support
Ethernet
IP(v4/v6)
TCP
TLS
HTTP/2 Frame Layer
HTTP/1.1 Semantics
- 23. HTTP Head of Line Blockingを回避
HTTP/2クライアント
画像サーバA
画像サーバB
Reverse
Proxy
HTTP/2
多重化通信
レスポンス
が速い
レスポンスが
遅い
HTTP/1.1クライアント
TCPを6本張れるけど、1本中
に同時1リクエストの制限
1本のTCP