Re: Proposal: Marking HTTP As Non-Secure

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.
>>