diff --git a/django/http/request.py b/django/http/request.py
index 804db6bf66..98a51f57c8 100644
--- a/django/http/request.py
+++ b/django/http/request.py
@@ -226,13 +226,14 @@ class HttpRequest:
     def scheme(self):
         if settings.SECURE_PROXY_SSL_HEADER:
             try:
-                header, value = settings.SECURE_PROXY_SSL_HEADER
+                header, secure_value = settings.SECURE_PROXY_SSL_HEADER
             except ValueError:
                 raise ImproperlyConfigured(
                     'The SECURE_PROXY_SSL_HEADER setting must be a tuple containing two values.'
                 )
-            if self.META.get(header) == value:
-                return 'https'
+            header_value = self.META.get(header)
+            if header_value is not None:
+                return 'https' if header_value == secure_value else 'http'
         return self._get_scheme()
 
     def is_secure(self):
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 6729d36cb0..6aed2f862f 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -2253,10 +2253,13 @@ By default, ``is_secure()`` determines if a request is secure by confirming
 that a requested URL uses ``https://``. This method is important for Django's
 CSRF protection, and it may be used by your own code or third-party apps.
 
-If your Django app is behind a proxy, though, the proxy may be "swallowing" the
-fact that a request is HTTPS, using a non-HTTPS connection between the proxy
-and Django. In this case, ``is_secure()`` would always return ``False`` -- even
-for requests that were made via HTTPS by the end user.
+If your Django app is behind a proxy, though, the proxy may be "swallowing"
+whether the original request uses HTTPS or not. If there is a non-HTTPS
+connection between the proxy and Django then ``is_secure()`` would always
+return ``False`` -- even for requests that were made via HTTPS by the end user.
+In contrast, if there is an HTTPS connection between the proxy and Django then
+``is_secure()`` would always return ``True`` -- even for requests that were
+made originally via HTTP.
 
 In this situation, configure your proxy to set a custom HTTP header that tells
 Django whether the request came in via HTTPS, and set
diff --git a/docs/releases/1.11.22.txt b/docs/releases/1.11.22.txt
index 91d81890df..58ea68146e 100644
--- a/docs/releases/1.11.22.txt
+++ b/docs/releases/1.11.22.txt
@@ -5,3 +5,23 @@ Django 1.11.22 release notes
 *July 1, 2019*
 
 Django 1.11.22 fixes a security issue in 1.11.21.
+
+CVE-2019-12781: Incorrect HTTP detection with reverse-proxy connecting via HTTPS
+--------------------------------------------------------------------------------
+
+When deployed behind a reverse-proxy connecting to Django via HTTPS,
+:attr:`django.http.HttpRequest.scheme` would incorrectly detect client
+requests made via HTTP as using HTTPS. This entails incorrect results for
+:meth:`~django.http.HttpRequest.is_secure`, and
+:meth:`~django.http.HttpRequest.build_absolute_uri`, and that HTTP
+requests would not be redirected to HTTPS in accordance with
+:setting:`SECURE_SSL_REDIRECT`.
+
+``HttpRequest.scheme`` now respects :setting:`SECURE_PROXY_SSL_HEADER`, if it
+is configured, and the appropriate header is set on the request, for both HTTP
+and HTTPS requests.
+
+If you deploy Django behind a reverse-proxy that forwards HTTP requests, and
+that connects to Django via HTTPS, be sure to verify that your application
+correctly handles code paths relying on ``scheme``, ``is_secure()``,
+``build_absolute_uri()``, and ``SECURE_SSL_REDIRECT``.
diff --git a/docs/releases/2.1.10.txt b/docs/releases/2.1.10.txt
index c572e42623..c5914c23c2 100644
--- a/docs/releases/2.1.10.txt
+++ b/docs/releases/2.1.10.txt
@@ -5,3 +5,23 @@ Django 2.1.10 release notes
 *July 1, 2019*
 
 Django 2.1.10 fixes a security issue in 2.1.9.
+
+CVE-2019-12781: Incorrect HTTP detection with reverse-proxy connecting via HTTPS
+--------------------------------------------------------------------------------
+
+When deployed behind a reverse-proxy connecting to Django via HTTPS,
+:attr:`django.http.HttpRequest.scheme` would incorrectly detect client
+requests made via HTTP as using HTTPS. This entails incorrect results for
+:meth:`~django.http.HttpRequest.is_secure`, and
+:meth:`~django.http.HttpRequest.build_absolute_uri`, and that HTTP
+requests would not be redirected to HTTPS in accordance with
+:setting:`SECURE_SSL_REDIRECT`.
+
+``HttpRequest.scheme`` now respects :setting:`SECURE_PROXY_SSL_HEADER`, if it
+is configured, and the appropriate header is set on the request, for both HTTP
+and HTTPS requests.
+
+If you deploy Django behind a reverse-proxy that forwards HTTP requests, and
+that connects to Django via HTTPS, be sure to verify that your application
+correctly handles code paths relying on ``scheme``, ``is_secure()``,
+``build_absolute_uri()``, and ``SECURE_SSL_REDIRECT``.
diff --git a/docs/releases/2.2.3.txt b/docs/releases/2.2.3.txt
index 2bb8736192..1dd20d3bfd 100644
--- a/docs/releases/2.2.3.txt
+++ b/docs/releases/2.2.3.txt
@@ -4,8 +4,28 @@ Django 2.2.3 release notes
 
 *Expected July 1, 2019*
 
-Django 2.2.3 fixes several bugs in 2.2.2. Also, the latest string translations
-from Transifex are incorporated.
+Django 2.2.3 fixes a security issue and several bugs in 2.2.2. Also, the latest
+string translations from Transifex are incorporated.
+
+CVE-2019-12781: Incorrect HTTP detection with reverse-proxy connecting via HTTPS
+--------------------------------------------------------------------------------
+
+When deployed behind a reverse-proxy connecting to Django via HTTPS,
+:attr:`django.http.HttpRequest.scheme` would incorrectly detect client
+requests made via HTTP as using HTTPS. This entails incorrect results for
+:meth:`~django.http.HttpRequest.is_secure`, and
+:meth:`~django.http.HttpRequest.build_absolute_uri`, and that HTTP
+requests would not be redirected to HTTPS in accordance with
+:setting:`SECURE_SSL_REDIRECT`.
+
+``HttpRequest.scheme`` now respects :setting:`SECURE_PROXY_SSL_HEADER`, if it is
+configured, and the appropriate header is set on the request, for both HTTP and
+HTTPS requests.
+
+If you deploy Django behind a reverse-proxy that forwards HTTP requests, and
+that connects to Django via HTTPS, be sure to verify that your application
+correctly handles code paths relying on ``scheme``, ``is_secure()``,
+``build_absolute_uri()``, and ``SECURE_SSL_REDIRECT``.
 
 Bugfixes
 ========
diff --git a/tests/settings_tests/tests.py b/tests/settings_tests/tests.py
index 280f46f2aa..3770d15a3d 100644
--- a/tests/settings_tests/tests.py
+++ b/tests/settings_tests/tests.py
@@ -378,6 +378,18 @@ class SecureProxySslHeaderTest(SimpleTestCase):
         req.META['HTTP_X_FORWARDED_PROTOCOL'] = 'https'
         self.assertIs(req.is_secure(), True)
 
+    @override_settings(SECURE_PROXY_SSL_HEADER=('HTTP_X_FORWARDED_PROTOCOL', 'https'))
+    def test_xheader_preferred_to_underlying_request(self):
+        class ProxyRequest(HttpRequest):
+            def _get_scheme(self):
+                """Proxy always connecting via HTTPS"""
+                return 'https'
+
+        # Client connects via HTTP.
+        req = ProxyRequest()
+        req.META['HTTP_X_FORWARDED_PROTOCOL'] = 'http'
+        self.assertIs(req.is_secure(), False)
+
 
 class IsOverriddenTest(SimpleTestCase):
     def test_configure(self):