Proposal: Marking HTTP As Non-Secure

classic Classic list List threaded Threaded
228 messages Options
1 ... 9101112
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> On 8 February 2016 at 10:58, Craig Francis <[hidden email]> 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.
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

craig.francis
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On 8 February 2016 at 10:58, Craig Francis <[hidden email]> 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.
>>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> On 8 February 2016 at 10:58, Craig Francis <[hidden email]> 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.
>>>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

craig.francis
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>> On 8 February 2016 at 10:58, Craig Francis <[hidden email]> 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.
>>>>
>>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>
>>>>>> On 8 February 2016 at 10:58, Craig Francis <[hidden email]> 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.
>>>>>
>>>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

craig.francis
On 11 Feb 2016, at 09:27, Igor Bukanov <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 8 February 2016 at 10:58, Craig Francis <[hidden email]> 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.
>>>>>>
>>>>
>>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Jens Engelke
In reply to this post by Chris Palmer
I can image that there are concerns from content providers that there
visitors might be scared by a visual indication of "non-secure". Even if
these content providers offer their content via http:// and https:// a
careless user is taken to http:// if he just enters the hostname in the URL
bar as many consumers do.
If browsers could default to https for "scheme-less" entries in the URL bar
(and fall back to http:// if there is no response), then visiting a
non-secure page is an explicit choice of the end user. These users would
more likely expect (and be used to) visual indicators for non-secure.

<[hidden email]> schrieb am Di., 16. Aug. 2016 um 10:30 Uhr:

> As both a user and sysadmin I really encourage this initiative.
>
> One way to implement this that I think would make non-secure site more
> obvious and would enhance security would be to add a red border to any site
> or frame that isn't secure. Hovering the mouse over the border could
> identify what makes the site/frame non-secure.
>
> An option to disable the borders per site could be added in the site
> permissions so that known sites wouldn't show the border and could be used
> for sites where the border affects functionality.
>
> This should be a fairly simple function to code and I think it would be a
> lot more noticeable than just the address bar notifications. I think user
> education would be fairly easy too.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

PhistucK
The problem is that there may be (and I saw some already) websites that
sort of accidentally offer an HTTPS version (or offer it for the login
screen only) and thus the site is not usable in HTTPS (due to HTTP script
references and so on). The user will never know that it is a protocol issue.

If a website supports HTTPS, it should be responsible - automatically
redirect to HTTPS and serve HTTPS with HTTP Strict Transport Security
headers.


☆*PhistucK*

On Tue, Aug 16, 2016 at 11:56 AM, Jens Engelke <[hidden email]>
wrote:

> I can image that there are concerns from content providers that there
> visitors might be scared by a visual indication of "non-secure". Even if
> these content providers offer their content via http:// and https:// a
> careless user is taken to http:// if he just enters the hostname in the
> URL bar as many consumers do.
> If browsers could default to https for "scheme-less" entries in the URL
> bar (and fall back to http:// if there is no response), then visiting a
> non-secure page is an explicit choice of the end user. These users would
> more likely expect (and be used to) visual indicators for non-secure.
>
> <[hidden email]> schrieb am Di., 16. Aug. 2016 um 10:30 Uhr:
>
>> As both a user and sysadmin I really encourage this initiative.
>>
>> One way to implement this that I think would make non-secure site more
>> obvious and would enhance security would be to add a red border to any site
>> or frame that isn't secure. Hovering the mouse over the border could
>> identify what makes the site/frame non-secure.
>>
>> An option to disable the borders per site could be added in the site
>> permissions so that known sites wouldn't show the border and could be used
>> for sites where the border affects functionality.
>>
>> This should be a fairly simple function to code and I think it would be a
>> lot more noticeable than just the address bar notifications. I think user
>> education would be fairly easy too.
>
> --
> 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 [hidden email].
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
1 ... 9101112