Be explicit that you don't need to update `<a href>` links to be HTTPS
konklone opened this issue · 7 comments
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.
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.
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
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.
@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.
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!
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.
I think this is likely not needed.