1 / 27

Towards a Safe Playground for HTTPS and Middle-Boxes with QoS2

This paper presents a solution, QoS2, that combines HTTP and HTTPS to achieve both quick load times and security. It introduces the challenges of using HTTPS and middle-boxes, and proposes an architecture that classifies web content and uses checksums for verification. Evaluation results show significant performance improvements. Future work includes enhancing platforms and protocols to support QoS2.

washamj
Download Presentation

Towards a Safe Playground for HTTPS and Middle-Boxes with QoS2

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. Towards a Safe Playground for HTTPS and Middle-Boxes with QoS2 Zhenyu Zhou zzy@cs.duke.edu CS Dept., Duke University @Duke UniversityMay, 2015

  2. Outline • Introduction • Challenges • Solution • QoS2 Architecture • Evaluation • Future works

  3. Introduction • HTTPS • HTTP on top of SSL/TLS • Safe – Prevailed nowadays • Over 50% traffic! • But does the “S” come for free? Image referenced from: https://www.hallaminternet.com/2015/migrating-website-http-https/

  4. Introduction • Is the “S” free? • No! • Page Load Time (PLT) • More RTTs for establishing connections • Key exchange • Decryption/Encryption Image referenced from: http://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-bindings-on-iis.aspx

  5. Introduction • Middle Boxes • Inspecting packets and optimizing end-user performance are prevented Ka Ka Kb Kb Not Hit!! Cache

  6. Introduction • All-or-nothing choice nowadays • HTTP – Quick, but not safe • HTTPS – Safe, but not quick • Trade-off • Make the Internet Quick and Of course Safe, Too

  7. Introduction • Our overall goal • Short load time and low overhead • Leverage the benefits of HTTP • Simple • High efficiency • Security is not compromised • Serve the objects via HTTPS • Ensure security

  8. Outline • Introduction • Challenges • Solution • QoS2 Architecture • Evaluation • Future works

  9. Challenges • How to combine the two aspects of our goal together? • The straw man solution is trivial: deploy both of them at the same time • Why do some people not prefer mixed content? • Man in the Middle Attacks • Stripping Attacks

  10. Challenges • Man in the Middle Attacks • Unsecure data can be hijacked and threats the secure part

  11. Challenges • Stripping Attacks Image referenced from: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

  12. Outline • Introduction • Challenges • Solution • QoS2 Architecture • Evaluation • Future works

  13. Solution • Q: How to combine HTTP and HTTPS? • Key observations • Not everything needs to be encrypted • The data that indeed need to be encrypted may NOT need to be cached • HTTPS connections are not well utilized and may be harmful • HTTPS handshake can account for over 42% of data exchanged • Key idea • Use HTTP for as many objects as possible

  14. Solution • Classify the Web Content • Public content, can be sent over HTTP • The content contains little information • Google logo • The content which is the same for all users • Javascript files • Private content, must be sent over HTTPS • The content contains personal information • User name, password, etc.

  15. Solution • Classify the Web Content

  16. Solution • Employ checksums to prevent tampering of data • Checksums prevent Man in the Middle Attacks compromising the unsecure data • Send checksums over HTTPS channel • Key insight: • Checksums are much smaller than data, sending checksum over HTTPS incurs minimal costs

  17. Outline • Introduction • Challenges • Solution • QoS2 Architecture • Evaluation • Future works

  18. QoS2 Architecture

  19. QoS2 Architecture • Server Side • Tags content as either private or public • Tags determine which content is sent over HTTP or HTTPS. • Calculates and maintains a checksum for each content that is tagged as public • Checksums enable verification of an object’s integrity. • Maintains two connections with every client • A secure connection (over HTTPS) and an unsecure one (over HTTP). The server uses the secure connection to transfer the checksums. This ensures that the checksums are not tampered with.

  20. QoS2 Architecture • Client Side • Uses the checksum to verify the integrity of unencrypted data

  21. Outline • Introduction • Challenges • Solution • QoS2 Architecture • Evaluation • Future works

  22. Evaluation • Experiment Setup • We compare the load time for varying latencies to the origin server and potential proxies. • The public and private are each hosted on a 2.00 GHz server with 16 GB of RAM • The web servers and the browsing client are all interconnected through a 1G Local Area Network • Latencies follow distribution from Pings to Alexa Top 100 servers. • We set the latency at three points: 10%, median and 95% • Linux tc command

  23. Evaluation

  24. Evaluation • Gain at least a 20% performance improvement in low latency networks and as much as 70% in high latency networks • The improvements are function of both the dependencies between objects and the size of the public objects

  25. Outline • Introduction • Challenges • Solution • QoS2 Architecture • Evaluation • Future works

  26. Future works • Enhance the Nginxand Apache platforms to support QoS2 • Implement checksum verification in a browser • Enhance the protocol to disambiguate between stale checksums and attacks on the HTTP channel • Compare with QUIC protocol

  27. Thank you!Questions?

More Related