1 / 14

Formal specification and testing of QUIC

Develop a standard document (RFC) and provide detailed advice for implementers in English. Develop implementations and test for interoperability, performance, and validating the RFC. Use formal specification to check protocol compliance. Apply it to the emerging QUIC secure transport protocol.

sdean
Download Presentation

Formal specification and testing of QUIC

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. Formal specification and testing of QUIC Ken McMillan Microsoft Research Lenore Zuck University of Illinois at Chicago

  2. Internet protocol development • Develop a standard document (RFC) • Detailed advice for implementers in English • Develop implementations • Test for interoperability, performance, validating the RFC • Two-fold problem: • Implementations testing each other are too benign. • There is no check for compliance to the standard. Result: non-compliant implementations escape to the wild, becoming a de facto standard. This has security consequences, as in SSL/TLS. Non-compliance led to vulnerable workarounds which led to attacks such as POODLE.

  3. Proposal: use formal specification Specification serves a testing function Generates adversarialstimulus Checks protocol compliance This approach is called compositional specification-based testing. We will apply it to the emerging QUIC secure transport protocol.

  4. What is QUIC? • Replacement for TLS/TCP stack • Introduce by Google in 2013 • Goal • More responsive web applications • Standardization process • IETF working group, current draft = 22 • Transport for HTTP/3 QUIC will soon carry a large fraction of traffic on the Internet.

  5. How does it work? client server 0: CRYPTO: server hello, ACK 0 1: CRYPTO: finish, ACK 0 2: STREAM: “GET /index.html” 3: STREAM: “GET /index.html” 2: STREAM: “<html>…”, ACK 3 4: CONNECTION_CLOSE 0: CRYPTO: client hello authenticated, session keys retransmission Functions: Multiple streams, retransmission, flow and congestion control, version negotiation, migration, path validation, connection ID management, pre-shared keys, etc. Describes in 224 pages of RFC.

  6. Compositional testing Network Global specification: defines legal messages given message history client server Local assume/guarantee specification Assume: all past messages satisfy Guarantee: current sent message satisfies Intuition: no process can be the first to violate the protocol

  7. Isolating a process with A/G Network Generate Check Key properties: Adverse stimulus Checks compliance server Local assume/guarantee specification Randomly Generate incoming messages satisfying Check that outgoing messages satisfy

  8. Form of the specification Specification must be written only in terms of observables and must be effectively usable as both a generator and a checker. Guarded command form: event deterministic update guard verify and sample randomly using SMT

  9. Example: sequence numbers (in Ivy) actionpacket_event(src:endpoint,dst:endpoint,content:packet) relation seq_used(S : endpoint, N : seq_num) after init{ seq_used(S ,N) := false; } before packet_event{ require ¬seq_used(src, content.seq); } after packet_event{ seq_used(src, content.seq) := true; } A relation storing sequence numbers N used by endpoint S. A class of events corresponding to packet transmission Packet event update Initial state of specification Packet event guard

  10. Capturing the specification by testing client server Suppose is too strong: client message will violate Suppose is too weak: server will fail on generated message An implementation pushes on an A/G specification from both sides. This means we can use A/G testing to capture specification knowledge from implementations. Resulting specification in about 3KLOC of Ivy is highly incomplete. However, it can interact with real servers and clients to transfer web pages, without the servers and clients detecting protocol errors. This process revealed many errors in implementations and some problems in the draft standard.

  11. Some numbers • Errors detected: 27 • crashes: 13 • compliance violations: 12 • progress failures: 2 (no data transferred). Considered to be exploitable: 4 (apart from crashes) Resulting from ambiguities in the standard: 4 Resulting from adversarial stimulus: 18-22 (e.g., unusual message order) In every case where we could assign a root cause to the error, we found that detection was due to either adversarial stimulus or compliance checking. This validates our intuition that these elements were missing from prior testing efforts.

  12. A generated DoS scenario CLIENT addr: A probe packets… packet Role generated by tester SERVER probe CLIENT addr: B packet Abandons old probe • Packets alternate from different address • Probe never finishes • Data stream is blocked indefinitely • Attacker replaying packets from addrB can effect DoS

  13. A heartbleed-style data leak A server sent a STREAM data frame containing bytes read beyond the end of a buffer. <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML> <HEAD> <TITLE>PicoQuic HTTP 0.9 service</TITLE> </HEAD><BODY> <h1>Simple HTTP 0.9 Responder</h1> <p>GET /, and GET index.html returns this text</p> <p>Get /doc-NNNNN.html returns html document of length NNNNN bytes(decimal)</p> <p>Get /doc-NNNNN also returns html document of length NNNNN bytes(decimal)</p> <p>Get /doc-NNNNN.txt returns txt document of length NNNNN bytes(decimal)</p> <p>Get /NNNNN returns html document of length NNN^Z^X\200^Cl\357^@^D^@ <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML> <HEAD> <TITLE>PicoQuic HTTP 0.9 service</TITLE> </HEAD><BODY> <h1>Simple HTTP 0.9 Responder</h1> <p>GET /, and GET index.html returns this text</p> <p>Get /doc-NNNNN.html returns html document of length NNNNN bytes(decimal)</p> <p>Get /doc-NNNNN also returns html document of length NNNNN bytes(decimal)</p> <p>Get /doc-NNNNN.txt returns txt document of length NNNNN bytes(decimal)</p> <p>Get /NNNNN returns html document of length NNNNN bytes(decimal)</p> <p>Any other command will result in an error, and an empty response.</p> <h1>Enjoy!</h1> </BODY></HTML> Adversarial stimulus (in flow control) resulted in finding a security flaw, even though security properties not specified.

  14. Conclusions • A formal specification is a tool with a use • Generation of adverse stimulus • Checking of protocol compliance • A specification need not be complete or perfect to serve its function well • A modest specification effort pays significant dividends • Specifications can address significant pain points in protocol development • Faster approach to unit test development • Help to avoid release of non-compliant implementations in the wild.

More Related