HTTPS: ”S”の代償


[The Cost of the “S” in HTTPS](https://www.cs.cmu.edu/~dnaylor/CostOfTheS.pdf)
 Naylor, et al., 2014　の　個人的なまとめです。

コメントに、今後のHTTP通信について意見などをカジュアルにいただけると幸いです。

# Abstract
セキュリティとプライバシーの問題により、HTTPSが広がってきた。しかしながら、下記のような弊害もあるかもしれない。

* インフラコスト
* 通信遅延
* データの使用量
* エネルギーの消費

キャッシュや、ウイルススキャンのようなアプリケーションレイヤーのコンテンツが必要とした付加価値は不透明な暗号化された通信に対しては効果が無い。

![Screenshot 2015-04-01 13.09.49.png](https://qiita-image-store.s3.amazonaws.com/0/6410/8fb43d64-bd48-880e-ad12-6690d9fb85d2.png "Screenshot 2015-04-01 13.09.49.png")
(Source: Naylor, et al., 2014)


## この論文の貢献
* 上記のようなコストを明らかにすること
* ISPの3年間のデータの分析しHTTPの増加を調べる
* 直接的、間接的なコストを明らかにする


## HTTP と　HTTPSのコミュニケーションの違い
![Screenshot 2015-04-01 13.13.16.png](https://qiita-image-store.s3.amazonaws.com/0/6410/6ee741e8-7301-6399-2795-4e09bc7c0dd9.png "Screenshot 2015-04-01 13.13.16.png")
(Source: Naylor, et al., 2014)
 
HTTPSではtransport層が暗号化を提供してくれるので、安全なコミュニケーションが可能である。一方このセキュアな通信のために、コネクションを確立した後、クライアントの鍵を交換するために1回多くの通信をしなければならない。
 
## HTTPSの使用率の変化
![Screenshot 2015-04-01 13.20.48.png](https://qiita-image-store.s3.amazonaws.com/0/6410/115c1cb9-d9de-b79b-98c8-6cd8240f469c.png "Screenshot 2015-04-01 13.20.48.png")


![Screenshot 2015-04-01 13.21.11.png](https://qiita-image-store.s3.amazonaws.com/0/6410/09bd41a2-d42e-5483-6106-729c412eac5e.png "Screenshot 2015-04-01 13.21.11.png")
(Source: Naylor, et al., 2014)


データセットはヨーロッパのとある大きなISPで取得した25,000 の住民のADSLのトラッフィク
図3によると2014, Sepには44.3%のコネクションがHTTPSである。4月の大きな変動は[Facebook](http://goo.gl/B7U3jv)がHTTPS通信をすべてのユーザに対してdefaultにしたからである。2014, JanにはYoutubeがHTTPS越しにvideoストリーミングを始めた。Youtubeでは2014, Sepには50%のトラフィックがHTTPS越しに配信されている。


図4によると2014の80%がHTTPSを使いアップロードが行われている。
2012年には45.7%だったことと比べると大きな変化である。一方ダウンロードの方は、増加は著しくない。ただし、Youtbeにより2014年の増加の割合は前年の増加率の倍以上となっている。


## HTTPSの代償

### ServerSide
* セッションの暗号キーの計算 (具体的な実験はなし)
* SSL/TSL証明書発行の代金


### ClientSide
* RTT(Round Trip Time)による遅延
* Proxyキャッシュ, セキュリティの恩恵がなくなる
* デコードに伴う電力消費 (実験の結果それほど影響があるとはいえない)

#### キーを交換する際に起きるリクエストによるRTT増加に伴う遅延
![Screenshot 2015-04-06 12.04.56.png](https://qiita-image-store.s3.amazonaws.com/0/6410/2e9910d9-4f64-4938-4562-cfffac161ead.png "Screenshot 2015-04-06 12.04.56.png")
(Source: Naylor, et al., 2014)





実験環境は3GのUSBモデムとファイバー接続の2種で実験
図5, HTTPSにすると3G回線が大きく影響を受けている。90%以上のwebページが500ms以上の遅延を被ることになる。40%のページが500msの差(1.3x)が生まれる。ファイバーの場合は40%のページはほとんど影響をうけない。

### TLS Handshake 遅延コスト
![Screenshot 2015-04-01 14.33.01.png](https://qiita-image-store.s3.amazonaws.com/0/6410/5f9ff7c5-eda8-58e9-09a5-7966999d4dec.png "Screenshot 2015-04-01 14.33.01.png")
(Source: Naylor, et al., 2014)

2014 April 3rdの1時間のみのデータを分析対象にする。これには100万のTLSが含まれていた。メジャーなサービスのみを分析する。
図7の左、RTTが100ms以上はヨーロッパの外通信している。ここで注目したいのが、サーバが近くともhandshakeの時間はすべてのデータで多くなている。
図7の中央の確率分布 (Cumulative Distribution Function)を見るとGoogleが10%が300msが超えるがTLSのhandshakeに時間が短いことがわかる。たとえばTwitterは50%以上が300msを超える遅延がある。5%のリクエストが最低でもRTTよりも10倍長い遅延を経験する。


### Proxyへの影響
#### キャッシュ
#### データセット
* Transp-Proxy: 2000万人のサブスクラーバがいる。過去2年間のデータを分析
* OptIn-Proxy: 2000個のモバイルのサブスクラーバがいる2014 Mayから1週間分のデータを分析

##### キャッシュによる削減
* Transp-Proxy: 1TB / day
* OptIn-Proxy: 1.3GB / day

Transp-Proxyの過去2年間のキャッシュヒット率は14.9%(データ量にすると15.6%), 1日2TBのデータを各Proxyが300万人へ配信していた。
OptIn-Proxyでは1.3GBを削減していた。


#### 圧縮
圧縮されていないデータをProxyでgzipなどで圧縮し、クライアントへのデータ量を削減していた。TranspProxyの圧縮率は28.5%であった。


HTTPSになると上記ができなくなる。一方、[Trusted Proxy](http://goo.gl/BUxQ22)という仕組みが提案されている。　リンク

### 電力消費費
![Screenshot 2015-04-01 15.13.36.png](https://qiita-image-store.s3.amazonaws.com/0/6410/0465c062-1ece-60ba-b42b-fb895f844bbb.png "Screenshot 2015-04-01 15.13.36.png")

(Source: Naylor, et al., 2014)
#### シュミレーション

* Galaxy SII で3GとWiFiで実験
* データサイズは1kB to 1MB
* それらをwebサーバにホストしダウンロード

この実験に関しては、違いは標準偏差の粋をでない。

#### CNNのデータを使用した電力消費の実験
![Screenshot 2015-04-01 15.18.24.png](https://qiita-image-store.s3.amazonaws.com/0/6410/8d8cda8a-0351-3ceb-7e88-addf1a610be8.png "Screenshot 2015-04-01 15.18.24.png")

そこまで大きな変化はない。


### 付加価値のあるサービス
影響があるサービスネット上のサービス

* DPI(Deep Packet Inspection)を使ったセキュリティ
* URL fiterling
* tracking cookies

これらのネットワークの中のサービスはHTTPSの暗号化によって影響を受ける。下記のことが暗号化によりできなくなる。

* DPI

パケットのコンテント見ることによってネットワーク上で脅威をふせぐことができる。また、単純なDDoSアタックも防ぐことができる。

* URL filtering

IWFを通した直接的な通信は5%しかないが、Internet Watch Foundation9のようなブラックリストで、多くの電気通信会社はフィルタリングをしている。


* tracking cookies

このようなことをできなくすることがTLSが導入された目的であるがoptin のサービスでユーザをトラッキングすることができなくなる。


# 結論
オンラインのプライバシーの意識の増加から、HTTPS通信は増えている。しかしながら、モバイルネットワークに致命的である遅延は増加する。また、ネットワーク上のサービスは暗号化されたデータに対してなにもできない。たとえば、あるproviderでは1日あたり2TBのデータをキャッシュができなくなる。これは最大で30%の電気消費の増加につながる。付加価値があるウィルススキャン、アクセス制御のようなサービスに影響がある。しかし、どの程度かは不明瞭である。明確なのはHTTPSを使う時代が来てしまったこである。我々が今後すべきこととして重要ななこと2つある。１つは低レベルでのHTTPSによる負の影響のギャップを抑えること。例 Google [“0-RTT”](http://blog.chromium.org/2013/06/experimenting-withquic.html) 2つ目は、ネットワーク上の付加価値のあるサービスのHTTPS環境でも使えるようにすることである。これは[Trusted Proxy](http://goo.gl/BUxQ22)のようなものが大きな役割を果たすだろう。