Re: ATS fails for one subdomain, succeeds for another
Re: ATS fails for one subdomain, succeeds for another
- Subject: Re: ATS fails for one subdomain, succeeds for another
- From: Daniel Jalkut <email@hidden>
- Date: Tue, 5 Dec 2017 09:35:27 -0500
> On Dec 5, 2017, at 3:12 AM, Quinn The Eskimo! <email@hidden> wrote:
>
> I suspect B.2. is what’s going on here. That is, the HSTS entry has
> rewritten your HTTP URL to HTTPS before it hits the wire, and thus it’s never
> blocked by ATS.
Thank you, Quinn! I do think you must have pegged the answer. I was not
familiar with HSTS but now that I’ve read up on it it matches the scenario
nicely. Wordpress.com does indeed include a Strict-Transport-Security header in
its responses.
The only thing that eludes me is not being able to figure out how to prompt the
system to cache the HSTS status for the second domain. It’s mostly an academic
curiosity at this point, but it since I’ve been loading the second domain’s
URLs in web views, across NSURLSession data tasks, etc., I might have expected
by now that its HSTS status would be cached.
> B.2. For those not on the list, if the client ever sees the HSTS header it
> can cache that knowledge outside of the standard `NSURLCache`.
Do you have any insights about logic the system uses when deciding whether to
cache the information, and at which level of the frameworks it’s done? I’m
guessing it would be at the CFNetwork layer. Do you think it might be a bug, or
at least an opportunity for improvement, that the system is not caching my
HSTS-compliant target (sub)domain?
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden