Transport Layer Security T. Lemon
Internet-Draft Nominum, Inc.
Intended status: Standards Track June 6, 2016
Expires: December 8, 2016
Blocked Site Alerts for TLS
draft-lemon-tls-blocking-alert-00
Abstract
Hosts connecting to the Internet should generally be able to connect
to all available services. However, as a matter of policy, need or
preference, some services may be blocked by the network. TLS
correctly treats attempts to communicate the reason for such blockage
to the client as an attack. This memo describes a safe way for hosts
to be notified using the TLS alert mechanism that a connection has
been blocked by the network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 8, 2016.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Lemon Expires December 8, 2016 [Page 1]
Internet-Draft Blocked Site Alerts for TLS June 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Meanings of Alert Descriptions . . . . . . . . . . . . . . . 4
3.1. Captive Portal . . . . . . . . . . . . . . . . . . . . . 4
3.2. Malicious Site . . . . . . . . . . . . . . . . . . . . . 4
3.3. Policy Violation . . . . . . . . . . . . . . . . . . . . 4
3.4. Account Attention Requested . . . . . . . . . . . . . . . 4
3.5. Account Attention Required . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
There are a number of situations in which a connection from a
particular host to a particular service on the Internet may be
prohibited by policy, or may be blocked in order to redirect the user
to a captive portal login. In current practice, such connections,
particularly HTTP connections, are usually terminated on some sort of
HTTP proxy that presents a web page notifying the user as to what
happened, and possibly offering some way to address whatever problem
has come up. For instance, with a captive portal, the user may be
directed to log in.
Such HTTP proxies are performing what can accurately be described as
a man-in-the-middle attack. Whether the purpose is benign or
malicious, TLS[1] detects such attacks and, rightly, prevents them.
Unfortunately, TLS's correct behavior in this situation creates a
usability problem. There is no way to notify the user as to what
went wrong. This is a problem not only with HTTP connections, but
also with other TLS-based connections, such as secure IMAP
connections: users of captive portals are generally familiar with the
phenomenon of having to reset the mail client after logging in to the
captive portal, because it has concluded that the network is not
usable as a result of detecting an invalid certificate.
Lemon Expires December 8, 2016 [Page 2]
Internet-Draft Blocked Site Alerts for TLS June 2016
One way to address this is to simply tell the user to click through
the security warning. This is of course a disastrously bad idea,
because it trains the end user to automatically permit genuinely
malicious attacks.
There is no reasonable basis for trusting a proxy engaging in a MiTM
attack of this sort. It would be very unsafe, for example, to
provide a TLS extension that could be used by the proxy to convey any
sort of server-generated status message or URL, because these would
present a valuable attack surface.
However, the TLS protocol begins as a plaintext communication. A
plaintext response to the initial TLS Client Hello message can
include an Alert response indicating that the connection is not
permitted. Alert response codes contain no information generated by
the server: they simply contain a status code and an indication as to
whether the alert is fatal or just a warning.
Because they provide no mechanism for a malicious attacker to trick
the end user into clicking on a malicious URL, or any way to tell a
careful lie to the end user, TLS alerts would seem to be a viable
means of providing the client with sufficient information to present
a useful error message without compromising the security of the end
user.
This document defines a set of TLS alert descriptions to indicate
each of the common reasons why a network service provider might block
a particular connection.
2. Applicability
Alert descriptions defined in this document are intended to be used
in alert messages marked fatal. If a server sends an alert using any
of the codes defined in this document which is marked as a warning,
the client will detect a MiTM attack once the connection progresses
to the point where the server certificate can be checked.
TLS clients receiving any of the alert descriptions documented here
may present a message in a user interface describing the result code
that was received. TLS clients without user interfaces may log a
message indicating that such an alert was received. In either case,
clients should limit the rate at which such messages that are
presented, to avoid denial of service or resource exhaustion.
Connections not directly initiated by a user should not result in a
message being displayed in the user interface (for example, a
Javascript XMLHttpRequest that generates such an alert).
Lemon Expires December 8, 2016 [Page 3]
Internet-Draft Blocked Site Alerts for TLS June 2016
Because a TLS proxy interposed between the host and the server will
not know the name of the server to which the host is connecting, it
may need to depend on the Server Name Indication extension [2] to
provide different status codes for different servers.
3. Meanings of Alert Descriptions
3.1. Captive Portal
The 'captive_portal' alert description represents a claim by the
server that the host is connected to a network behind a captive
portal. This is a curable condition: the end user may be able to
register with the captive portal, and subsequently a connection to
the same server would not be intercepted, and could succeed. TLS
clients receiving this code may choose to retry the connection
periodically, frequently enough that authenticating would provide a
timely resumption of service.
3.2. Malicious Site
The 'malicious_site' alert description represents a claim by the
server that the host has attempted a connection to a service that is
known by the network administration to serve malicious content (e.g.,
malware, phishing, etc.). This condition is assumed to be a
permanent failure; although it may be that at some future time the
same IP address is no longer marked malicious, the particular
transaction that was attempted is not likely to succeed if retried.
3.3. Policy Violation
The 'policy_violation' alert description represents a claim by the
server that the host has attempted to connect to a site the use of
which is in violation of local policy. For example, connecting to a
porn site from an enterprise network might be a policy violation.
3.4. Account Attention Requested
The 'account_attention_requested' alert description represents a
claim by the server that the network service provider is requesting
that the end user log in to their account. This is a temporary
condition, such that an immediate attempt to reconnect can be
expected to succeed reaching the correct server.
3.5. Account Attention Required
The 'account_attention_required' alert description represents a claim
by the server that the network service provider is insisting that the
end user log in to their account. This is not a temporary condition:
Lemon Expires December 8, 2016 [Page 4]
Internet-Draft Blocked Site Alerts for TLS June 2016
until whatever situation has motivated the service provider to place
this block has been resolved, any further attempt to connect will
result in the same alert description being returned.
4. Acknowledgements
Placeholder
5. IANA Considerations
The IANA is requested to allocate values for the five new TLS Alert
descriptions documented here from the TLS Alert Registry. These are:
TBD captive_portal
TBD malicious_site
TBD policy_violation
TBD account_attention_requested
TBD account_attention_required
6. Security Considerations
This document attempts to avoid creating a channel of attack for a
malicious attacker. However, any bit of information, no matter how
small, can be used as a lever to trick the user into taking some
action which will create an opportunity for attack.
The situation prior to introduction of these new alert messages is
that attackers wanting to trick an end user into taking such an
action can do one of two things: they can simply block the
connection, which will result in the user trying to figure out what
went wrong, or they can send an invalid cert and hope that the user
clicks through the warnings.
A captive_portal alert might be used by the operating system as a
means of directing the end user to log in to a captive portal web
page. An attacker knowing the expected behavior of the operating
system could trigger such an attempt. However, means of triggering
such attempts already exist, so this introduces no new opportunity.
A malicious_site alert has no meaningful user mitigation response
other than to stop trying to visit that site. An attacker might
provide such a response as a way to prevent an end user from
accessing that site in the future. To avoid this, TLS clients that
receive such alerts should not cache them. An end user might still
Lemon Expires December 8, 2016 [Page 5]
Internet-Draft Blocked Site Alerts for TLS June 2016
remember that such a warning was received, and might take it more
seriously than an invalid cert message. There is no means to
mitigate this risk; however, the added value of being able to block
malicious sites likely outweighs the possibility that a malicious
attacker could succeed in tricking the user in this way.
A policy_violation alert might encourage the end user to try to find
some way around the policy. The alternative is to block the
connection entirely, however; this would likely trigger similar
behavior in the end user, so this does not seem to be a substantial
additional risk.
The account_attention_requested and account_attention_required alerts
could be used to trick the end user into going to a faked version of
their provider's site that is not secured using TLS and PKI. The
user could then be tricked into providing authentication credentials
or other personal information. Existing browser mitigation for such
attacks are likely adequate, but it cannot be denied that there is
some additional risk in presenting these messages to the end user.
The messages could be presented along with some advice to the end
user about checking to make sure that the site is secure, or even
provide the user with a user interface element to click that brings
them to a browser window that prevents non-TLS/non-PKI connections
from succeeding.
7. Privacy Considerations
To the extent that HTTP proxies using these alert messages rely on
the Server Name Indication TLS extension [2], there could be a
concern that the end user's privacy might be violated if the proxy
logs the SNI information sent in each request. However, there is no
way at present to prevent a passive listener from capturing such
information, so this does not create a new privacy risk.
8. References
8.1. Normative References
[1] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
8.2. Informative References
Lemon Expires December 8, 2016 [Page 6]
Internet-Draft Blocked Site Alerts for TLS June 2016
[2] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
Author's Address
Ted Lemon
Nominum, Inc.
800 Bridge Parkway
Redwood City, California 94065
United States of America
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Lemon Expires December 8, 2016 [Page 7]