8

I am looking up the behavior of HSTS on both HTTP and HTTPS websites, and their HTTP and HTTPS embedded resources. My understanding is that if an HSTS response header has been passed on by the server in an HTTPS response, or if the site's name is present on the HSTS preload list, then all the resources of that request would be sent on HTTPS.

However, while inspecting some sites via the Firefox Web Inspector, I am noticing some discrepancies. For example, here on cnn.com (an HTTP website), some of the requests of doubleclick.net's subdomains are going over HTTP, even though it is present in the HSTS preload list over here (with include_subdomains:true).

enter image description here

Just to test whether the root domain was sending the HSTS header, I navigated to the ad.doubleclick.net link in the location address bar which directed me to Double Click's main site https://www.doubleclickbygoogle.com Over here the HSTS header is being sent:

enter image description here

Yet, there is no effect on doubleclick's requests on cnn.com when I reload:

enter image description here

Another interesting thing is that when I try to locate the source tag of request on the DOM by going to the Inspector tab, there is no such tag with http://ad.doubleclick.net (strung with some querystrings). The "Cause" and "Type" heading in the inspector seem to indicate its some tracker sort of a pixel.

Does anyone have any idea what could be going on over here?

Improve this question
6
  • Check how the HSTS header was set. Was it set at secureupload.g.double.click.net or doubleclick.net (I strongly suspect the former).
    – grochmal
    Oct 19, 2016 at 9:08
  • By where do you mean the host domain which sends the HSTS header response? That would be https://doubleclickbygoogle.com wouldn't it?
    – QPTR
    Oct 19, 2016 at 9:18
  • 1
    HSTS has a includeSubDomains directive. If the main domain gives you HSTS with IncludeSubDomains that would be the case. But it does not need to be. A subdomain can set HSTS for itself, and other domains at the same level will not get it. (I'm 80-90% sure of that, need to do more RFC reading)
    – grochmal
    Oct 19, 2016 at 9:39
  • Yep. From the RFC: When establishing an HTTP connection to a given host, however instigated, the UA examines its cache of Known HSTS Hosts to see if there are any with domain names that are superdomains of the given host's domain name. If any are found, and of those if any have the includeSubDomains directive asserted, then HSTS Policy applies to the given host. Otherwise, HSTS Policy applies to the given host only if the given host is itself known to the UA as an HSTS Host
    – QPTR
    Oct 19, 2016 at 13:17
  • 1
    +1 for diligent code formatting.
    – 700 Software
    Oct 19, 2016 at 17:18

2 Answers 2

Reset to default
9

To cite from the source code you mention:

354  // Other Google-related domains that must use an acceptable certificate
355  // iff using SSL.
     ...
361  { "name": "doubleclick.net", "include_subdomains": true, "pins": "google" },

This means that the certificate is pinned iff the site is served over https. It does not mean that the site needs to be served over https. This is different for other domains where the force-https attribute is set:

264  { "name": "accounts.google.com", "include_subdomains": true, "mode": "force-https", "pins": "google" },

EDIT: based on the source code of Chromium (function TransportSecurityState::GetStaticDomainState in net/http/transport_security_state.cc) I'll try to explain the information which can be seen in chrome://net-internals/#hsts and how it relates to the static information from net/http/transport_security_state_static.json using the example doubleclick.net:

static_sts_domain: doubleclick.net
static_upgrade_mode: OPPORTUNISTIC

OPPORTUNISTIC is the default mode (STSState::MODE_DEFAULT). This means that it does not force HTTPS. The default mode is used since no explicit force-https setting was given in the configuration.

static_sts_include_subdomains: true

Since it does not enforce https this setting does not matter. But the value might be caused by the configuration of include_subdomains shown above even if this configuration line does not include force-https.

static_sts_observed: 1476162000

This is the build time of the static HSTS/HPKP list, i.e. 2016/09/04 in this case.

static_pkp_domain: doubleclick.net
static_pkp_include_subdomains: true
static_pkp_observed: 1476162000
static_spki_hashes: sha256/IPMbDAjLVSGntGO3WP53X/zilCVndez5YJ2+vJvhJsA=,sha256/7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=,sha256/h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU=

These are the information about pinning. These have a direct relation to the settings shown above (i.e. include_subdomains and which pins should be used).

Improve this answer
8
  • But isn't pinning different from HSTS, in the sense that the pins attribute is relevant only in the case when HPKP header has been sent. What I mean to say is that HSTS in itself is used as a solution for the situation when you have http links, and should be turned on when the root domain of that` HTTP` link has set the include_subdomains attribute. So, what then is the reason for force-https? And how does it connect with `pins' (which is used to decide the certificate we trust)
    – QPTR
    Oct 19, 2016 at 13:33
  • 1
    @QPTR: 'pin' is HPKP, 'force-https' is HSTS. You can have 'pin' without 'force-https' like in case of doubleclick. In this case 'pin' is only relevant if the site is accessed with https and ignored otherwise, i.e. the site is not forced to https. Forcing to https (HSTS) is only done if 'force-https' is set, no matter if combined with 'pin' or without.
    – Steffen Ullrich
    Oct 19, 2016 at 13:53
  • So, basically HSTS applies if force-https is set in that list, and HPKP applies if pins has been set? Got it! So, basically since doubleclick.net has only HPKP policy specified, it means its not there in the HSTS list.
    – QPTR
    Oct 19, 2016 at 14:03
  • 1
    Just one more thing. Here on chrome when I look up in chrome://net-internals/#hsts, I get this policy: static_sts_domain: doubleclick.net static_upgrade_mode: OPPORTUNISTIC static_sts_include_subdomains: true static_sts_observed: 1474693200 static_pkp_domain: doubleclick.net static_pkp_include_subdomains: true Over here, what is the point of including static_sts_include_subdomains and static_pkp_include_subdomains separately? Shouldn't that mean that HSTS is actually specified for subdomains for HSTS as well, in addition to HPKP.
    – QPTR
    Oct 19, 2016 at 14:05
  • What I mean by that is, that given that they have their attributes separately listed, shouldn't that mean that HSTS for doubleclick has indeed been turned on inside Chrome (and chrome dev tools show the request in http as well). Or is it that include_subdomains inside the Chromium list (the one you quote) is just singly listed for both HSTS and HPKP. What happens if on a website, subdomains are included for HSTS but not for HPKP and similarly for max-age? Thanks for the answers, btw, I am just trying to clarify whether force-https is indeed the last word on HSTS.
    – QPTR
    Oct 19, 2016 at 15:37
3

HSTS only apply for the domain it's been set.

What you are looking for is upgrade-insecure-requests CSP directive.

Content-Security-Policy: upgrade-insecure-requests

In the HSTS preload list, doubleclick.net is NOT listed for HSTS for for key pinning.

More details on https://scotthelme.co.uk/migrating-from-http-to-https-ease-the-pain-with-csp-and-hsts/

Improve this answer
3
  • CSP can only be set by the website though? What happens when do not have it set, yet still I want to ensure that embedded third-party requests go via HTTPS if their own root domains have set the HSTS header ?
    – QPTR
    Oct 19, 2016 at 13:37
  • As a user ? Using the extension httpseverywhere is the easiest way. If you prefer doing it manually, just visits manually an https webpage of a webpage of the website that set hsts, it will ensure you that all future requests use https...
    – Tom
    Oct 19, 2016 at 15:08
  • True, but when I visited the home domain of doubleclick, that is doubleclickbygoogle, and then later reloaded the page, it was still continuing onwards as http. No effect. It could be that as Steffen says, the policy for doubleclick.net only applies for HSTS and not for HPKP. But I'll try this for some other requests.
    – QPTR
    Oct 19, 2016 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .