Towards a Safe Playground for HTTPS and Middle-Boxes with QoS2 Zhenyu Zhou CS Dept., Duke University May, 2015

Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 2

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:

Introduction Is the “S” free?  No! Page Load Time (PLT)  More RTTs for establishing connections  Key exchange  Decryption/Encryption 4 Image references from: iis.aspx

Introduction Middle Boxes  Inspecting packets and optimizing end-user performance are prevented 5 KaKa KbKb Cache Not Hit!! KaKa KbKb

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

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

Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 8

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

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

Challenges Stripping Attacks 11 Image references from: Defeating-SSL.pdf

Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 12

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

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

Solution Classify the Web Content 15

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

Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 17

QoS2 Architecture 18

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

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

Outline Introduction Challenges Solution QoS2 Architecture Validation Evaluation Future works 21

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

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

Validation 24

Validation 25

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

Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 27

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

Evaluation 29

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

Outline Introduction Challenges Solution QoS2 Architecture Evaluation Future works 31

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

Thank you! Questions? 33