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

Inline

On Dec 18, 2014 1:07 AM, <chaals@yandex-team.ru> wrote:
>
>
>
> 18.12.2014, 01:27, "softwaredevjirka@gmail.com" <
softwaredevjirka@gmail.com>:
>>
>> On Wednesday, December 17, 2014 7:44:59 PM UTC+1, cha...@yandex-team.ru
wrote:
>>>
>>> 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).
>>> --
>>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>
>>
>> 511 Network Authentication Required?
>>
>> There is http://tools.ietf.org/html/rfc6585#section-6 for that. Chromium
bug is https://code.google.com/p/chromium/issues/detail?id=114929 , Firefox
has their own as well. As far as I know this only works for HTTP
connections. There really is no reasonable way how the airport can step
into an HTTPS connection and demand authentication without causing a
certificate error.
>
>
> There is a certificate error. The point is that since it is expected
behaviour, I get trained to say "yeah, whatever" so I can pay for the
connection I need. Despite the fact that it is very difficult to be *sure*
that the error is not actually a real problem.
>
> I'd love to see a better situation relying on a proper standard.
>
> But in general I don't.
>

I'm not sure if it's terribly germane to the
HTTP-being-indicated-as-not-secure to rathole too much on the ways that
HTTPS can be messed with, but I will simply note that the Chrome Security
Enamel team are working on ways to better detect and manage this.

While we can wish for better standards, this is an area where standards
compliant devices take years to become even remotely ubiquitous. As such, a
heuristic based approach on the way the world is, at least with respective
to captive portals that actively try to disrupt and compromise users'
connections.

>>
>> There is experimantal https://tools.ietf.org/rfc/rfc2521.txt which
suggests an ICMP packet "Need Authorization", but as I said, it is
experimantal. Am I missing something?
>>
>> This gradual roll out of the UI hints that is being proposed now would
help shift attention to such problems. The problems won't be solved until
we get to a state we (actually, you ;) truly _need_ to be solving them.
>
>
> Sure. But this turns out to be a case where right now there is a problem,
and instead of *solving* it it seems that "the world" (or at least the
parts I see, which is quite a lot by geography) is instead finding a quick
workaround that gets them where they were going - at the cost of learning
to ignore a potentially serious problem.
>
> On the whole I think this discussion is valuable, and the proposal makes
sense. But I have concerns about whether we really understand the things
that are going to change and the implications, so use cases like this are
important to find and make sure we understand.
>
> cheers
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>

As noted elsewhere, we aren't trying to boil the ocean, and though I
certainly accept the concerns are valid (and, as mentioned above, are
already being independently worked on), I think we should be careful how
much we fixate on these issues versus considering the broader philosophical
issues this proposal is bringing forward.

There are certainly awful things in the world of HTTPS, on a variety of
fronts. And yet, despite those warts, we would be misleading ourselves and
others to think that insecure transports such as HTTP - ones actively
disrupted for commercial gain, "value" adding, or malicious havoc and ones
that are passively monitored on widespread, pervasive scale  - represent
the desirable state of where we want to be or go.

I think the end goal is more robust - we want a world where users are not
only safe by default, but they expect that, and can understand what makes
them unsafe. Though some of these may be outside our ken as UAs - for
example, we have limited ability to know you're running a three year old
version of phpBB that is owned harder than Sony Pictures and has more
remote exploits than msasn1.dll - there are things we do know and should
communicate. One of them is that the assumption many users have - that
their messages are shared only between them and the server - is not true
unless the server operator is conscientious.