Be explicit that you don't need to update <a href> links to be HTTPS

[konklone]

You need to focus on pulling in resources through <link> and <script> tags, but the links on your page don't need to be updated in order to comply.

[elucify]

While that's true, those http:// links back to domains you control do leak; a MITM on http would be able to see the redirects.

[alex]

That's what HSTS is for :-)

On Fri, Oct 14, 2016 at 2:54 PM, Mark Johnson notifications@github.com
wrote:

While that's true, those http:// links back to domains you control do
leak; a MITM on http would be able to see the redirects.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#205 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAADBCHQFPI0-0kOiGGKGowhGoyEh69Oks5qz8_UgaJpZM4KPCZD
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

[elucify]

Yeah, HSTS is great.

Older browsers don't support HSTS, unfortunately. Which is one reason we're spending so much time fixing mixed content issues, since that's what Content-Security-Policy: upgrade-insecure-requests is for. It's a shame that u-i-r support isn't better than it is; it would have made this job a lot easier.

[konklone]

@elucify Totally -- changing as many links as possible to be HTTPS is clearly a positive security goal, and HSTS won't help legacy browsers.

I opened this issue after an inquiry from an agency where they mistakenly believed that updating <a href> links was a compliance requirement of M-15-13, and it's important that agencies not have that impression. As a policy lever, M-15-13 basically asks for two things -- server-side redirects, and HSTS -- and we want to focus all of our compliance "capital" on pushing as hard as we can for those two things.

The lack of u-i-r support in IE/Edge is frustrating. You could make a positive impact on its adoption by publicly noting somewhere how much of a difference it would make in your work. After WIRED posted about their struggles with flagging u-i-r support, Apple prioritized the feature and it's now deployed to Safari in stable iOS and OS X channels. Microsoft may be responsive to federal agencies expressing a need where Edge is the only major outlier.

[elucify]

Yes, https <a href> is clearly not mixed content, although we have interpreted mixed content as a requirement, based on (1) the advice on https.cio.gov (which discusses it pretty extensively), and (2) missing u-i-r means that mixed content == busted page for some clients.

This is somewhat hacky but... might you recommend using JavaScript to update http: hrefs on every page? Many sites have a site-wide JS module or two. Silently updating those links with JavaScript would essentially be a "poor man's u-i-r".

As for encouraging vendors to get on the ball with security features (like u-i-r), maybe cio.gov could take leadership there, along with NIST, to extend the USGCB (https://usgcb.nist.gov/) to include a baseline and test suite for browser security features. I know that's a tall order--remember all the controversy over IE6 at State in 2008--but certainly M-15-13 implies HTTPS support, so why not HSTS and u-i-r? The prospect of being locked out of Federal government IT systems should get every vendor's attention. OTOH USGCB is stale--they still recommend IE8!

[konklone]

but certainly M-15-13 implies HTTPS support, so why not HSTS and u-i-r?

M-15-13 already does require HSTS. :)

although we have interpreted mixed content as a requirement, based on (1) the advice on https.cio.gov (which discusses it pretty extensively), and (2) missing u-i-r means that mixed content == busted page for some clients.

I would interpret it as a recommendation, not a requirement. https.cio.gov also recommends not using SHA-1 or RC4, but those aren't requirements of M-15-13. We've got to pick our requirements battles.

[konklone]

I think this is likely not needed.