Re: Testing W3C's HTTPS setup

Also consider upping that max-age for the HSTS headers to a longer time once this is sorted. Smart move to make the HSTS time very low during initial rollout.

Aloha,
--
Jim Manico
Global Board Member
OWASP Foundation
https://www.owasp.org

> On Sep 21, 2015, at 9:58 AM, Eric Mill <eric@konklone.com> wrote:
> 
> I'm a little confused as to the barrier here -- like Mike said, it's never been the case that HSTS would fix mixed-content warnings, even with CSP upgrade-insecure-requests. There have been some proposals to this effect, but nothing is finalized in any browser, and only Mozilla has indicated clear interest.
> 
> As an outsider, I can say that it looks pretty weird for the W3C to not have HTTPS figured out yet. Are there ways for outsiders to help identify or fix mixed content issues? I'll run some sed commands on a folder full of flat text files to help the W3C any time. :)
> 
> -- Eric
> 
>> On Mon, Sep 21, 2015 at 8:06 AM, Mike West <mkwst@google.com> wrote:
>>> On Mon, Sep 21, 2015 at 1:48 PM, Jose Kahan <jose.kahan@w3.org> wrote:
>>> We need a solution that will allow to assume all content is https,
>>> in perpetuity, without needing to upgrade all legacy content.
>> 
>> That seems like an unfortunate design decision. I hope you'll change your mind over time. :)
>>  
>>> > I guess it's not clear to me why you're fine with the current setup for
>>> > browsers like Safari, but aren't fine with it for Firefox? Wouldn't you
>>> > just treat Firefox like every other browser that doesn't support the
>>> > upgrade directive? That is:
>>> >
>>> > * If you don't see an `upgrade-insecure-requests` header in the navigation
>>> > to `http://w3.org/`, don't redirect to HTTPS.
>>> 
>>> That's how we set it up.
>> 
>> Great! In that case, I still don't understand the problem. If Firefox/Safari/Edge don't support the features that you need, and you're not redirecting them, what is the problem that would cause you to roll back the change?
>> 
>>> > * If you don't see an `upgrade-insecure-requests` header in a navigation to
>>> > `https://w3.org`, downgrade to HTTP (and don't serve HSTS)?
>>> >
>>> > This use case is why we added the signaling header. :)
>>> 
>>> That doesn't make sense. When browsing protected resources, you need
>>> HTTP, you cannot downgrade it to HTTP systematically. What I think
>>> you mean to say is that for public resources, apply the rule you said.
>>> I may be missing some of the context in your statement.
>> 
>> I'm sure the setup you're working with will have some special cases (like resources behind the login wall being HTTPS-only). Those special cases shouldn't see any change in behavior from today, however, right? Firefox still works correctly on those pages.
>> 
>> I suppose I should have been more specific. If you don't see an `upgrade-insecure-requests` header in a request for a page which requires `upgrade-insecure-requests` to function correctly, then you should downgrade that request from HTTPS to HTTP. Does that make sense?
>> 
>> -mike
> 
> 
> 
> -- 
> konklone.com | @konklone