iHTTP: Efficient Authentication of Non-Confidential HTTP Traffic

1. iHTTP: Efficient Authentication of Non-Confidential HTTP Traffic Jason Gionta, Peng Ning North Carolina State University Xiaolan Zhang IBM T.J. Watson Research Center ACNS '12

2. 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 ACNS '12

3. 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 ACNS '12

4. 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! ACNS '12

5. 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 ACNS '12

6. Observation • Two categories of HTTP data • Client-static • Client-unique ACNS '12

7. Observation HTTP request: index.html HTTP response: Hi Friend! HTTP response: Hi Friend! HTTP request: index.html • Two categories of HTTP data • Client-static: many clients  one response • Client-unique ACNS '12

8. Observation HTTP request: index.php HTTP response: Hi Client 1! HTTP response: Hi Client 2! HTTP request: index.php • Two categories of HTTP data • Client-static: many clients  one response • Client-unique: different clients  different responses ACNS '12

9. Assumptions and Threat Model • Assumptions • Clients and servers are loosely synchronized • Response data is client-static andnon-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 ACNS '12

10. iHTTP: Presentation Plan • iHTTP framework • Generation of server response • Verification on client • Three techniques • Authenticator generation • Freshness authentication • Opportunistic verification at clients ACNS '12

11. iHTTP Framework Extract Metadata & Generate Hashes Generate Response Response Output HTTP Response & Authenticator Authenticator Data Send Response to Client Sign : Server :iHTTP Server side ACNS '12

12. iHTTP Framework Receive Response HTTP Response & Authenticator Verify Authenticator HTTP Response Render Response Verify HTTP Response : Browser :iHTTP Client side ACNS '12

13. iHTTP: Authenticator Generation A.t – generation timestamp A.e – expiration A.u – requested URL A.l – length of authenticated data • 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 ACNS '12

14. 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 ACNS '12

15. 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 ACNS '12

16. 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 ACNS '12

17. 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 ACNS '12

18. iHTTP: Authenticated Sliding Timestamps Xn Xn-1 Xi Xi-1 X2 X1 • Based on the one-way property of hash chains • Authenticate Xi by hashing to known Xn • Servers releases hash values to extend freshness ACNS '12

19. iHTTP: Hash Chain Generation Server Secret A.e Nonce A.t Time Xn Xn-1 Xi Xi-1 X2 X1 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 ACNS '12

20. iHTTP: Extending a Timestamp A.e A.t Time Xn Xn-1 Xi Xi-1 X2 X1 Hash Chain Generation • Server releases Xi with each authenticator • where i is based on current server time c • The validity of the authenticator is extended to ACNS '12

21. iHTTP: Client Authentication A.e A.t Time Xn Xn-1 Xi Hash Chain Generation • 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 ACNS '12

22. 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 ACNS '12

23. iHTTP: Opportunistic Hash Verification <html> <head> <link type="text/css" href="/screen_home.css" /> _h="675DBD8DEBFB8881F068FF7E03510F98C75DAD5D" /> </head> … </html> • Client Request Anticipation • Servers parse HTML responses for resources • URLs are used to look up authenticators • Authenticators are hashed and embedded in HTML ACNS '12

24. 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 ACNS '12

25. 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 ACNS '12

26. 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 ACNS '12

27. 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 ACNS '12

28. JMeter Benchmark Results ACNS '12

29. JMeter Benchmark Results (Cont’d) ACNS '12

30. Client Macro-benchmark 21.6% reduction • 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 ACNS '12

31. Server Micro-benchmark • Five primary operations • Signature generation • 86% of authenticator generation cost ACNS '12

32. How about Client-Unique ata? Not so good! • SpecWeb2009 • Industry standard benchmark software • Deployed banking web application • 15 unique pages • Unique page responses for each user ACNS '12

33. 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 ACNS '12

34. Thank You! Questions? ACNS '12