Computer Science

iHTTP: Efficient Authentication of Non-Confidential HTTP Traffic

1

Xiaolan ZhangIBM T.J. Watson Research Center

Jason Gionta, Peng NingNorth Carolina State University

06/29/12 ACNS '12

Computer Science

Background

• Web traffic (HTTP) is dominant on the Internet– 77% of the total IP traffic in 2011 (Cisco)

• Authenticity of HTTP data is important!– AD rewriting and injection

• Ex. rewrite ads incoming over public WiFi– Click fraud

• Ex. modified search results to entice user clicks – Malicious attacks on clients

• Ex. Java script based exploits

06/29/12 ACNS '12 2

Computer Science

Motivation

• Standard solution: HTTPS (i.e., HTTP over TLS/SSL)– Provide key management, authentication, and encryption– Significant performance overhead

• Bootstrapped via public key cryptography• Does not support network caching

• Need better ways to authenticate HTTP data– Less costly than HTTPS– Supports network caching– Data authentication and integrity– Data freshness authentication

306/29/12 ACNS '12

Computer Science

Previous Research• SSL Splitting [MIT MS Thesis 2003]

– Introduce proxy/cache into authenticated data delivery

– Requires modification and trust in proxies and caches

• SINE [NPSec 2009]– Progressive authentication

• Progressive rendering – Cache and aggregate signatures

to amortize costs– No data freshness assurance

• Replay attacks– Require knowledge of pages to

be accessed to aggregate signatures

• HTTPI [ICCCN 2011]– Essentially long-lived TLS/SSL– Extra key management

required

• HTTPi [WWW 2012] – Support HTTP/1.1 chunked

encoding– Data freshness authentication

• Sign authenticator with updated timestamps

– Server must sign each response• Costly!

– Client must verify each signature

• Costly!06/29/12 ACNS '12 4

Computer Science

Our Approach: iHTTP

• Authentication and integrity of HTTP response data– Signature based approach

• Enable data freshness authentication– Authenticated timestamp

• Lightweight and efficient– Dynamically update timestamps without signing– Assist clients in signature verification

• No modification to network caches

506/29/12 ACNS '12

Computer Science

Observation

• Two categories of HTTP data– Client-static– Client-unique

606/29/12 ACNS '12

Computer Science

Observation

• Two categories of HTTP data– Client-static: many clients one response– Client-unique

706/29/12 ACNS '12

Client 1

Client 2

HTTP request: index.html

HTTP request: index.html

HTTP response: Hi Friend!

HTTP response: Hi Friend!

Computer Science

Observation

• Two categories of HTTP data– Client-static: many clients one response– Client-unique: different clients different responses

806/29/12 ACNS '12

Client 1

Client 2

HTTP request: index.php

HTTP request: index.php

HTTP response: Hi Client 1!

HTTP response: Hi Client 2!

Computer Science

Assumptions and Threat Model

• Assumptions– Clients and servers are loosely synchronized– Response data is client-static and non-confidential

• Threat model– Attackers may intercept, modify, store, and replay data

between the client and the server– Attackers may slow down data delivery for reasonable

amounts of time

906/29/12 ACNS '12

Computer Science

iHTTP: Presentation Plan

• iHTTP framework– Generation of server response– Verification on client

• Three techniques– Authenticator generation– Freshness authentication– Opportunistic verification at clients

06/29/12 ACNS '12 10

Computer Science ACNS '12

iHTTP Framework

• Server side

11

: Server

Generate Response

ResponseOutput

Extract Metadata &

Generate Hashes

AuthenticatorData

SignHTTP Response& Authenticator

Send Responseto Client

: iHTTP

06/29/12

Computer Science

iHTTP Framework

• Client side

12

ReceiveResponse

HTTP Response& Authenticator

Verify Authenticator

HTTP ResponseRender

ResponseVerify HTTP

Response

: Browser : iHTTP

06/29/12 ACNS '12

Computer Science

• Authenticator content– Authenticator metadata– Response metadata– Message body hashes

• An authenticator is generated when– New response data is observed for a URL, or– Authenticator expires

)}.|.|.|.|.|.({ ContentHTTPHeadersHTTPlAuAeAtAHSignk

iHTTP: Authenticator Generation

A.t – generation timestampA.e – expirationA.u – requested URLA.l – length of authenticated data

1306/29/12 ACNS '12

Computer Science ACNS '12

Observation on Progressive Authentication

• Progressive authentication– Proposed as part of SINE [NPSec 2009]– Enables progressive rendering– Not useful for compressed data

• Compressed data must be buffered

14

HTTP Response

Non-Critical Headers

DivideMessage Body

Critical Headers

HTTP Headers

Expiration

Xn Has

h C

hain

Gen

Xn-1

Cn

Cn-1

Hash

X2

X1C1

C2

HTTP Content

Hash

Hash

Hash

Authenticator: Signk{H(Expiration,

HTTP Headers, Response Body)}

06/29/12

Computer Science

iHTTP: Authenticator Generation (Cont’d)

• Authentication of HTTP.Content– Leverage Naïve and Progressive Authentication

• Compressed data – Naïve authentication method (i.e., treat all data as one unit)

• Non-compressed data– Progressive authentication

1506/29/12 ACNS '12

Computer Science

iHTTP: Freshness Authentication

• Expiration time A.e allows long-lived authenticators– When response content does not change– Bypasses signing; allows authenticator caching

• Significant performance benefit

• Problem – Expiration time A.e is static after signing– Attackers can replay old data whose expiration time has not

passed– Removing A.e requires signing each response

1606/29/12 ACNS '12

Computer Science

iHTTP: Freshness Authentication (Cont’d)

• How to enable data freshness efficiently?– Authenticated sliding timestamps

• Decouple data freshness and authenticator generation– Freshness not tied to authenticator timestamp

• Enables caching of authenticators– Amortizes signing costs

1706/29/12 ACNS '12

Computer Science

iHTTP: Authenticated Sliding Timestamps

• Based on the one-way property of hash chains– Authenticate Xi by hashing to known Xn

• Servers releases hash values to extend freshness

18

Xn Xn-1 Xi Xi-1 X2 X1

06/29/12 ACNS '12

Computer Science

iHTTP: Hash Chain Generation• Each hash operation represents time increment Δt

– Δt: server defined and configurable• Size of hash chain dependent on A.t, A.e, and Δt

– • Xn and Δt are included in the authenticator

19

Xn Xn-1 Xi Xi-1 X2 X1

Hash Chain Generation

Timet t t t t

n A.e A.t

t

A.t A.e Nonce

ServerSecret

06/29/12 ACNS '12

)}||.|.|.|.|.|.({ tXContentHTTPHeadersHTTPlAuAeAtAHSign nk

Computer Science

iHTTP: Extending a Timestamp

• Server releases Xi with each authenticator– where i is based on current server time c– – The validity of the authenticator is extended to

20

Xn Xn-1 Xi Xi-1 X2 X1

Hash Chain Generation

Timet t t t t

A.t A.e

t

tAcni .

tAtin .*)(

06/29/12 ACNS '12

Computer Science

iHTTP: Client Authentication

• Verify the authenticator data using the signature– Verifies Xn and Δt

• Authenticate Xi by hashing Xi to Xn ( )• Authenticate freshness

– Request timestamp must be less than

21

Xn Xn-1 Xi

Hash Chain Generation

Timet t t t t

A.t A.e

niin XXH )(

06/29/12 ACNS '12

tAtin .*)(

Computer Science

iHTTP: Client Authenticator Verification

• Clients verify at least one signature per response • Rendering web pages may require many signature

verifications– CNN.com: 128 responses– All-Thats-Interesting.tumblr.com: 176 responses

• Clients can get overwhelmed– Especially for resource constrained clients

2206/29/12 ACNS '12

Computer Science

<html> <head> <link type="text/css" href="/screen_home.css" />_h="675DBD8DEBFB8881F068FF7E03510F98C75DAD5D" /> </head> …</html>

iHTTP: Opportunistic Hash Verification

• Client Request Anticipation– Servers parse HTML responses for resources– URLs are used to look up authenticators– Authenticators are hashed and embedded in HTML

)||.|.|.|.|.|.( tXContentHTTPHeadersHTTPlAuAeAtAH n

2306/29/12 ACNS '12

Computer Science

Opportunistic Hash Verification (Cont’d)

• Client operations– Verify follow-up components with the embedded hash

value– Only verify the signatures of follow-up components when

the hash verification fails• Benefits

– Involves costly signature verifications only when the follow-up components are updated after hash embedding

06/29/12 ACNS '12 24

Computer Science

Security Analysis

• Authenticated data– Based on existing PKI infrastructure

• Same as HTTPS– Authenticators are bounds to data

• Data Integrity– Based on signatures or authenticated hash values

• Verifiable freshness– Clients calculate timestamps

• Cannot forge due to one-way hash chain properties

2506/29/12 ACNS '12

Computer Science

Limitations

• iHTTP not suitable for all HTTP data– Beneficial for Client-Static data

• Client-Static data is cacheable– Not suitable for Client-Unique data

• Cannot protect client requests – Cookies and post data not protected

• Each response must be signed – Poor performance

2606/29/12 ACNS '12

Computer Science

Experimental Evaluation

• Server Macro-benchmark– Use JMeters– Compare iHTTP, HTTP, HTTPS, and HTTPi– Deployed blog template website

• Client-Static data– Simulated 130 simultaneous clients– Four different configurations

• Non-Chunked-Not-Compressed• Compressed (but not chunked)• Chunked (but not compressed)• Chunked-compressed

2706/29/12 ACNS '12

Computer Science ACNS '12 28

JMeter Benchmark Results

06/29/12

Computer Science ACNS '12 29

JMeter Benchmark Results (Cont’d)

06/29/12

Computer Science

Client Macro-benchmark

• Evaluate impact of Opportunistic Hash Verification*– On a resource constrained client

• Android enabled Droid2

• 20 requests to Client-Static blog– 17 resources per web page

Configuration Avg Page LoadNon-OHV 7.4321 s

OHV 5.8291 s

3006/29/12 ACNS '12

21.6% reduction

Computer Science

Server Micro-benchmark

• Five primary operations

• Signature generation – 86% of authenticator generation cost

Operation TimeAuthenticator Creation 4.97771 ms

Signature Generation 4.32070 ms

Hash Embedding 0.13189 ms

Cache Search 0.08751 ms

SHA-1 Operation 0.00042 ms

3106/29/12 ACNS '12

Computer Science

How about Client-Unique ata?

• SpecWeb2009– Industry standard benchmark software– Deployed banking web application

• 15 unique pages• Unique page responses for each user

Protocol Avg Response Time Avg Bytes per ReqHTTP 544 ms 41,818

HTTPS 576 ms 41,828

iHTTP 647 ms 50,627

HTTPi 662 ms 52,147

3206/29/12 ACNS '12

Not so good!

Computer Science

Conclusion

• iHTTP– Lightweight authentication of HTTP response data– Both secure and efficient– Enables freshness authentication without signing

• Authenticated sliding timestamps– Minimizes client computation

• Opportunistic Hash Verification– Performance

• Better than previous signature-based approach HTTPi• Similar to HTTP for non-chunked Client-Static data

3306/29/12 ACNS '12

Computer Science

Thank You!

Questions?

06/29/12 ACNS '12 34