idnits 2.17.00 (12 Aug 2021) /tmp/idnits64227/draft-lemon-tls-blocking-alert-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2016) is 2168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (ref. '1') (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Standards Track June 6, 2016 5 Expires: December 8, 2016 7 Blocked Site Alerts for TLS 8 draft-lemon-tls-blocking-alert-00 10 Abstract 12 Hosts connecting to the Internet should generally be able to connect 13 to all available services. However, as a matter of policy, need or 14 preference, some services may be blocked by the network. TLS 15 correctly treats attempts to communicate the reason for such blockage 16 to the client as an attack. This memo describes a safe way for hosts 17 to be notified using the TLS alert mechanism that a connection has 18 been blocked by the network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 8, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Meanings of Alert Descriptions . . . . . . . . . . . . . . . 4 57 3.1. Captive Portal . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Malicious Site . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Policy Violation . . . . . . . . . . . . . . . . . . . . 4 60 3.4. Account Attention Requested . . . . . . . . . . . . . . . 4 61 3.5. Account Attention Required . . . . . . . . . . . . . . . 4 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 There are a number of situations in which a connection from a 74 particular host to a particular service on the Internet may be 75 prohibited by policy, or may be blocked in order to redirect the user 76 to a captive portal login. In current practice, such connections, 77 particularly HTTP connections, are usually terminated on some sort of 78 HTTP proxy that presents a web page notifying the user as to what 79 happened, and possibly offering some way to address whatever problem 80 has come up. For instance, with a captive portal, the user may be 81 directed to log in. 83 Such HTTP proxies are performing what can accurately be described as 84 a man-in-the-middle attack. Whether the purpose is benign or 85 malicious, TLS[1] detects such attacks and, rightly, prevents them. 87 Unfortunately, TLS's correct behavior in this situation creates a 88 usability problem. There is no way to notify the user as to what 89 went wrong. This is a problem not only with HTTP connections, but 90 also with other TLS-based connections, such as secure IMAP 91 connections: users of captive portals are generally familiar with the 92 phenomenon of having to reset the mail client after logging in to the 93 captive portal, because it has concluded that the network is not 94 usable as a result of detecting an invalid certificate. 96 One way to address this is to simply tell the user to click through 97 the security warning. This is of course a disastrously bad idea, 98 because it trains the end user to automatically permit genuinely 99 malicious attacks. 101 There is no reasonable basis for trusting a proxy engaging in a MiTM 102 attack of this sort. It would be very unsafe, for example, to 103 provide a TLS extension that could be used by the proxy to convey any 104 sort of server-generated status message or URL, because these would 105 present a valuable attack surface. 107 However, the TLS protocol begins as a plaintext communication. A 108 plaintext response to the initial TLS Client Hello message can 109 include an Alert response indicating that the connection is not 110 permitted. Alert response codes contain no information generated by 111 the server: they simply contain a status code and an indication as to 112 whether the alert is fatal or just a warning. 114 Because they provide no mechanism for a malicious attacker to trick 115 the end user into clicking on a malicious URL, or any way to tell a 116 careful lie to the end user, TLS alerts would seem to be a viable 117 means of providing the client with sufficient information to present 118 a useful error message without compromising the security of the end 119 user. 121 This document defines a set of TLS alert descriptions to indicate 122 each of the common reasons why a network service provider might block 123 a particular connection. 125 2. Applicability 127 Alert descriptions defined in this document are intended to be used 128 in alert messages marked fatal. If a server sends an alert using any 129 of the codes defined in this document which is marked as a warning, 130 the client will detect a MiTM attack once the connection progresses 131 to the point where the server certificate can be checked. 133 TLS clients receiving any of the alert descriptions documented here 134 may present a message in a user interface describing the result code 135 that was received. TLS clients without user interfaces may log a 136 message indicating that such an alert was received. In either case, 137 clients should limit the rate at which such messages that are 138 presented, to avoid denial of service or resource exhaustion. 140 Connections not directly initiated by a user should not result in a 141 message being displayed in the user interface (for example, a 142 Javascript XMLHttpRequest that generates such an alert). 144 Because a TLS proxy interposed between the host and the server will 145 not know the name of the server to which the host is connecting, it 146 may need to depend on the Server Name Indication extension [2] to 147 provide different status codes for different servers. 149 3. Meanings of Alert Descriptions 151 3.1. Captive Portal 153 The 'captive_portal' alert description represents a claim by the 154 server that the host is connected to a network behind a captive 155 portal. This is a curable condition: the end user may be able to 156 register with the captive portal, and subsequently a connection to 157 the same server would not be intercepted, and could succeed. TLS 158 clients receiving this code may choose to retry the connection 159 periodically, frequently enough that authenticating would provide a 160 timely resumption of service. 162 3.2. Malicious Site 164 The 'malicious_site' alert description represents a claim by the 165 server that the host has attempted a connection to a service that is 166 known by the network administration to serve malicious content (e.g., 167 malware, phishing, etc.). This condition is assumed to be a 168 permanent failure; although it may be that at some future time the 169 same IP address is no longer marked malicious, the particular 170 transaction that was attempted is not likely to succeed if retried. 172 3.3. Policy Violation 174 The 'policy_violation' alert description represents a claim by the 175 server that the host has attempted to connect to a site the use of 176 which is in violation of local policy. For example, connecting to a 177 porn site from an enterprise network might be a policy violation. 179 3.4. Account Attention Requested 181 The 'account_attention_requested' alert description represents a 182 claim by the server that the network service provider is requesting 183 that the end user log in to their account. This is a temporary 184 condition, such that an immediate attempt to reconnect can be 185 expected to succeed reaching the correct server. 187 3.5. Account Attention Required 189 The 'account_attention_required' alert description represents a claim 190 by the server that the network service provider is insisting that the 191 end user log in to their account. This is not a temporary condition: 193 until whatever situation has motivated the service provider to place 194 this block has been resolved, any further attempt to connect will 195 result in the same alert description being returned. 197 4. Acknowledgements 199 Placeholder 201 5. IANA Considerations 203 The IANA is requested to allocate values for the five new TLS Alert 204 descriptions documented here from the TLS Alert Registry. These are: 206 TBD captive_portal 208 TBD malicious_site 210 TBD policy_violation 212 TBD account_attention_requested 214 TBD account_attention_required 216 6. Security Considerations 218 This document attempts to avoid creating a channel of attack for a 219 malicious attacker. However, any bit of information, no matter how 220 small, can be used as a lever to trick the user into taking some 221 action which will create an opportunity for attack. 223 The situation prior to introduction of these new alert messages is 224 that attackers wanting to trick an end user into taking such an 225 action can do one of two things: they can simply block the 226 connection, which will result in the user trying to figure out what 227 went wrong, or they can send an invalid cert and hope that the user 228 clicks through the warnings. 230 A captive_portal alert might be used by the operating system as a 231 means of directing the end user to log in to a captive portal web 232 page. An attacker knowing the expected behavior of the operating 233 system could trigger such an attempt. However, means of triggering 234 such attempts already exist, so this introduces no new opportunity. 236 A malicious_site alert has no meaningful user mitigation response 237 other than to stop trying to visit that site. An attacker might 238 provide such a response as a way to prevent an end user from 239 accessing that site in the future. To avoid this, TLS clients that 240 receive such alerts should not cache them. An end user might still 241 remember that such a warning was received, and might take it more 242 seriously than an invalid cert message. There is no means to 243 mitigate this risk; however, the added value of being able to block 244 malicious sites likely outweighs the possibility that a malicious 245 attacker could succeed in tricking the user in this way. 247 A policy_violation alert might encourage the end user to try to find 248 some way around the policy. The alternative is to block the 249 connection entirely, however; this would likely trigger similar 250 behavior in the end user, so this does not seem to be a substantial 251 additional risk. 253 The account_attention_requested and account_attention_required alerts 254 could be used to trick the end user into going to a faked version of 255 their provider's site that is not secured using TLS and PKI. The 256 user could then be tricked into providing authentication credentials 257 or other personal information. Existing browser mitigation for such 258 attacks are likely adequate, but it cannot be denied that there is 259 some additional risk in presenting these messages to the end user. 260 The messages could be presented along with some advice to the end 261 user about checking to make sure that the site is secure, or even 262 provide the user with a user interface element to click that brings 263 them to a browser window that prevents non-TLS/non-PKI connections 264 from succeeding. 266 7. Privacy Considerations 268 To the extent that HTTP proxies using these alert messages rely on 269 the Server Name Indication TLS extension [2], there could be a 270 concern that the end user's privacy might be violated if the proxy 271 logs the SNI information sent in each request. However, there is no 272 way at present to prevent a passive listener from capturing such 273 information, so this does not create a new privacy risk. 275 8. References 277 8.1. Normative References 279 [1] Dierks, T. and E. Rescorla, "The Transport Layer Security 280 (TLS) Protocol Version 1.2", RFC 5246, 281 DOI 10.17487/RFC5246, August 2008, 282 . 284 8.2. Informative References 286 [2] Eastlake 3rd, D., "Transport Layer Security (TLS) 287 Extensions: Extension Definitions", RFC 6066, 288 DOI 10.17487/RFC6066, January 2011, 289 . 291 Author's Address 293 Ted Lemon 294 Nominum, Inc. 295 800 Bridge Parkway 296 Redwood City, California 94065 297 United States of America 299 Phone: +1 650 381 6000 300 Email: ted.lemon@nominum.com