1 / 34

iHTTP: Efficient Authentication of Non-Confidential HTTP Traffic

iHTTP: Efficient Authentication of Non-Confidential HTTP Traffic . Jason Gionta, Peng Ning North Carolina State University. Xiaolan Zhang IBM T.J. Watson Research Center. Background. Web traffic (HTTP) is dominant on the Internet 77% of the total IP traffic in 2011 (Cisco)

alena
Download Presentation

iHTTP: Efficient Authentication of Non-Confidential HTTP Traffic

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related