Proposal: Marking HTTP As Non-Secure

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

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
On 16 December 2014 at 01:18, Ryan Sleevi <[hidden email]> wrote:

> "Authentication" here does not refer to "Does the user authenticate
> themselves to the site" (e.g. do they log in), but "Is the site you're
> talking to the site you the site you expected" (or, put differently, "Does
> the server authenticate itself to the user").
>

With protocols like SRP or J-PAKE authentication in the first sense (log
in) also provides authentication in the second sense (protocols ensures
mutual authentication between the user and the server without leaking
passwords). I wish there would be at least some support in the browsers for
these protocols so one could avoid certificates and related problems in
many useful cases.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

Andy Wingo-5
In reply to this post by Ryan Sleevi-2
On Tue 16 Dec 2014 06:35, Ryan Sleevi <[hidden email]> writes:

> scheme-relative URLs are awesome, and we should encourage them (over
> explicit http://-schemed URLs)

Isn't it an antipattern to make a resource available over HTTP if it is
available over HTTPS?  In all cases you could just use HTTPS; no need to
provide an insecure option.

The one case that I know of when scheme-relative URLs are useful is when
HTTPS is not universally accessible, e.g. when the server only supports
TLSv1.2 and so is not reachable from old Android phones, among other
UAs.  In that case scheme-relative URLs allow you to serve the same
content over HTTPS to browsers that speak TLSv1.2 but also have it
available insecurely to older browsers.

If there is mention of scheme-relative URLs in a "Marking HTTP as
Non-Secure" set of guidelines for authors and site operators, it should
be to avoid them in favor of explicitly using the HTTPS scheme.

Andy
_______________________________________________
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

Sigbjørn Vik
In reply to this post by Chris Palmer
I am happy to see this initiative, I consider the current standard
browser UI broken and upside-down. Today, plain http is not trustworthy,
but it still has the "normal" look in browsers. We ought to change this.

A few thoughts:

Users expect that when they come to a site that looks like Facebook, it
is Facebook. They expect any problems to be flagged, and unless there is
a warning, that everything is OK. They do not understand what most
icons/colors and dialogs mean, and are confused by the complexity of
security (and the web in general). A good UI should present the web the
way the user expects it to be presented. Expecting users to spend their
time learning and memorizing various browser UIs (user education) is
arrogant. Starting this discussion from the implementation details is
starting it in the wrong end.

One example of an experimental browser UI is Opera Coast. It goes much
further than cleaning up the security symbols, it removes the entire
address field. It uses a lot of extra background checks, with the aim to
allow users to browse without having to check addresses. If something
seems wrong, it will warn the user ahead of time. This seems to me to be
the ideal, where security is baked into the solution, not tacked on top.
From a user's perspective, it just works. I think revamping address bars
and badges should take the long term goal into consideration as well.
(I'll happily discuss Coast's solutions, but please start a new thread
if so.)

Browsers normally have 3-5 different visual security states in the UI;
normal (no security), DV and EV. Some browsers have special visual
indicators for various types of broken security (dubious, bad, etc). In
addition there are a multitude of corner cases. Although I can see the
use of three states, to support gradual degradation via the middle
state, more than three states is confusing, and the ideal should be
none, as in the above example.

Given three states for now, the question is how we want to display them.
We need one for general unsecured contents. We want one for top
security, i.e. all the latest encryption standards and EV. Then general
encryption would go into the last bucket. Encryption standards will have
to change over time. From a user perspective, a natural way to mark
three states would be as insecure (red/warning), normal (neutral/no
marking) and secure (green/padlock).

There is no need to distinguish unsecured from dubiously secured, they
can just go into the same bucket. There isn't even any need to warn
users about certificate errors, the UI is just downgraded to insecure,
as a self-signed site is no less secure than an http site. There are
technical reasons for the warnings, but those can be bug-fixed. Active
attacks (e.g. certificate replacement to an invalid one, HSTS failure,
revoked certificates, ...) might still be hard-blocked, but note that
this constitutes a fourth state, and the UI is becoming very complicated
already - there are probably better ways to map such cases into the
insecure state, but that is a separate discussion.

One issue is that browser UI is and should be a place for innovation,
not rigid specifications. At the same time, users would clearly benefit
from consistent and good UI. Diverging from the de-facto UI standard
towards a better one comes with a cost for browsers, and they might not
have the incentive to do so. A coordinated move towards a better future
would be good, as long as we avoid the hard limitations. Regardless of
this discussion, we do need better coordination for removing old crypto
standards (SHA-1, SSLv3, RC4, ...) from the "secure" bucket in the UI.
In short, I am all for a coordinated move, but there needs to be space
for browsers to innovate as well.

In terms of the transition plan, I think a date-based plan is the only
thing which will work. This gives all parties time to prepare, they know
when the next phase will start, and nobody will be arguing if we have
reached a milestone or not. It also avoids any deadlocks where the next
phase is needed to push the web to the state where the next phase will
begin. Any ambitious timeline will fail to get all players on board. A
multi-year plan is still better than the resulting user confusion if
browsers move on their own.

BTW, have you explicitly contacted other browser teams?

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

Security UI Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

chaals
In reply to this post by Peter Kasting
16.12.2014, 05:02, "Peter Kasting" <[hidden email]>:
On Mon, Dec 15, 2014 at 5:50 PM, Christian Heutger <[hidden email]> wrote:
> So, assuming we have HTTP vs HTTPS-EV/HTTPS-DV, how best should UAs communicate to the user the lack of security guarantees from HTTP.
 
I would recommend here as mentioned:
 
No padlock, red bar or red strike, … => no encryption [and no validation], e.g. similar to SHA1 deprecation in worst situation
Only vs. HTTPS: Padlock => everything fine and not red, „normal“ address bar behavior
With EV differentiation: Padlock, yellow bar, yellow signal, … => only encryption, e.g. similar to current mixed content, …
EV: Validation information, Padlock green bar, no extras, … => similar to current EV
 
Red-Yellow-Green is recognized all other the world, all traffic signals are like this, explanation on what signal means what can be added to the dialog on click. (Red) strike, (yellow) signal, (green) additional validation information follow also the idea to have people without been able to differentiate colors to understand what happens here.
 
Please don't try to debate actual presentation ideas on this list.  How UAs present various states is something the individual UA's design teams have much more context and experience doing, so debating that sort of thing here just takes everyone's time to no benefit, and is likely to rapidly become a bikeshed in any case.
 
As the very first message in the thread states, the precise UX changes here are up to the UA vendors.  What's more useful is to debate the concept of displaying non-secure origins as non-secure, and how to transition to that state over time.
 
Certainly doing UI before understanding what we want to convey is backwards. On the other hand, it is not true that we should not discuss UI on (at least some of these) lists. Users benefit not only from good UI, but also from consistent UI - even when it's not that clever, recognising things from everywhere else can help them (or hurt them, if someone does something different that confuses them).
 
cheers
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
[hidden email] - - - Find more at http://yandex.com
 

_______________________________________________
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

ianG-2
In reply to this post by Igor Bukanov-2
On 14/12/2014 19:46 pm, Igor Bukanov wrote:

> On 14 December 2014 at 20:32, Michael Ströder <[hidden email]> wrote:
>
>> if you
>> force everybody to speak HTTPS you might endorse leveraging central SSL
>> reverse proxies leading to even easier traffic interception.
>>
>
> Indeed. In a https-only world ISP may just require for the user to install
> their certificate. Still it will be better than the current situation when
> it is very cheap to sniff on a neighbor cable-modem link or with a fake GSM
> node and revert the situation to the one that was several years ago when
> sniffing was realistically possible only on the level of ISP.


Yup.  We are moving from a world where everyone can sniff more or less
everything because there is so much leakage ... to a world where ISPs
and other neerdowhellers will have to do an active attack in order to do
their sniffing.

This is definitively a better result because an active attack can be
detected.  A passive attack by its nature is undetectable.  We can fight
the former, not the latter.



iang

_______________________________________________
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

ianG-2
In reply to this post by Chris Palmer
On 14/12/2014 19:04 pm, Chris Palmer wrote:

> On Sun, Dec 14, 2014 at 10:47 AM, Michael Ströder <[hidden email]>
> wrote:
>
> Chris Palmer wrote:
>>> Reducing the number of parties you have to trust from [ the site
>> operator,
>>> the operators of all networks between you and the site operator ] to
>> just [
>>> the site operator ] is a huge win.
>>
>> Yes, I agree. But to really guarantee this you would have to block all the
>> shiny SSL facade reverse proxy services out there. ;-)
>>
>
> That edges up to the remote attestation problem (which is unsolvable). We
> just want the browser to tell the truth about what it can determine.
>
> If the site operator chooses to deploy in a not perfectly safe manner, that
> is a separate problem that the community will have to solve by other means.
>
>
>> I suspect your approach will rather make people rush into using such
>> central
>> SSL fake services and data is transmitted in clear behind the service. If
>> this
>> happens those services will be an even more attractive interception point.
>> <https://lists.mozilla.org/listinfo/dev-security>
>>
>
> We will have to try to deal with that somehow (most likely at "layer 8").
> But, are you saying that, for this reason, the status quo is somehow
> acceptable or even preferable?


Improvement is always useful.  However any improvement in one area
raises questions in another area.  In general, if you're improving X
while not improving Y, there is always the possibility that you're
getting too far ahead with X and wasting the work.

In more particularity, the issue of pushing people to HTTPS all over
raises questions of javascript & domain rich sites, HTTPS proxy servers,
how to get the certs easily into web servers, goals of encryption v.
authentication, how to display who says what, etc etc.

These might be intractable questions.  But, the reason we started the
push to HTTPS everywhere in 2005 or so was that these questions can only
be answered if we push everyone into that situation.

I guess the issue here is that we need to be holistic.  Push for
improvements in all areas, and be somewhat patient with those areas that
push too fast.

Pushing for HTTPS everywhere is like harsh medicine.  Tastes disgusting
and makes you gag, but totally necessary.



iang
_______________________________________________
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

Chris Palmer
In reply to this post by Sigbjørn Vik
On Tue, Dec 16, 2014 at 5:59 AM, Sigbjørn Vik <[hidden email]> wrote:

> There is no need to distinguish unsecured from dubiously secured, they
> can just go into the same bucket. There isn't even any need to warn
> users about certificate errors, the UI is just downgraded to insecure,
> as a self-signed site is no less secure than an http site. There are
> technical reasons for the warnings, but those can be bug-fixed. Active
> attacks (e.g. certificate replacement to an invalid one, HSTS failure,
> revoked certificates, ...) might still be hard-blocked, but note that
> this constitutes a fourth state, and the UI is becoming very complicated
> already - there are probably better ways to map such cases into the
> insecure state, but that is a separate discussion.

Well, we do have to make sure that the browser does not send cookies
to an impostor origin. That's (1 reason) why Chrome uses interstitial
warnings today.

We could do away with interstitials if the definition of the origin
included some notion of cryptographic identity — e.g. (HTTPS,
facebook.com, 443, [set of pinned keys]) instead of just (HTTPS,
facebook.com, 443) — but there'd still be problems with that, and very
few site operators are currently able to commit to pinning right now.
(And, that might never change.)

> BTW, have you explicitly contacted other browser teams?

This mass mailing is that.
_______________________________________________
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

Jeffrey Walton
In reply to this post by Donald Stufft
 > "If someone thinks their users are OK with their website not having

> integrity/authentication/privacy"
>
> That is an assumption that doesn't apply to every website. Many websites
> don't even have authentication.
>
> "Presumably these users would still be OK with it after Chrome starts making
> the situation more obvious."
>
> Or perhaps it doesn't, and it scares them away. Just like with the cookie
> bars, where now every user believes all cookies are evil. You assume users
> are able to make an informed decision based on such warnings, and I doubt
> that.
>
> "Presumably these users would still be OK with it after Chrome starts making
> the situation more obvious"
>
> If users are unable to make an informed choice than I personally believe
> it’s up to the User Agent to try and pick what choice the user most likely
> wants.
Makes sense to me, but others have complained that it will break the web.

For example, allowing mixed content when a user specifically asked for
HTTPS seems like a [obvious] bad thing.

As another example, location data is classified as high value. The
code or API that operates on the data is also high value. As such, it
needs a secure origin. Allowing mixed content so the sensitive
location data acquired from sensitive API calls data can be backhauled
over HTTP seems like a [obvious] bad thing.

Both examples seem bad because it does not meet user's expectations
(especially when a user specifically requested an HTTPS page).

But asking for that enforcement on the user's behalf drew some
negative criticism.

> I have a hard time imagining that most users, if given the choice
> between allowing anyone in the same coffee shop to read what they are
> reading and not allowing, would willingly choose HTTP over HTTPS.
+1.

Peter Gutmann has a lot to say about users and their behaviors in
Engineering Security
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). Be sure to
check out Chapter 3, Psychology. In particular, see the section "How
Users Make Decisions" on page 125.

Jeff
_______________________________________________
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

tylerl
In reply to this post by Sigbjørn Vik
First of all, some change along these lines is absolutely necessary is it
closes a huge hole that has been successfully exploited since the Netscape
days. That is, while browsers indicate positive security for TLS, they make
no indication at all in the case no security, leaving ample room for
website content to fill that void. Call this the "Green padlock favicon"
problem if you like.

Some notable points:

Given these roughly 3 distinct scenarios with respect to connection status:

A: The connection is successfully secured. (HTTPS)
B: No security was attempted. (HTTP)
C: Securing the connection has failed. (Certificate validation failure)

A few people have said that B and C are roughly identical from a security
perspective and could be represented as the same state -- in both cases no
security is provided. I would disagree here. In the case of the failed
certificate verification, the client has attempted to secure the connection
and that attempt has failed. In the case of HTTP, the client made no
indication of a preference for security. While scenario B represents the
*absence* of security, scenario C represents the *failure* of security, and
is therefore more troublesome. While we want to raise the awareness of
scenario B, we shouldn't promote it to the severity of scenario C. Doing so
conflates two very different cases and failure modes; while both represent
the absence of verifiable transport security, the latter indicates that the
user's expressed expectation of security has not been met, while the former
simply reflects the absence of any expectation of security.

With respect to EV vs DV/DANE certificates, that discussion should be
completely separate from this. No further comment necessary.

Finally, it's worth noting that reports from the field in response to the
Chrome SHA-1 sunsetting initiative have shown that even the most minor of
warnings has a measurable impact on site operators. I've received many
reports from operators large and small indicating visible losses of revenue
due to the nearly-hidden warning Chrome currently displays for a SHA-1 cert
with a long expiration. This suggests that the UX changes surrounding
security needn't initially be intrusive to have a strong impact on site
operations. An unobtrusive but centrally-located notice to the effect of
"your connection has not been secured" is indisputably accurate, conveys no
bias or agenda, and yet can be expected to produce a sea-change of behavior
for site operators.

It's like bike locks: they're functional and highly visible, but also
optional. Still, if one day someone started putting up signs saying "this
bike has no lock", even though it's telling you nothing you couldn't
already see, behavior would immediately change.
_______________________________________________
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

Sigbjørn Vik
On 17-Dec-14 08:48, [hidden email] wrote:

> Given these roughly 3 distinct scenarios with respect to connection status:
>
> A: The connection is successfully secured. (HTTPS)
> B: No security was attempted. (HTTP)
> C: Securing the connection has failed. (Certificate validation failure)
>
> A few people have said that B and C are roughly identical from a
> security perspective and could be represented as the same state -- in
> both cases no security is provided. I would disagree here. In the case
> of the failed certificate verification, the client has attempted to
> secure the connection and that attempt has failed. In the case of HTTP,
> the client made no indication of a preference for security. While
> scenario B represents the *absence* of security, scenario C represents
> the *failure* of security, and is therefore more troublesome. While we
> want to raise the awareness of scenario B, we shouldn't promote it to
> the severity of scenario C. Doing so conflates two very different cases
> and failure modes; while both represent the absence of verifiable
> transport security, the latter indicates that the user's expressed
> expectation of security has not been met, while the former simply
> reflects the absence of any expectation of security.

I respectfully, but strongly, disagree :) If you want to separate the
states, I'd say that C is better than B. C has *some* security, B has
*none*. Consider a self-signed certificate, where the site owner chooses
to provide what little security he can, this is still much better than
plain old http. Or a certificate expired by one day, which is the same
certificate that the browser has seen on that site for the 2 years past,
this is still way better than B.

If a malicious actor can get write access to a page with status C, he
can immediately change the security level to status B anyway. Redirect
the page to http://official-looking.subdomain-facebook.com, and present
B, so displaying B as better doesn't help users much against attacks. If
a malicious actor does not have write access to a page with status C,
then status C is already better than status B. If the browser can detect
an active attack (like the login form having moved to http from https or
replacement of a good certificate by a bad one) then the browser should
of course warn against the attack, but that is a different scenario.

In most cases, users type 'facebook.com', and give no preference for
security. Any such preference is a server preference. The same holds for
clicking links, the user has no expectation of where he will be taken.
For bookmarks, or cases where the user explicitly types 'https://', the
user might have an expectation of security. If he does, and the security
level of the page indicates either B or C, he should immediately be
alerted anyway. If you think this indicates an explicit preference for
security, then the browser could warn similar to an active attack in
these cases.

But my main point against this is still that you need an entire
paragraph to explain the difference, to people who already know the
background. A user wants to know if he is secure or not, not if his
'facebook.com' request was intercepted on the way and replaced by a http
MiTM (status B, really bad), or if 'facebook.com' made a bug leaving you
exposed (status C, pretty bad). Most users wouldn't understand the
difference. I consider it arrogant trying to force users to understand
the difference, most users just want to go to facebook, not get a
lecture on internet safety. I consider it harmful to try to display the
difference, as the more states we have in the UI, the more users have to
learn, which means they will remember less, and the states become less
meaningful. Keep it simple, and keep to user expectations, not
implementation details.

As a consumer buying bread, you want to know if the bread is safe to eat
or not. Whether the farmer tried to control pesticide usage and failed,
or he didn't try to control it, makes little difference. Professional
health and safety inspectors (akin to browser and web developers) are
about the only ones who care.

> I've
> received many reports from operators large and small indicating
> visible
> losses of revenue due to the nearly-hidden warning Chrome currently
> displays for a SHA-1 cert with a long expiration.

Are you able to share more details on this?

--
Sigbjørn Vik
Opera Software
_______________________________________________
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

Håvard Molland
In reply to this post by Chris Palmer
On 16. des. 2014 21:10, 'Chris Palmer' via Security-dev wrote:
> Well, we do have to make sure that the browser does not send cookies
> to an impostor origin. That's (1 reason) why Chrome uses interstitial
> warnings today.
I've been experimenting with a Chromium patch where the url context is
given two cookie stores,  "standard" and "insecure https" (this being
adapted to the current scheme where we don't warn about http). After the
connection has been established but before the request is sent, the
appropriate cookies are picked from the stores based on the security
state of the connection.  Secure cookies going over a good tls
connection and all http cookies are picked from the "normal" store,
while secure cookies going over a bad tls connection is picked from the
"insecure https" store. This stops secure cookies received on a good
connection from being sent to an imposter origin.

However, to remove the interstitial warning, most offline storages would
have to be separated into two caches, to avoid cache poisoning. Examples
are appcache, service workers, fileapi, dom storage, indexed db and the
standard disk cache. This would be a huge undertaking to get right and
maintain.

Separating the cookie store still has some value even without removing
the interstitial warning though.

>> BTW, have you explicitly contacted other browser teams?
> This mass mailing is that.

Hopefully all the relevant Browser UI teams read these lists.

--
---
Opera Software

_______________________________________________
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

Adrienne Porter Felt-3
In reply to this post by Sigbjørn Vik
We plan to continue treating B and C differently. If there is a validation
failure (C), Chrome will show a full-page interstitial. That will not be
the case for HTTP (B). They will look the same in the URL bar because they
are both insecure but the overall experience will be quite different.

On Wed, Dec 17, 2014 at 3:52 AM, Sigbjørn Vik <[hidden email]> wrote:

>
> On 17-Dec-14 08:48, [hidden email] wrote:
>
> > Given these roughly 3 distinct scenarios with respect to connection
> status:
> >
> > A: The connection is successfully secured. (HTTPS)
> > B: No security was attempted. (HTTP)
> > C: Securing the connection has failed. (Certificate validation failure)
> >
> > A few people have said that B and C are roughly identical from a
> > security perspective and could be represented as the same state -- in
> > both cases no security is provided. I would disagree here. In the case
> > of the failed certificate verification, the client has attempted to
> > secure the connection and that attempt has failed. In the case of HTTP,
> > the client made no indication of a preference for security. While
> > scenario B represents the *absence* of security, scenario C represents
> > the *failure* of security, and is therefore more troublesome. While we
> > want to raise the awareness of scenario B, we shouldn't promote it to
> > the severity of scenario C. Doing so conflates two very different cases
> > and failure modes; while both represent the absence of verifiable
> > transport security, the latter indicates that the user's expressed
> > expectation of security has not been met, while the former simply
> > reflects the absence of any expectation of security.
>
> I respectfully, but strongly, disagree :) If you want to separate the
> states, I'd say that C is better than B. C has *some* security, B has
> *none*. Consider a self-signed certificate, where the site owner chooses
> to provide what little security he can, this is still much better than
> plain old http. Or a certificate expired by one day, which is the same
> certificate that the browser has seen on that site for the 2 years past,
> this is still way better than B.
>
> If a malicious actor can get write access to a page with status C, he
> can immediately change the security level to status B anyway. Redirect
> the page to http://official-looking.subdomain-facebook.com, and present
> B, so displaying B as better doesn't help users much against attacks. If
> a malicious actor does not have write access to a page with status C,
> then status C is already better than status B. If the browser can detect
> an active attack (like the login form having moved to http from https or
> replacement of a good certificate by a bad one) then the browser should
> of course warn against the attack, but that is a different scenario.
>
> In most cases, users type 'facebook.com', and give no preference for
> security. Any such preference is a server preference. The same holds for
> clicking links, the user has no expectation of where he will be taken.
> For bookmarks, or cases where the user explicitly types 'https://', the
> user might have an expectation of security. If he does, and the security
> level of the page indicates either B or C, he should immediately be
> alerted anyway. If you think this indicates an explicit preference for
> security, then the browser could warn similar to an active attack in
> these cases.
>
> But my main point against this is still that you need an entire
> paragraph to explain the difference, to people who already know the
> background. A user wants to know if he is secure or not, not if his
> 'facebook.com' request was intercepted on the way and replaced by a http
> MiTM (status B, really bad), or if 'facebook.com' made a bug leaving you
> exposed (status C, pretty bad). Most users wouldn't understand the
> difference. I consider it arrogant trying to force users to understand
> the difference, most users just want to go to facebook, not get a
> lecture on internet safety. I consider it harmful to try to display the
> difference, as the more states we have in the UI, the more users have to
> learn, which means they will remember less, and the states become less
> meaningful. Keep it simple, and keep to user expectations, not
> implementation details.
>
> As a consumer buying bread, you want to know if the bread is safe to eat
> or not. Whether the farmer tried to control pesticide usage and failed,
> or he didn't try to control it, makes little difference. Professional
> health and safety inspectors (akin to browser and web developers) are
> about the only ones who care.
>
> > I've
> > received many reports from operators large and small indicating
> > visible
> > losses of revenue due to the nearly-hidden warning Chrome currently
> > displays for a SHA-1 cert with a long expiration.
>
> Are you able to share more details on this?
>
> --
> Sigbjørn Vik
> Opera Software
>
_______________________________________________
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

Sigbjørn Vik
On 17-Dec-14 17:22, 'Adrienne Porter Felt' via Security-dev wrote:
> We plan to continue treating B and C differently. If there is a
> validation failure (C), Chrome will show a full-page interstitial. That
> will not be the case for HTTP (B). They will look the same in the URL
> bar because they are both insecure but the overall experience will be
> quite different.

Looking the same in the URL bar is already a good improvement on today.
However, the interstitial will continue to provide a negative incentive
to webmasters to attempt to apply security, as if they get it wrong,
users get a worse experience. Going for http might just be the safer
choice. The interstitial thus has the opposite effect of what this
proposal aims to achieve.

In an ideal world, where there were no technical reasons for the
interstitial (meaning the browser wouldn't leak cookies or other data
and the user would be at least as secure as when using http), would you
still want to show it to users? And if so why?


> On Wed, Dec 17, 2014 at 3:52 AM, Sigbjørn Vik <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 17-Dec-14 08:48, [hidden email] <mailto:[hidden email]> wrote:
>
>     > Given these roughly 3 distinct scenarios with respect to connection status:
>     >
>     > A: The connection is successfully secured. (HTTPS)
>     > B: No security was attempted. (HTTP)
>     > C: Securing the connection has failed. (Certificate validation failure)
>     >
>     > A few people have said that B and C are roughly identical from a
>     > security perspective and could be represented as the same state -- in
>     > both cases no security is provided. I would disagree here. In the case
>     > of the failed certificate verification, the client has attempted to
>     > secure the connection and that attempt has failed. In the case of HTTP,
>     > the client made no indication of a preference for security. While
>     > scenario B represents the *absence* of security, scenario C represents
>     > the *failure* of security, and is therefore more troublesome. While we
>     > want to raise the awareness of scenario B, we shouldn't promote it to
>     > the severity of scenario C. Doing so conflates two very different cases
>     > and failure modes; while both represent the absence of verifiable
>     > transport security, the latter indicates that the user's expressed
>     > expectation of security has not been met, while the former simply
>     > reflects the absence of any expectation of security.
>
>     I respectfully, but strongly, disagree :) If you want to separate the
>     states, I'd say that C is better than B. C has *some* security, B has
>     *none*. Consider a self-signed certificate, where the site owner chooses
>     to provide what little security he can, this is still much better than
>     plain old http. Or a certificate expired by one day, which is the same
>     certificate that the browser has seen on that site for the 2 years past,
>     this is still way better than B.
>
>     If a malicious actor can get write access to a page with status C, he
>     can immediately change the security level to status B anyway. Redirect
>     the page to http://official-looking.subdomain-facebook.com, and present
>     B, so displaying B as better doesn't help users much against attacks. If
>     a malicious actor does not have write access to a page with status C,
>     then status C is already better than status B. If the browser can detect
>     an active attack (like the login form having moved to http from https or
>     replacement of a good certificate by a bad one) then the browser should
>     of course warn against the attack, but that is a different scenario.
>
>     In most cases, users type 'facebook.com <http://facebook.com>', and
>     give no preference for
>     security. Any such preference is a server preference. The same holds for
>     clicking links, the user has no expectation of where he will be taken.
>     For bookmarks, or cases where the user explicitly types 'https://', the
>     user might have an expectation of security. If he does, and the security
>     level of the page indicates either B or C, he should immediately be
>     alerted anyway. If you think this indicates an explicit preference for
>     security, then the browser could warn similar to an active attack in
>     these cases.
>
>     But my main point against this is still that you need an entire
>     paragraph to explain the difference, to people who already know the
>     background. A user wants to know if he is secure or not, not if his
>     'facebook.com <http://facebook.com>' request was intercepted on the
>     way and replaced by a http
>     MiTM (status B, really bad), or if 'facebook.com
>     <http://facebook.com>' made a bug leaving you
>     exposed (status C, pretty bad). Most users wouldn't understand the
>     difference. I consider it arrogant trying to force users to understand
>     the difference, most users just want to go to facebook, not get a
>     lecture on internet safety. I consider it harmful to try to display the
>     difference, as the more states we have in the UI, the more users have to
>     learn, which means they will remember less, and the states become less
>     meaningful. Keep it simple, and keep to user expectations, not
>     implementation details.
>
>     As a consumer buying bread, you want to know if the bread is safe to eat
>     or not. Whether the farmer tried to control pesticide usage and failed,
>     or he didn't try to control it, makes little difference. Professional
>     health and safety inspectors (akin to browser and web developers) are
>     about the only ones who care.
>
>     > I've
>     > received many reports from operators large and small indicating
>     > visible
>     > losses of revenue due to the nearly-hidden warning Chrome currently
>     > displays for a SHA-1 cert with a long expiration.
>
>     Are you able to share more details on this?
>
>     --
>     Sigbjørn Vik
>     Opera Software
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]
> <mailto:[hidden email]>.


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

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

Anne van Kesteren
In reply to this post by Sigbjørn Vik
On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <[hidden email]> wrote:
> I respectfully, but strongly, disagree :) If you want to separate the
> states, I'd say that C is better than B. C has *some* security, B has
> *none*.

You would advocate not blocking on certificate failures and just hand
over credentials to network attackers? What would happen exactly when
you visit e.g. google.com from the airport (connected to something
with a shitty captive portal)?


--
https://annevankesteren.nl/
_______________________________________________
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

Stephen Gallagher
In reply to this post by Chris Palmer
As a web developer, I feel that this proposal is missing the point somewhat.

For the typical end-user browsing general purpose sites, the biggest risk is not interception of traffic, but vulnerabilities on the back-end, and HTTPS does absolutely nothing to address this.

Making a more prominent indication of site "security" risks mis-interpretation by end users that their data is in fact secure, which is not the case in reality - especially since most users won't differentiate between transport security and back-end security.

Additionally, many sites simply don't have the type of content or interaction that requires the added complexity of HTTPS, even if it's perceived as an easy upgrade in tech circles. An overly intrusive "non-secure" indicator could lead to end-user confusion in these cases.

After users realise that these sites are not in fact stealing their data, the effectiveness of the indicator as a valid tool is diminished, since it has already flagged a false positive in the eyes of the end user.

I believe these and other nuances should be carefully taken into account when considering this proposition.
_______________________________________________
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

gshollingsworth
In reply to this post by Chris Palmer
My comment will focus on the Non-secure (broken HTTPS, HTTP). There is a significant and extremely important security difference between broken HTTPS and HTTP. Assuming the webmaster and web developer properly chose HTTP, it is not intended to be secure but intended for everybody to see. Broken HTTPS is intended to be secure but is not, again same assumption of proper choice by webmaster and web developer. The message to the user should not be the same. Broken HTTPS deserves an alarming declaration of being insecure to warn the user. HTTP deserves  a more gentle reminder message that it is not intended to be secure. If the page content on a HTTP page includes password fields or other clearly identifiable sensitive content fields, then that deserves the same treatment as broken HTTPS.

Webmasters and web developers should be making the appropriate choices for HTTP and HTTPS. Not all web content needs to be served via HTTPS. Users will suffer from alert overload and begin to ignore the important alerts. The simple fact a site is HTTP does not deserve an alert, it depends on the content and context.

I did notice a few comments identifying possible issues when trying to serve include HTTP in an HTTPS page. That is insecure and should not be expected to work. Mixed HTTPS and HTTP has long been identified to users as a security issue and should continue to be.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

Sigbjørn Vik
In reply to this post by Anne van Kesteren
On 17-Dec-14 18:17, Anne van Kesteren wrote:
> On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <[hidden email]> wrote:
>> I respectfully, but strongly, disagree :) If you want to separate the
>> states, I'd say that C is better than B. C has *some* security, B has
>> *none*.
>
> You would advocate not blocking on certificate failures
> and just hand
> over credentials to network attackers?

My comment above is about the relative security of http versus
non-perfect https. In most cases, non-perfect https is better. In some
cases, they are equally bad.[*]

Another topic is how to deal with broken https. Browsers today present
the user with an interstitial designed to allow him to shoot himself in
the foot, after which they leak any cached secure data to the broken
site. I consider that leakage a bug.

> What would happen exactly when
> you visit e.g. google.com from the airport (connected to something
> with a shitty captive portal)?

Assuming interstitials were replaced with cache separation:

The browser would detect that this isn't the same secure google you
talked to yesterday, and not share any data you got from google
yesterday with the captive portal. Once you reconnect to the authentic
google, the browser would use the first set of data again.

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

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

chaals
In reply to this post by Anne van Kesteren


17.12.2014, 20:19, "Anne van Kesteren" <[hidden email]>:
> On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <[hidden email]> wrote:
>>  I respectfully, but strongly, disagree :) If you want to separate the
>>  states, I'd say that C is better than B. C has *some* security, B has
>>  *none*.
>
> You would advocate not blocking on certificate failures and just hand
> over credentials to network attackers? What would happen exactly when
> you visit e.g. google.com from the airport (connected to something
> with a shitty captive portal)?

This is a pretty interesting use case. When you connect at the airport, the typical first thing that happens is you get a warning saying that the site you want to connect to has the wrong certificate (you went to pogoda.yandex.ru but the certtificate is for airport.logins.aero, or 1.1.1.1).

If you are me, you wrestle with the interface until you find out how to connect anyway, and hope that it doesn't remember this for other places (and that I do).

so having handed over your credit card details to get 30 minutes of connection time, you're in a hurry (your plane will leave soon, and you still haven't told Mum you're hoping she will collect you when you land).

If you're visiting google.com, it's hard to see what the next interstitial does that is useful. To take the standard Coast example, if you went to myAe.ro every day for the last month, and their certificate expired yesterday but hasn't changed, I think the answer is pretty clear.

If it expired last month, and you've been using it for a year, there may be an issue. If it is brand new and registered to someone else, there might well be an issue even though the certificate itself looks good…

just some thinking out loud…

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
[hidden email] - - - Find more at http://yandex.com
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

ianG-2
In reply to this post by Anne van Kesteren
On 17/12/2014 17:17 pm, Anne van Kesteren wrote:
> On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <[hidden email]> wrote:
>> I respectfully, but strongly, disagree :) If you want to separate the
>> states, I'd say that C is better than B. C has *some* security, B has
>> *none*.
>
> You would advocate not blocking on certificate failures and just hand
> over credentials to network attackers? What would happen exactly when
> you visit e.g. google.com from the airport (connected to something
> with a shitty captive portal)?


There is a big issue with signalling, something that isn't defined in
the 'secure browsing protocol' and is interpreted differently by
different folks.

Take expired certificates.  "We all know" there is no difference between
the technical security available for a certificate at E-1 and E+1 where
E is expiry day.  Yet, the browser presents to the user that the
certificate is insecure.  It's not.  We know it's not.  But the
"commercial" prerogative kicks in and the protocol is instructed to
harass the user(s) and get a fee paid.  This is the CA's security not
the users' security.

So a clear benefit *to security of end-users* would be to accept expired
certificates if we actually know they were good before.  But
CAs/browsers will never accept that.  Oh well.



Then there is self-signed certs.  If you compare to HTTP, when my site
uses a self-signed cert, it is better in all ways, even in the presence
of MITMing.  But when you compare a self-signed cert to say
https://google then "we know" it is worse.

Which is it?  Better or worse?  It depends on your baseline.

To some extent it also depends on what we know.  Sigbjørn assumes we
know that google communicates with HTTPS and we should separate the
cached info out.  Which means the browser must become HTTPS aware.
Which is good except HTTP was supposed to be stateless once upon a time.

In the alternate, we don't know these things so we could simply assume
that self-signed certs are signalling a highly secure thing and are bad,
hence the "mozilla N-click interstitial torture screen" that forces the
user to do something really bad, and get taught by sysadms to do that.
The result of this is of course that users are taught to again ignore
warning signs, because it is mostly when google goes self-signed that we
care.  If we had known this was the interpretation from the beginning
(again, signalling) it would have been far better to ban self-signed
totally because they basically undermine the CA-cert model.  But we
didn't know that.

To make some progress, really the browser should become much more aware
so it can for example know that google is not self-signed, and make a
distinction.  There should be more of a wizard approach, where it knows
that this is the first time a site has been visited, and it remembers
that security arrangement.

Summary of all this is that it is very messy.  There are multiple layers
of meanings here.  When OP says there is A, B, C, D, I'd say sure, do
that but don't believe there is only A, B, C, D.  Or at least surface
your assumptions (my original question), and be prepared to see that
list get complicated.



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

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
On Wed, Dec 17, 2014 at 11:29 AM, ianG <[hidden email]> wrote:

> Take expired certificates.  "We all know" there is no difference between the
> technical security available for a certificate at E-1 and E+1 where E is
> expiry day.  Yet, the browser presents to the user that the certificate is
> insecure.  It's not.  We know it's not.  But the "commercial" prerogative
> kicks in and the protocol is instructed to harass the user(s) and get a fee
> paid.  This is the CA's security not the users' security.

If a site operator can't get operational details like certificate
expiration right, should users believe they can get more difficult
things right?

That said, we (Chrome) have experimented a bit with softer warnings in
case of "barely expired" certificates. It might happen (no promises).

> So a clear benefit *to security of end-users* would be to accept expired
> certificates if we actually know they were good before.  But CAs/browsers
> will never accept that.  Oh well.

We would if we could make it work, and maybe we can. Maybe we can't.

> Then there is self-signed certs.  If you compare to HTTP, when my site uses
> a self-signed cert, it is better in all ways, even in the presence of
> MITMing.  But when you compare a self-signed cert to say https://google then
> "we know" it is worse.
>
> Which is it?  Better or worse?  It depends on your baseline.

The way to make self-signed certificates "safe" (as in: safe enough to
make a representation to a real-world user trying to achieve a task)
is to pin the keys, and hard-fail on pinning validation failure. Now
you need a ceremony for recovery. Do you have a ceremony design that
would work for real-world users who have no idea what is going on? I
bet you don't.

Because we cannot effectively communicate all this nuance to
real-world users, and because the client has very limited "knowledge"
of what is "expected" at run-time, we (Chrome, and most other
browsers) have consistently chosen to quantize the definition of
security *up*. It does upset some people with certain ideologies, but
it results in a more clear message to most people.

> To make some progress, really the browser should become much more aware so
> it can for example know that google is not self-signed, and make a
> distinction.

Yes, that's key pinning. We are doing it and it works. But it's not a
slam-dunk for all operators.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
1234567 ... 12