Re: Proposal: Showing the padlock icon on all secure origins

Localhost is not necessarily a secure origin -

Examples:

1. A local user could set up port forwarding. You think you're
connecting to your own web server but are really being MITMed.

2. IPv6 attack:
http://googleprojectzero.blogspot.com/2015/01/finding-and-exploiting-ntpd.html

"Bypassing the first one is actually not that hard if you’re on the
same network. As we all know IP addresses can be spoofed. But can we
spoof the address of localhost? It turns out OS X and the Linux Kernel
behave similarly in this case. Any IP packet arriving on an external
interface and with the source IP 127.0.0.1 will be dropped
immediately. But if we use IPv6 instead we can actually spoof ::1 and
send control mode packets to the daemon (some Linux distributions have
firewall rules in place that protect against this, e.g. Red Hat).
Thus, if we are on the same local network, we can send spoofed packets
to the link-local address of the target and bypass the IP
restrictions."

3. On UNIX systems, not all systems handle sockets read permissions
the same way. Other users could intercept your traffic if they have
read permission.

4. The host name 'localhost' might not resolve to 127.0.0.1....

related:

Localhost isn't necessarily safe from remote attacks if there's an
HTTP proxy running on the host as well, the proxy might respond to
requests for localhost by connecting to its own localhost. (this is a
fun trick for pentesting proxy servers, too - attack the localhost
admin interface through the proxy)

(I work for Mozilla, but not on the browser, you're welcome to make a
feature request on https://bugzilla.mozilla.org/)





On Sun, Nov 29, 2015 at 9:07 PM, Chaals McCathie Nevile
<chaals@yandex-team.ru> wrote:
> On Tue, 24 Nov 2015 02:35:28 +1000, Joel Weinberger <jww@chromium.org>
> wrote:
>
>> I think this is a per user-agent decision as most (all?) iconography is.
>
>
> Sort of...
>
>> It is not mandated that a 'lock' icon is needed at all; that's just a
>> convention that user agents have converged on. It's also notable that some
>> major browsers use the lock icon for additional purposes (see the
>> UC Browser, for example, which if I'm not mistaken, also uses lock
>> iconography for HTTP pages that have been scanned for malware).
>
>
> There was some very explicit work around EV certificates and how browsers
> represent them. Because if there is inconsistent iconography users can be
> misled...
>
> ...hence the discussion about changing the "broken security" icon usage from
> mixed TLS / trasnmission in the clear to apply to pure transmission in the
> clear as well.
>
>> That having been said, you might consider filing feature requests with
>> various browser vendors, as I think your point about localhost has merit
>> in our particular context, and I'm guessing the other major user agents
>> may feel similarly.
>
>
> +1
>
> cheers
>
>
>> --Joel
>>
>> On Mon, Nov 23, 2015 at 5:24 AM timeless <timeless@gmail.com> wrote:
>>
>>> I'm not sure localhost should be seen as secure. Historically, people
>>> downloaded untrusted content and then were tricked into loading it.
>>>
>>> Also, in the really olden days, people shared computers so many different
>>> users would have writeable storage on a single localhost. In a university
>>> setting, a couple would be pranksters -- untrustworthy. Their files could
>>> be accessed via localhost, but doing so could be manifestly bad for you
>>> and
>>> your data.
>>>
>>> If you want to provision a CA and add it to your list and then issue
>>> yourself a certificate for an alternative name for your host (I.e. other
>>> than localhost), then I don't see a problem with you doing that.
>>> On Nov 22, 2015 3:22 PM, "Simon Brown" <mail@simonandrewbrown.co.uk>
>>> wrote:
>>>
>>>> Currently most browsers only show the padlock icon on HTTPS sites, even
>>>> though there are other secure origins, such as localhost. I propose that
>>>> browsers start showing the padlock icon for other secure origins,
>>>> providing
>>>> there isn’t a security problem, such as an invalid certificate on a HTTP
>>>> site or content from an insecure origin. This would:
>>>>
>>>> 1. Make it easier for users to ascertain whether an origin is secure.
>>>> Currently secure localhost and insecure HTTP have the same indicators.
>>>> 2. Increase the perceived normality of the padlock signal, making
>>>> insecure origins stand out more.
>>>> 3. Make it more obvious to developers when they are able to use features
>>>> that are restricted to secure origins.
>>>>
>>>> https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features
>>>> 4. Make the transition to marking insecure origins as non-secure more
>>>> straightforward.
>>>>
>>>> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
>>>>
>>>
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>

Received on Tuesday, 1 December 2015 09:20:09 UTC