Re: Proposal: Prefer secure origins for powerful new web platform features

I don't having SSL-only features is good. To get an SSL certificate you
need to pay.. we are essentially forcing developers to pay money to some
dubious organization (every year!) just so that they can use some web
features. Note this isn't the case for DNS nor even an IP (since you can do
it in a university, for example without paying anyone, or in an intranet,
or at home, etc). It's not really a great idea.

It might also be worth noting that for some use-cases and setups, SSL
doesn't add any security benefits. I see there is "localhost" and 127/8 to
try and address this concern, but this will never be a complete list, and
will just break sites for users, annoy developers, and introduce dangerous
practices.

At some point will buy and publicize a key for a certificate with CN=*.
localnetwork.com and then route 10-0-0-1.localnetwork.com to 10.0.0.1 just
so that people bypass this requirement.

I get the goal is to make mass surveillance harder and protect users
against sites that don't care about security, but this doesn't seem to be
the right way.

On Wed, Aug 20, 2014 at 9:43 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Wed, Aug 20, 2014 at 8:40 AM, Jim Manico <jim.manico@owasp.org> wrote:
>
>> HTTPS has made giant strides in just the last six months. Ephemeral
>> cipher suites, pinning on the rise, etc. Historical attacks like BEAST and
>> CRIME against TLS are significant, but rarely have these bugs forces the
>> developer to get involved. They are configuration and infrastructure issues.
>>
>> I think it behooves standard bodies to try to integrate and require
>> security by default, as much as possible.
>>
>> In my world as an application security professional, I have not had to
>> convince a team to use HTTPS ever, because outside of a few very
>> specialized cases like Netflix, there is no way to achieve even a remotely
>> reasonable web security posture without it. Forgive my visceral reaction
>> here. I am just a bit shocked to see HTTPS-by-default argued against.
>>
>
> ​Just to be clear, I'm not arguing against use of HTTPS. I'm arguing
> against (non-judicious use of) the tactic withholding web features from
> HTTP sites as a way to encourage HTTPS use. I think it has to be clear that
> the use of HTTPS is truly necessary *as a consequence of properties of the
> new feature*. Otherwise it can be seen like the withheld feature was just
> in the wrong place at the wrong time.
>
>
>>
>> Netflix is a very special case, and I'm surprised that your content
>> partners let you stream plaintext!
>>
>
> ​They don't. The content is encrypted before it is placed on the CDN
> servers. But then that encrypted content is served over HTTP. We do use per
> session encrypted URLs, but that's a roadblock ​- you can still fingerprint
> the file. We obviously use HTTPS for user account management etc. but for
> streaming the site has to be HTTP because the content is.
>
> Other video service providers take a similar approach - ~half of all (US,
> peak) internet traffic is not a "very special case".
>
>
>>
>> To your point, I remember the XForms to Webforms debate and of course
>> XForms lost. XForms was so complex to use even if it was prepped to fight
>> XSS better than Webforms. But XForms lost for a reason - complexity. I do
>> acknowledge that if we make security overly complex or expensive many devs
>> will skip it.
>>
>
> ​Yes, and there could be much simpler ways of authenticating flat files
> downloaded over HTTP. For example having a secure origin vouch for them
> with some form of signature over the resource. I'm not proposing that as a
> solution, not least because it does not address ​privacy, just pointing out
> that there may be other options that could be looked at.
>
> ...Mark
>
>
>
>>
>> Cheers,
>>
>> --
>> Jim Manico
>> @Manicode
>> (808) 652-3805
>>
>> On Aug 20, 2014, at 10:17 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>> Well, there is the world as it is today and the world as we would like it
>> to be. The question is how to get there from here.
>>
>> I'm not saying sites should not address user security and privacy, but
>> only that making HTTPS a price-of-admission to parts of the web platform
>> may not be the best tactic to get us there. At least it should be used very
>> judiciously. In addition to the points below, the admission price needs to
>> be proportionate. Considering my own industry (video streaming), which
>> might represent 50%+ of US peak internet traffic, migrating that traffic to
>> a secure transport would be a huge win. But the cost at that scale is
>> pretty high in the short term (in the long term, by which I mean one
>> hardware refresh cycle for serving infrastructure once a migration decision
>> is made, the incremental cost is much lower). There is also work to
>> mitigate UX impacts that stem from longer connection setup times and
>> increased operational complexity. And then you have to convince people that
>> HTTPS will really get them the security that they want - non-trivial with
>> things like [1][2] popping up all the time.
>>
>> As to "enforce, by standard, HTTPS everywhere", I see that this was in
>> part in jest, but still, simply expecting people to invest large sums of
>> money just because you declare they should by fiat is also not a great
>> strategy for success.
>>
>> ...Mark
>>
>> [1]
>> https://www.blackhat.com/us-14/briefings.html#the-beast-wins-again-why-tls-keeps-failing-to-protect-http
>> [2] http://antoine.delignat-lavaud.fr/doc/oakland14_slides.pdf
>>
>> PS: disabled-by-default, with a settings switch to enable it, is in
>> practice equivalent to just disabled from a web developer's point of view.
>> The drop-off if you had to ask customers to change browser settings would
>> be prohibitive.
>>
>>
>> On Tue, Aug 19, 2014 at 9:04 PM, Jim Manico <jim.manico@owasp.org> wrote:
>>
>>> The thought that people caring about secure web applications in 2014 and
>>> NOT using HTTPS is something I'm struggling with. HTTPS is one of the most
>>> fundamental aspects to web security that requiring it for certain
>>> security-centric standards seems wise and prudent.
>>>
>>> If a website is NOT using HTTPS today then any remote hope for a secure
>>> web app is lost.
>>>
>>> How about we deprecate all of HTTP and enforce, by standard, HTTPS
>>> everywhere? ;)
>>>
>>> PS: The proposal states HTTPS by default implying it can be removed;
>>> this kind of "default" security in standards is key...
>>>
>>> Aloha,
>>> --
>>> Jim Manico
>>> @Manicode
>>> (808) 652-3805
>>>
>>> On Aug 19, 2014, at 5:24 PM, Mark Watson <watsonm@netflix.com> wrote:
>>>
>>> Chris, all,
>>>
>>> I think we should be highly selective about applying any blanket prohibition on access to features from http sites.
>>>
>>>
>>> It is of course quite appropriate for UAs to require user consent, provide warnings etc., including differentiating between use of a feature by a secure origin and a non-secure one, as they see fit. However, the danger of prohibiting things is that web developers may feel a new feature is being "held hostage" in support of an unrelated, albeit noble, goal of encouraging https use.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Developers need to be convinced that https makes business sense for them because of the user privacy and security benefits, and be given time to migrate their services. It should not be, instead, a price-of-admission for some new feature. Indeed, there is a danger that people do the minimum necessary to get the new feature, rather than properly considering the security aspects. That's not a good thing if you want to actually achieve the security benefits in practice.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ...Mark
>>>
>>>
>>>
>>> On Fri, Jun 27, 2014 at 3:55 PM, Chris Palmer <palmer@google.com <palmer@google.com?Subject=Re%3A%20Proposal%3A%20Prefer%20secure%20origins%20for%20powerful%20new%20web%20platform%20features&In-Reply-To=%3CCALx_OUBdUKR6Ko%3DBZEhQtdFbpdjEY-76h0-P-DbqLCyVnh3nVQ%40mail.gmail.com%3E&References=%3CCALx_OUBdUKR6Ko%3DBZEhQtdFbpdjEY-76h0-P-DbqLCyVnh3nVQ%40mail.gmail.com%3E>> wrote:
>>> > Hi everyone,
>>> >
>>> > Apologies in advance to those of you who will get this more than once,
>>> > due to the cross-posting. I wanted to get this to a wide audience, to
>>> > gather feedback and have a discussion involving as many interested
>>> > parties as possible (browser vendors, web developers, security
>>> > engineers, privacy advocates, et al.).
>>> >
>>> > * Proposal
>>> >
>>> > The Chrome Security team and I propose that, for new and particularly
>>> > powerful web platform features, browser vendors tend to prefer to make
>>> > the the feature available only to secure origins by default.
>>> >
>>> > * Definitions
>>> >
>>> > "Particularly powerful" would mean things like: features that handle
>>> > personally-identifiable information, features that handle high-value
>>> > information like credentials or payment instruments, features that
>>> > provide the origin with control over the UA's trustworthy/native UI,
>>> > access to sensors on the user's device, or generally any feature that
>>> > we would provide a user-settable permission or privilege to. Please
>>> > discuss!
>>> >
>>> > "Particularly powerful" would NOT mean things like: new rendering and
>>> > layout features, CSS selectors, innocuous JavaScript APIs like
>>> > showModalDialog, or the like. I expect that the majority of new work
>>> > in HTML5 fits in this category. Please discuss!
>>> >
>>> > "Secure origins" are origins that match at least one of the following
>>> > (scheme, host, port) patterns:
>>> >
>>> >     * (https, *, *)
>>> >     * (wss, *, *)
>>> >     * (*, localhost, *)
>>> >     * (*, 127/8, *)
>>> >     * (*, ::1/128, *)
>>> >     * (file, *, —)
>>> >     * (chrome-extension, *, —)
>>> >
>>> > This list may be incomplete, and may need to be changed. Please discuss!
>>> >
>>> > A bug to define “secure transport” in Blink/Chromium:
>>> > https://code.google.com/p/chromium/issues/detail?id=362214
>>> >
>>> > * For Example
>>> >
>>> > For example, Chrome is going to make Service Workers available only to
>>> > secure origins, because it provides the origin with a new, higher
>>> > degree of control over a user's interactions with the origin over an
>>> > extended period of time, and because it gives the origin some control
>>> > over the user's device as a background task.
>>> >
>>> > Consider the damage that could occur if a user downloaded a service
>>> > worker script that had been tampered with because they got it over a
>>> > MITM'd or spoofed cafe wifi connection. What should have been a nice
>>> > offline document editor could be turned into a long-lived spambot, or
>>> > maybe even a surveillance bot. If the script can only run when
>>> > delivered via authenticated, integrity-protected transport like HTTPS,
>>> > that particular risk is significantly mitigated.
>>> >
>>> > * Background
>>> >
>>> > Legacy platforms/operating systems have a 1-part principal: the user.
>>> > When a user logs in, they run programs that run with the full
>>> > privilege of the user: all of a user’s programs can do anything the
>>> > user can do on all their data and with all their resources. This has
>>> > become a source of trouble since the rise of mobile code from many
>>> > different origins. It has become less and less acceptable for a user’s
>>> > (e.g.) word processor to (e.g.) read the user’s private SSH keys.
>>> >
>>> > Modern platforms have a 2-part security principal: the user, and the
>>> > origin of the code. Examples of such modern platforms include (to
>>> > varying degrees) the web, Android, and iOS. In these systems, code
>>> > from one origin has (or, should have) access only to the resources it
>>> > creates and which are explicitly given to it.
>>> >
>>> > For example, the Gmail app on Android has access only to the user’s
>>> > Gmail and the system capabilities necessary to read and write that
>>> > email. Without an explicit grant, it does not have access to resources
>>> > that other apps (e.g. Twitter) create. It also does not have access to
>>> > system capabilities unrelated to email. Nor does it have access to the
>>> > email of another user on the same computer.
>>> >
>>> > In systems with 2-part principals, it is crucial to strongly
>>> > authenticate both parts of the principal, not just one part.
>>> > (Otherwise, the system essentially degrades into a 1-part principal
>>> > system.) This is why, for example, both Android and iOS require that
>>> > every vendor (i.e. origin) cryptographically sign its code. That way,
>>> > when a user chooses to install Twitter and to give Twitter powerful
>>> > permissions (such as access to the device’s camera), they can be sure
>>> > that they are granting such capability only to the Twitter code, and
>>> > not to just any code.
>>> >
>>> > By contrast, the web has historically made origin authentication
>>> > optional. On the web, origins are defined as having 3 parts: (scheme,
>>> > host, port), e.g. (HTTP, example.com, 80) or (HTTPS, mail.google.com,
>>> > 443). Many origins use unauthenticated schemes like HTTP, WS, or even
>>> > FTP.
>>> >
>>> > Granting permissions to unauthenticated origins is, in the presence of
>>> > a network attacker, equivalent to granting the permissions to any
>>> > origin. The state of the internet is such that we must indeed assume
>>> > that a network attacker is present.
>>> >
>>> > * Thank You For Reading This Far!
>>> >
>>> > We welcome discussion, critique, and cool new features!
>>> >
>>>
>>>
>>
>