I read something else in the RFC (section-11.4*)* that seemed like a
contraction to your references, but after re-reading it I believe the
Firefox for Linux Mint implementation is correct per the RFC though
problematic for my configuration. I still have a question as to why
Firefox for Windows, Firefox for Ubuntu and Chrome for Windows, Mint and
Ubuntu all behave differently than Firefox for Mint.
Thanks,
Arthur
On 10/4/2015 8:49 AM, =JeffH wrote:
> It seems like the handling of HSTS is incorrect in Firefox on Linux
Mint
> per RFC6797 11.4.1,
>
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
> and when compared to Google Chrome. I don't have the includeSubDomains
> flag set in the Strict-Transport-Security HTTP header, but Firefox
> upgrades the connection when I connect to the server on TCP 443 (Nginx)
> or TCP 8080 (Jenkins). The header is only set when connecting on TCP
> 443, so it should only be upgraded on TCP 443 unless I have the
> includeSubDomains flag set in the Strict-Transport-Security HTTP header
> and I don't.
Well, the above is correct behaviour per RFC6797
<https://tools.ietf.org/html/rfc6797>:
...
1. Introduction
...
This specification also incorporates notions from [JacksonBarth2008]
in that policy is applied on an "entire-host" basis: it applies to
HTTP (only) over any TCP port of the issuing host.
...
5.4. User Agent HSTS Policy Enforcement
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. See
Section 8.3 ("URI Loading and Port Mapping") for details.
...
8.3. URI Loading and Port Mapping
Whenever the UA prepares to "load" (also known as "dereference") any
"http" URI [RFC3986] (including when following HTTP redirects
[RFC2616]), the UA MUST first determine whether a domain name is
given in the URI and whether it matches a Known HSTS Host, using
these steps:
1. Extract from the URI any substring described by the host
component of the authority component of the URI.
2. If the substring is null, then there is no match with any Known
HSTS Host.
3. Else, if the substring is non-null and syntactically matches the
IP-literal or IPv4address productions from Section 3.2.2 of
[RFC3986], then there is no match with any Known HSTS Host.
4. Otherwise, the substring is a given domain name, which MUST be
matched against the UA's Known HSTS Hosts using the procedure in
Section 8.2 ("Known HSTS Host Domain Name Matching").
5. If, when performing domain name matching any superdomain match
with an asserted includeSubDomains directive is found, or, if no
superdomain matches with asserted includeSubDomains directives
are found and a congruent match is found (with or without an
asserted includeSubDomains directive), then before proceeding
with the load:
The UA MUST replace the URI scheme with "https" [RFC2818], and
if the URI contains an explicit port component of "80", then
the UA MUST convert the port component to be "443", or
if the URI contains an explicit port component that is not
equal to "80", the port component value MUST be preserved;
otherwise,
if the URI does not contain an explicit port component, the UA
MUST NOT add one.
NOTE: These steps ensure that the HSTS Policy applies to HTTP
over any TCP port of an HSTS Host.
NOTE: In the case where an explicit port is provided (and to a
lesser extent with subdomains), it is reasonably likely that
there is actually an HTTP (i.e., non-secure) server running on
the specified port and that an HTTPS request will thus fail
(see item 6 in Appendix A ("Design Decision Notes")).
...
HTH,
=JeffH
This e-mail and any attachments may contain CONFIDENTIAL information, including
PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or
disclosure of this information is STRICTLY PROHIBITED; you are requested to
delete this e-mail and any attachments, notify the sender immediately, and
notify the Mediture Privacy Officer at privacyoffi...@mediture.com.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
