Re: Proposal: Marking HTTP As Non-Secure

On 11 Feb 2016, at 09:27, Igor Bukanov <[email protected]> wrote:

> my point is that the warning about plain HTTP cannot be effective unless it is as strong as the current warning about https:// embedding http:// media. If the proposal is to show exactly such strong warning, then fine. But I got an impression that the warning would be much milder.




Hi Igor,

Both situations will (eventually) be exactly the same.


In summary the intention is to only have 3 (possibly 4) different states:

1) Neutral, with Organisation Name (aka HTTPS with EV certificate, and no errors).

2) Neutral (aka HTTPS, and no errors).

3) Non-Secure (everything else, such as HTTP pages, and HTTPS pages with "passive mixed-content").


A 4th one *might* be needed for HTTPS websites with "active mixed-content" (e.g. JavaScript), but it could just be shown as Non-Secure (to indicate that there is a problem).

The reason it might have its own state is due to how browsers handle this situation at the moment.

Currently the browser blocks the active content, displays an icon to show that the page might be broken (e.g. a shield in Chrome), and still shows the page as "secure". This is technically correct, as the insecure content was blocked.

If browsers continue to do this, then the 4th state will also be Neutral, but with an icon to show that the page might be broken (because we all "know" that once JavaScript loads it always works perfectly).

However, as most users still don't know what a shield icon means (fortunately Firefox has recently dropped this), then from a users point of view it might be best to still block the active mixed-content, and show it as Non-Secure (this might mean the webpage gets fixed).

Craig






> On 11 Feb 2016, at 09:27, Igor Bukanov <[email protected]> wrote:
> 
> Hi, Craig,
> 
> my point is that the warning about plain HTTP cannot be effective
> unless it is as strong as the current warning about https:// embedding
> http:// media. If the proposal is to show exactly such strong warning,
> then fine. But I got an impression that the warning would be much
> milder.
> 
> On 11 February 2016 at 10:13, Craig Francis <[email protected]> wrote:
>> Hi Igor,
>> 
>> I think we might be going in circles now, but just to summarise:
>> 
>> Now that all computers are powerful enough, and encryption is so readily available, the only reason for data being unencrypted on the network is because of legacy systems.
>> 
>> We need to find ways to replace those hideously broken (aka legacy) systems, and start warning people how badly broken they are.
>> 
>> This proposal is trying to do just that.
>> 
>> Even if we do get more root certificates from adware / totalitarian governments, it is still considerably better than the current situation... as HTTPS will eventually be seen as "normal" and will not need a lock icon.
>> 
>> Whereas plain text (which is even more vulnerable to adware / totalitarian governments, plus every other kind of problem that HTTP has) will be marked as "Non-Secure" (because there is no question, there is absolutely no security with it).
>> 
>> And actually, your comment about "if users get a warning about mail operators not implementing it, STARTTLS could be everywhere"... well that is what this proposal is basically doing, it is that warning, so that people do start requesting that HTTPS is everywhere :-)
>> 
>> Craig
>> 
>> 
>> 
>> 
>>> On 10 Feb 2016, at 18:22, Igor Bukanov <[email protected]> wrote:
>>> 
>>> Hi, Craig
>>> 
>>> When thinking about many years from now, one just cannot consider
>>> HTTPS alone. It may well be that in a few years from now the current
>>> HTTP/HTTPS debates will be irrelevant as either users will have HTTPS
>>> root certificates from adware companies installed on their computers
>>> that monitors all the traffic for the promise of free Internet or
>>> totalitarian governments will require to proxy all the traffic through
>>> their servers and certificates.
>>> 
>>> So I prefer to talk about the present situation. Currently for
>>> historical reasons https must continue to imply that everything is
>>> encrypted through certificates issued through CA. That includes any
>>> third-party media files. If those media files are not available
>>> through HTTPS, my however limited experience tells that it is a rather
>>> significant barrier for implementing https. Moreover, unless warnings
>>> about HTTP will be on the same scale as a bad impression from a broken
>>> lock icon in the address bar, I just do not see this will change in
>>> near future.
>>> 
>>> That idea about using encryption with http links is just one way to
>>> address this. With that a browser can keep the current status quo with
>>> https while starting strengthening requirements for http until it is
>>> indistinguishable from https.
>>> 
>>> As regarding STARTTLS in SMTP, it is still better than lack of any
>>> encryption whatsoever. And consider if users get a warning about mail
>>> operators not implementing it, STARTTLS could be everywhere.
>>> 
>>> 
>>> On 9 February 2016 at 17:18, Craig Francis <[email protected]> wrote:
>>>> Hi Igor,
>>>> 
>>>> HTTPS doesn't have to mean trusted, anyone can get a free cert now (even those hosting malware).
>>>> 
>>>> This proposal is just thinking about *many* years from now, where everything should be encrypted when it's in transit.
>>>> 
>>>> In the mean time we just need to think what the end result will be, and continue moving in that direction.
>>>> 
>>>> My interpretation of that includes:
>>>> 
>>>> 1) Encryption shall be the default (HTTPS).
>>>> 
>>>> 2) Users don't check if they are using HTTPS, they just assume it is (so no need for a lock icon).
>>>> 
>>>> 3) If the connection is being made over HTTP (unusual/dangerous/wrong), then the user needs to be notified.
>>>> 
>>>> 4) When it comes to trusting certain websites (e.g. banks), then EV certificates will imply a bit more trust (in theory).
>>>> 
>>>> Craig
>>>> 
>>>> 
>>>> 
>>>> PS: I don't think you will be able to put encryption over HTTP, in the same way you cant really trust encryption in email with STARTTLS (aka protocol downgrade attacks)... you really need it to be explicit that you are using HTTPS.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 9 Feb 2016, at 14:42, Igor Bukanov <[email protected]> wrote:
>>>>> 
>>>>> Hi, Craig
>>>>> 
>>>>> I am aware of CSP etc. features that supposes to simplify HTTP->HTTPS
>>>>> transition. However, they do not help at all in the case when the site
>>>>> embeds http-only media from other sites. I do not see anything
>>>>> currently that helps to mitigate against worsening user experience in
>>>>> those cases .
>>>>> 
>>>>> As https:// is supposed to mean a trusted context, I just do not see
>>>>> how to fix that without allowing to serve encrypted context over
>>>>> http:// urls and gradually raising requirements for the encryption
>>>>> there until those match https.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 9 February 2016 at 12:37, Craig Francis <[email protected]> wrote:
>>>>>> Hi Igor,
>>>>>> 
>>>>>> At the moment I completely agree, the web really does have too much of a legacy with the old plain text HTTP protocol.
>>>>>> 
>>>>>> But the browser developers are trying to look beyond that in this proposal.
>>>>>> 
>>>>>> By having this in their mind as the end goal, they can focus on how to make it happen.
>>>>>> 
>>>>>> This is why we have so much work going into upgrade-insecure-requests, HTTP Strict Transport Security, etc.
>>>>>> 
>>>>>> As to the user experience during this transition, they are hoping to make this better... so when you have an image from an insecure website, they are considering not showing a broken lock icon, but simply removing the lock icon all together (aka neutral)... but this is one of those stepping stones.
>>>>>> 
>>>>>> https://googleonlinesecurity.blogspot.com.au/2015/10/simplifying-page-security-icon-in-chrome.html
>>>>>> 
>>>>>> As to your example about gradually migrating a website, while you can't use self-signed certificates like this, you can still setup HTTPS (so you can load your own resources), and prepare the HTTP version of your website by adding a simple CSP header:
>>>>>> 
>>>>>>      Content-Security-Policy-Report-Only:
>>>>>>              default-src https:;
>>>>>>              report-uri https://report-uri.io/report/x...
>>>>>> 
>>>>>> This allows you to collect reports whenever a browser finds a resource that isn't being loaded over HTTPS. When these are all fixed, you can then switch your website over to being HTTPS only :-)
>>>>>> 
>>>>>> More information at:
>>>>>> 
>>>>>> https://scotthelme.co.uk/migrating-from-http-to-https-ease-the-pain-with-csp-and-hsts/
>>>>>> 
>>>>>> Craig
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 8 Feb 2016, at 19:48, Igor Bukanov <[email protected]> wrote:
>>>>>>> 
>>>>>>> On 8 February 2016 at 10:58, Craig Francis <[email protected]> wrote:
>>>>>>> 
>>>>>>>> I certainty take your point that HTTPS is currently more difficult than it needs to be,
>>>>>>> 
>>>>>>> The main practical problem is that HTTPS cannot be enabled gradually
>>>>>>> without worsening user experience. Consider a website that uses images
>>>>>>> from other sites that do not have HTTPS. Then the encryption cannot be
>>>>>>> activated without worsening user experience in form of broken lock
>>>>>>> icons in the address bar. LetsEncrypt does not help to address this.
>>>>>>> Why should one spend even trivial efforts if that worsen the
>>>>>>> experience?
>>>>>>> 
>>>>>>> I really wish there would way to serve encrypted pages over http://
>>>>>>> Then as a site operator I can gradually start, for example, with
>>>>>>> self-encrypted certificate for the main page and user would not spot a
>>>>>>> difference. Then I add encryption for all page resources, then add
>>>>>>> LetsEncrypt certificate. Again, at each stage the user experience
>>>>>>> stays the same even with presence of encrypted media files from other
>>>>>>> sites. Finally, when I know that all resources can be accessed over
>>>>>>> https://, I redirect to htpps:// the main site.
>>>>>> 
>>>> 
>> 

-- 
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]