1. Towards a Safe Playground for HTTPS and Middle-Boxes with QoS2 Zhenyu Zhou zzy@cs.duke.edu CS Dept., Duke University @Duke University @Duke University May, 2015

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

3. Introduction HTTPS  HTTP on top of SSL/TLS  Safe – Prevailed nowadays Over 50% traffic! But does the “S” come for free? 3 Image references 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 4 Image references 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 5 KaKa KbKb Cache Not Hit!! KaKa KbKb

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 6

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 7

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

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 9

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

11. Challenges Stripping Attacks 11 Image references 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 12

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 13

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. 14

15. Solution Classify the Web Content 15

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 16

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

18. QoS2 Architecture 18

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. 19

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

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

22. Validation The time to calculate checksum  Pre-calculated Eliminate latency overheads Result in stale checksums  Calculated on-demand Guarantee freshness Incur latency overheads Our choice: Pre-calculated 22

23. Validation Do object change frequently?  If yes – Pre-calculating checksum makes no sense, we have to calculate it almost every time retrieving the data  If no – Pre-calculation is reasonable Experiment setup  30 days  135 javascript files 23

24. Validation 24

25. Validation 25

26. Validation Result  Most objects rarely change, only 6 out of the 135 objects examined changed (less than 5%)  For those that do change, we observe that they in-fact change very frequently with approximately 50% of them changing everyday For most objects, pre-calculation is reasonable 26

27. Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 27

28. 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 28

29. Evaluation 29

30. 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 30

31. Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 31

32. Future works Enhance the Nginx and 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 32

33. Thank you! Questions? 33