JANOG 35.5でお話しした「ストリーミングのTLS(SSL)化」についてのサポートページです。プレゼンテーション本体では、ストリーミングのHTTP化（さらにはTLS化）と帯域制御について話す予定です（その他の一般的な所については以下のリンク等を参照してください）。
プレゼンテーション資料はSlideshareに置きました：
発表のustreamアーカイブは以下にあります：
SSLの基本
別に記事を連載しています。以下のページを参照ください。
TLS1.3のドラフトは以下です。そして、SNIの暗号化については、このドラフトに含まれていません（WGで議論されていることは事実ですが、標準になるかは不明です）：
SSLのトレンド
各種影響（SSLのトラフィック比率、SSLハンドシェイクによる遅延、SSLによるトラフィックの増加、消費電力の増加）についてサーベイを行った論文です。
Netflixも近々（2015年中？）にストリーミングのSSL化に踏み込むようです。
- 元メール by Mark Watson (Netflix Director)
- 業界記事
透過型キャッシュについて
昔（1998年）書いた資料ですが参考に
MPEG-DASH
仕様書（ISO/IEC 23009-1 “Dynamic adaptive streaming over HTTP (DASH) Part 1:Media presentation description and segment formats”）は、ISOであるため有償です。以下のページから購入できます：
ブラウザがMPEG-DASHをサポートしているかは、以下のリファレンスプレイヤを実行してみてください：
関連法規
ISPキャッシュと著作権
「ISPキャッシュにおける著作物の複製」が著作権の複製権を侵害しないことについては、著作権法第47条の5（送信の障害の防止等のための複製）が根拠となっています。
しかし、著作権法自体では、ISPキャッシュについて明確に著作物の複製が許されているわけではなく、以下の業界紙に文化庁長官官房著作権課が寄稿した「法文の解釈」が根拠として扱われている状況です。
- 「著作権法の一部を改正する法律（平成21年改正）について」、月刊コピライト2010年1月号、公益社団法人著作権情報センター
また、経産省が行った情報大航海プロジェクトの成果文書である「情報大航海プロジェクト・事業者向け解説書」に、このあたりの解説が含まれています：
さらに、文化庁は以下のページで、平成21年の著作権法の改正について解説しており：
このページに含まれるＱ＆Ａにおいて以下のように説明しています：
- 「インターネット上の通信を行う上で，頻繁なアクセスに効率よく対処するためのキャッシュサーバーや，情報を安定的に提供できるようにするためのミラーサーバー，バックアップサーバーなどの仕組みが通信事業者等にとって必須となっています。<鍋島略> 。本改正は，通信の効率化や安定性の向上のための取組に萎縮効果を与えないよう，このような複製は権利者の許諾なく行えることを著作権法上明確化するものです。」
しかし、実際には、以下のようにミラーサーバ等とISPキャッシュには大きな隔たりがあります：
- 配信側が行う複製（ミラーサーバ、バックアップサーバ）：著作権法で明示的に許されている
- ISPキャッシュ：解釈すれば許される（業界紙への寄稿が論拠）
また、改正当時（2009年）において、著作者の意図（キャッシュ不可）を無視するISPキャッシュはそれほど普及しておらず、これらの（著作者の意図を無視してキャッシュする）行為まで、著作権法の解釈により許されるという意見には、無理があると思われます（鍋島意見）。
さらに、ISPによるコンテンツの強制トランスコードについては（「ISPがコンテンツをキャッシュするだけ」についても明確に許されていない状況であり）、著作権の侵害だと思われます（鍋島意見）。
参考
帯域制御と電気通信事業法
電気通信事業者は、電気通信事業法第6条（利用の公平）により、通信に対して差別的な取り扱いを行うことはできません：
一方、昨今のトラフィック増加（および固定通信の場合は定額制の普及）により、電気通信事業者の収益が悪化しています。そのため、電気通信事業者の業界団体が主催する（総務省はオブザーバーとして参加）帯域制御の運用基準に関するガイドライン検討協議会で、帯域制御の運用について話し合いが行われ、現在、以下のガイドラインが発行されています：
つまり、「このガイドラインに従う帯域制御の運用については、電気通信事業法に違反しない」というのが、今の日本における状況といえます。ただし、このガイドラインに含まれる帯域制御の対象としては、以下の2種類だけであり：
- 特定のアプリケーション（P2Pファイル交換等）
- 特定のユーザ（ヘビーユーザ等）
特定（大量のトラフィックを発生させる）CPやIPアドレスに対する帯域制御は含まれません。そのため、CPやIPアドレスに対する帯域制御は、電気通信事業法的にグレーゾーンであると言えます。また、このガイドラインは、通信事業者の業界団体が定めたものであり、CP側の意向を反映したものではありません。そのため、ネットワークの中立性議論の視点でみると、このガイドラインは通信事業者側だけで決めたルールと言え（そのため、個別CPとは関連しない対象（アプリケーションやヘビーユーザ）に対する帯域制御だけが含まれる）、この協議会では、個別CPに対する帯域制御について日本全体のコンセンサスを得ることはできず、CP側の業界団体を交えた形の協議会が必要であると思われます（鍋島意見）。
偽証明書と不正競争防止法
暗号の強制解読については、不正競争防止法の対象となります。
HTTPストリーミング配信サーバのパフォーマンス
Netflixが積極的に情報を開示しています：
- 非SSLのサーバパフォーマンスは40Gbps/1台程度：
- 2014年におけるチューニングでは、数倍程度の負荷増加（ざっくりとした話）：
- もっと詳細に調べた結果を論文化したもの（2倍程度の負荷増加、kernel sendfile内でssl処理を行ってもドラスティックな パフォーマンス向上はない。ただし、行うべきチューニング項目はまだあり、更なるチューニングで負荷を下げられる可能性がある）：
偽証明書
SSL通信をMITM的にモニタリング・変更するために、偽証明書が使われる場合があります。この場合、端末のエラー表示を避けるためには、ルート証明書を端末にインストールする必要があります。
Gogo社（飛行機内Wifiサービス）における偽証明書の利用（ルート証明書のインストールなし）
Lenovo社のPCにSuperFish（ルート証明書をインストールし、偽証明書によりSSL通信のモニタリングを行う）がプレインストール
Squidにおける実装（システム例）
- SSL Peek and Splice (旧 SSL Bump)
HTTP/2で、きちんとやろうというRFC Draft（プロトコル例）
Ｑ＆Ａ補足
当日のＱ＆Ａ補足です：
古いWebサイトのSSL運用コスト
- Q:更新は無いが運用を続けたいWebサイトについて、SSL証明書の費用やSSL関連セキュリティパッチ適用などの運用コストをかけ続けるのは辛い。
- A:最近のCDNは、安価なSSLアクセラレータとして使用できます。つまり、オリジンサイトは非SSLとして運用し続け、そのフロントにSSL CDNをかぶせることで、サイトのSSL化が実現できます。そして、SSL証明書については、CDN事業者のマルチドメイン証明書を利用することで、更新等の手間を省けます。また、最近のCDNでは、SSL配信費用および証明書費用も安価（サービサーによっては無料）です。
SSL化によるライブ配信の遅延
- Q:ストリーミングをSSL化すると、暗号化処理等によりライブの遅延が大きくならないか？
- A:まず、Mpeg-DASH等のHTTP系ストリーミングの欠点として、ライブの遅延が大きいことがあります（最良でも4秒、実際には数十秒）。これに対し、SSLハンドシェイクに必要な時間は、（ざっくりと）1秒もかからないため、大きな影響は無いと言えます。
- 補足：SSLハンドシェイクの遅延は、理想的にはRTTの2倍＋α程度ですが、前述の論文によると2～20倍程度までばらつくようです（20倍等の大きなものは、CRL確認による遅延が原因だと思われます）。
Open Reverse Cache
詳細は、別の場所でお話できればと思います。