Upload
kaoru-maeda
View
557
Download
0
Embed Size (px)
Citation preview
https://lepidum.co.jp/ Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.
IETF95 Buenos AiresHTTP2関連レポート
株式会社レピダム
前田薫 (@mad_p)
IETF95報告会 2016/05/10
IETF95報告会2016/05/10
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Agenda
WG
dispatch
httpbis
oauth, httpauth
IETF95
Buenos Aires, AG
Apr 2-8, 2016
IETF95報告会2016/05/102
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
自己紹介
名前 前田薫@mad_p
所属 株式会社レピダムシニアプログラママネージャ
コミュニティー活動 Lightweight Language
Identity Conference
http2study
業務領域
認証・認可、デジタルアイデンティティー、プライバシー
標準化支援
ソフトウェアセキュリティー、脆弱性
IETFとの関わり
IETF89 Londonより
ART, SECエリア中心
IETF95報告会2016/05/103
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
dispatch: ART エリア概要
概要 ARTエリアのエリアWG 月曜朝イチにAPPS全体を見渡すセッション
トピックス AD交代: Barry → Alexey appsawg MLを存続 リアルタイム系の話が多かった draft-seantek-mail-regexen-00
Email validationの正規表現 議論は炎上、BCPではない、やるならInformationalで
https://www.ietf.org/proceedings/95/slides/slides-95-core-0.pdf
IETF95報告会2016/05/10
5
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
httpbis WG
概要 HTTPプロトコルの改良
HTTP/2は完了、さまざまな拡張
HTTP自体に関する新しいアイディア
Finished Documents RFC7694: Client Initiated Content Encoding
RFC7725: An HTTP Status Code to Report Legal Obstacles
RFC7838: Alternative Services
IETF95報告会2016/05/10
7
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
httpbis discussions
Secure Cookies ★Opportunistic security Character Encoding and Language for Parameters ★Client hints HTTP Encryption Content Encoding JSON Header Field Values ★ORIGIN frame and connection coalescing ★Client authentication with certificates Cache Digest Decomposing the Hypertext Transfer Protocol Merkle Integrity Content Encoding ★Secure Content Delegation using HTTP and Caching Secure HTTP Content
using Blind Caches ★印: 以降で少し解説
IETF95報告会2016/05/10
8
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Opportunistic security
draft-ietf-httpbis-http2-encryption-04 だいたい議論は終わり? .well-known/http-opportunistic の問題を検討 {
"origins": ["http://example.com", "http://www.example.com:81"],"commit": 86400
}
commit: この期間、セキュアコンテンツを提供する。commitの時間とwell-knownリソースの寿命を分離
HTTP/2 only問題 HTTP/1.1の実装の中には、TLSが使われているかどうかでURIスキームがhttpsであるか判断しているものがある
HTTP/2の:scheme pseudoヘッダもうまくいかない? → ML上でのSec-Schemeヘッダ検討へ(進行中)
IETF95報告会2016/05/10
9
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Client Hints
draft-ietf-httpbis-client-hints-00 リソースのレイアウトなど、デバイスに合わせて最適化したい。DPR
(Device Pixel Ratio), Width of the screen, or Viewportなどを使う。いままではUAを見て判定していた
RFC7234 では"Vary"ヘッダを使って、UAやクッキーに依存したコンテンツであることを示せると定義
Client Hintsはクライアントがその情報をサーバーに伝えるヘッダ群のこと DPR: 2.0 Width: 320 Viewport-Width: 320
これらの値に依存してコンテンツを作った場合、サーバーはVaryヘッダに加えてKeyヘッダも出す
サーバーはAccept-CHヘッダを送って、クライアントがClient Hintsを送ってくれれば考慮するよーと知らせることも可能
IETF95報告会2016/05/10
10
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
ORIGIN Frame
draft-nottingham-httpbis-origin-frame-01 同一のHTTP/2 connection上で、他のオリジンも提供できることを示すORIGIN frame
connection coalescingできることを明示
IETF95報告会2016/05/10
https://docs.google.com/presentation/d/1r7QXGYOLCh
4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/Ilya
11
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Client authentication with certificates
draft-thomson-http2-client-certs-02 リアクティブなクライアント証明書認証には問題があった TLS の client cert authはセッション単位
TLS を開始した後でクライアント証明書認証の必要なリソースにアクセスしたらどうする?
TLS 1.2では renegotiation; TLS 1.3では spontaneous authを使う 不統一。めんどう h2ではどのアクセスが認証を必要としたのかわからない
解決方法: 証明書検証に必要な道具をHTTP/2 Frameとして実装 request-idを導入し、対応が取れるように connection単位で証明書一覧を管理、streamごとに使う
IETF95報告会2016/05/10
12
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Client Cert Example
IETF95報告会2016/05/10
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/client_certs.pdf
13
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Secure Content Delegation using HTTP and Caching Secure HTTP Content using Blind Caches
draft-thomson-http-scd-00
draft-thomson-http-bc-00
ベースになっているのはContent-Encoding:
out-of-band
CE: OOBとは?
IETF95報告会2016/05/10
14
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
'Out-Of-Band' Content Coding for HTTP
draft-reschke-http-oob-encoding-04
IETF95報告会2016/05/10
Request:
GET /test HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, out-of-band
Response:
HTTP/1.1 200 OK
Date: Thu, 14 May 2015 18:52:00 GMT
Content-Type: text/plain
Cache-Control: max-age=10, public
Content-Encoding: out-of-band
Content-Length: 145
Vary: Accept-Encoding
{
"URIs": [
"http://example.net/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
],
"fallback": "/c/bae27c36-fa6a-11e4-ae5d-00059a3c7a00"
}
クライアントは、ここを取りに行って、このヘッダと合体させてHTTPレスポンスを作る
暗号化も可能。キーをCrypto-Keyで渡す
15
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Caching Secure HTTP Content using Blind Caches
IETF95報告会2016/05/10
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf95/BC.pdf
シェアドキャッシュができますね!
16
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Server Push活用
IETF95報告会2016/05/10
この1RTT ×
Server Pushで0RTT
いきなり近くに取りに行ける
17
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
oauth WG
概要 Webの認可プロトコルの策定 基本部品は完了 セキュリティー強化、拡張
トピック Mix-Up Security Vulnerability Discovery Metadata, OAuth Metadata Token Exchange OAuth 2.0 for Apps Resource Indicators
IETF95報告会2016/05/10
19
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Mix-Up Security Vulnerability
draft-ietf-oauth-mix-up-mitigation-00 クライアントをendpointについて混乱させるアタック
Dynamic registration, Authorization, Token, Resource
正当なサービスのAuthZエンドポイントから得たcodeを悪意あるサービスのTokenエンドポイントに送らせる、その逆、など
攻撃成功の要件 clientは3rd party triggerでauthzが開始できる必要がある
xsrfや、TLSのないページからの誘導など
clientは複数のclient_idを持っていること(複数のASから認可をもらうなど)
Dynamic RegistrationやDiscoveryを使うと攻撃が容易に cut-n-paste attack: 盗んだcodeをクラフトしたauthz responseに貼る
IETF95報告会2016/05/10
20
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Mix-Up Security Vulnerability原因と対策
原因:
AuthZ responseなど、リダイレクトで伝わってくる部分のintegrity保証メカニズムがない
cf: OpenID Connectではid_token内のc_hashがdetachedsignatureとして使える
エンドポイントが複数あるが対応が不明
対策:
AuthZ req/resのintegrity強化(deteched sig)
エンドポイント間の対応を明示→メタデータ
IETF95報告会2016/05/10
21
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Discovery Metadata, OAuth Metadata
Discovery Metadata draft-ietf-oauth-discovery
discoveryによって、各エンドポイントの対応を明確に
クライアントは設定時と実行時で値に違いがないかチェック
OAuth Metadata draft-sakimura-oauth-meta
AuthZ response, Token responseに、対応するエンドポイント情報を持たせる
Linkヘッダを使用
クライアントで検証
IETF95報告会2016/05/10
22
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
OAuthプロトコルの修正と今後
OAuth基本仕様が策定されてからも、数々の脆弱性が見つかり、mitigation方法を定めたドラフトが出ている
threat modelなどの文書の改訂と基本仕様のbis検討が必要なのではないか
Barry: bisの着手が早すぎるのはよくない。threatmodelなどを個別にUpdate, Errataしていき、ある程度たまったところで全体的なbisを考えるのがよい
IETF95報告会2016/05/10
23
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
httpauth WG
概要
HTTP認証仕様の策定
すでにBasic, Digest, HOBA, SCRAM策定済
トピック
Mutual Authがnear WGLC ready
最後のissueに対する対応を確認
5月にWGLC
BerlinまでにRFC化できるか?
IETF95報告会2016/05/10
25
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
まとめ
httpbis HTTP/2の策定はALT-SVCが完了して、部品としてはひととおりそろった
HTTPはまだまだ課題がつきない
oauth 基本部分がひととおり完了 セキュリティー強化、対策 アプリサポート
httpauth Mutual Authが終わったらおしまい?
IETF95報告会2016/05/10
27
Copyright © 2004-2016 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Any Questions? Please Give Feedbacks!
https://lepidum.co.jp/
mailto:[email protected] / twitter: @mad_p
IETF95報告会2016/05/10