Best practices for TLS Downgrade
draft-richsalz-httpbis-https-downgrade-02

Document Type Active Internet-Draft (individual)
Last updated 2019-09-19
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
HTTPWG                                                        B. Sniffen
Internet-Draft                                                 M. Bishop
Intended status: Best Current Practice                         E. Nygren
Expires: March 22, 2020                                          R. Salz
                                                     Akamai Technologies
                                                      September 19, 2019

                    Best practices for TLS Downgrade
               draft-richsalz-httpbis-https-downgrade-02

Abstract

   Content providers delivering content via CDNs will sometimes deliver
   content over HTTPS (or both HTTPS and HTTP) but configure the CDN to
   pull from the origin over cleartext and unauthenticated HTTP.  From
   the perspective of a client, it appears that their requests and
   associated responses are delivered over HTTPS, while in reality their
   requests are being sent across the network in-the-clear and responses
   are delivered unauthenticated.  This exposes user request data to
   pervasive monitoring [RFC7258]; it also means response data may be
   tampered with by active adversaries.  Terminating TLS connections on
   a load balancer and contacting a backend over cleartext has long been
   common within data centers, but doing this TLS termination and
   downgrade to HTTP at a CDN introduces additional risk when the
   unprotected traffic is sent over the general Internet, sometimes
   across national boundaries.

   While it would be nice to say "never do this," customer demand,
   content provider use-cases, and market forces today make it
   impossible for CDNs to not support downgrade.  However, following a
   set of best practices can provide visibility into when this is
   happening and can reduce some of the risks.

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 https://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."

Sniffen, et al.          Expires March 22, 2020                 [Page 1]
Internet-Draft                TLS-Downgrade               September 2019

   This Internet-Draft will expire on March 22, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Background and Motivation . . . . . . . . . . . . . . . . . .   2
   2.  Recommended alternatives  . . . . . . . . . . . . . . . . . .   4
   3.  Potential risk mitigations  . . . . . . . . . . . . . . . . .   4
   4.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Alternative approaches  . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     6.1.  Risks of doing downgrade  . . . . . . . . . . . . . . . .   6
     6.2.  Control of the network between the cache and the origin .   6
     6.3.  Confused-deputy issues at the browser or origin . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Background and Motivation

   Browsers are helping drive a push to universal HTTPS through a
   variety of mechanisms, including:

   o  Show HTTP as "not secure"

   o  Showing mixed-content warnings when images or advertisements are
      HTTP on an HTTPS base page

   o  Making "powerful" new web features available only for HTTPS

   On mobile, app stores sometimes require HTTPS for acceptance.

   These factors have pushed many content providers to quickly enable
   HTTPS, even when their origin infrastructure is not ready or not

Sniffen, et al.          Expires March 22, 2020                 [Page 2]
Internet-Draft                TLS-Downgrade               September 2019

   perceived as being ready.  Being able to use a CDN to convert HTTPS
Show full document text