Internet Draft T. Gallagher NSA Information Assurance Updates: 6455 (if approved) July 7, 2016 Expires January 2017 Security Enhancement for WebSockets to Prevent Private Network Mapping draft-gallagher-hybiwebsocketenhancement-00 Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted to IETF pursuant to, and in full conformance with, the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on 1/12/2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document proposes an update to RFC 6455 (WebSockets) which would Gallagher Expires January 2017 [Page 1] Internet Draft WebSockets Security Enhancement July 7, 2016 enhance security by preventing network mapping via WebSockets. By comparing timing differences between failed opening handshakes, WebSockets can be abused within web browsers to discover details about a target's private network. WebSocket network mapping is more efficient than other in-browser mapping techniques as it can take advantage of child WebWorker processes to bypass the throttling mitigations in many browsers. An attacker can exploit this browser weakness when a victim accesses an attacker-controlled web page. Gallagher Expires January 2017 [Page 2] Internet Draft WebSockets Security Enhancement July 7, 2016 Table of Contents 1. Introduction ....................................................3 2. Security Considerations .........................................4 2.1. Proposed Addition to RFC 6455 Section 7.2.1 ................4 2.2. Proposed New Subsection for RFC 6455 Section 10 ............4 3. IANA Considerations .............................................4 4. References ......................................................4 4.1. Normative References .......................................4 Author's Address ...................................................5 IETF Trust Legal Provisions ........................................5 Full Copyright Statement ...........................................5 1. Introduction This document is a proposal for an update to RFC 6455 to make the WebSocket protocol more secure against in-browser network mapping attacks. Other protocols may benefit from advice provided in this document, but additional work should be performed to ensure compatibility. Currently, WebSockets can be leveraged by malicious JavaScript to perform network mapping of a user's private network without the user's awareness. This can be accomplished when a user accesses an attacker-controlled web page. JavaScript code within the page can attempt to make WebSocket connections to private (RFC 1918) IP address/port combinations. Because it is unlikely that these private addresses host a WebSocket server, any response or lack of response from them will cause a connection error. By tracking the time between request and error, JavaScript code can infer which ports issued a response. Shorter times would indicate a responding port; longer times would indicate that no response was received. Using this information, an attacker could discover information about other devices on the network including IP addresses and operating network services. In-browser network mapping is a well-known technique and is achievable through several methods in addition to WebSockets. However, certain WebSocket network mapping techniques can bypass some browser mitigations that hinder mapping effectiveness. Specifically, browsers place a limit on the number of open connections for each browser process effectively reducing network mapping speed. Unlike other techniques, WebSocket network mapping can be accomplished within WebWorker child processes. Because most browsers enforce the connection limit independently for each WebWorker, an attacker can increase network mapping efficiency by an order of magnitude equal to the maximum number of WebWorkers. Gallagher Expires January 2017 [Page 3] Internet Draft WebSockets Security Enhancement July 7, 2016 2. Security Considerations The following mitigation would prevent WebSocket network mapping from within the browser. The below paragraph would be added to RFC 6455 in section 10, "Security Considerations", and a reference to this paragraph would be placed at the end of section 7.2.1, "Client- Initiated Closure". 2.1 Proposed Addition to RFC 6455 Section 7.2.1 Addition to RFC 6455 7.2.1. Client-Initiated Closure (Addition): When client-initiated closure occurs as a result of a failed opening handshake, the error message should not be reported through the WebSocket API until a uniform timeout has been reached. Section 10.x identifies security concerns of handling failed handshakes inconsistently. 2.2 Proposed New Subsection for RFC 6455 Section 10 New subsection for RFC 6455, 10.x. Uniform Termination of Failed Opening Handshakes: When a failed opening handshake occurs, browsers MUST trigger a uniform failure message to the JavaScript environment regardless of how the failure occurred. The error code and message MUST be uniform, and the error must be triggered at a uniform time based on when the request was issued. If JavaScript can detect differences between connection failure due to an unexpected response and connection failure due to no response, an attacker could identify network services and devices within a private network. For this reason, failed handshake errors should be held by the browser until a uniform timeout value is reached before triggering the JavaScript event for the erring connection. 3 IANA Considerations This document has no actions for IANA. 4 References 4.1 Normative References [RFC6455] Fette, I., Melnikov, A., "The WebSocket Protocol", RFC 6455, December 2011. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., Lear, E., "Address Allocation for Private Internets", Gallagher Expires January 2017 [Page 4] Internet Draft WebSockets Security Enhancement July 7, 2016 RFC 1918, February 1996. Author's Address Tom Gallagher Email: gallagher.tom.m@gmail.com Comments are solicited and should be addressed to the working group's mailing list at hybi@ietf.org and/or the author(s). IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.