WebAppSec Berlin F2F, Day 1, 13-July-2015

<bhill2> opening webex shortly

<wseltzer> scribenick: wseltzer

Introductions

bhill2: Genesis of this meeting, conversations about "what would it take to get all the Web commiunication secure"
... what are the edge cases, how do optimistic/opportunistic upgrades work
... upgrades, mixed content and interaction with same-origin
... tomorrow's agenda focused on that conversation, with TAG
... what do we want to build here? sponsor in IETF? work with TAG?

<scribe> agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md

bhill2: SRI is about ready to head to CR, so we could talk about that too
... agenda has room for other discussion

<bhill2> wseltzer: leads w3c's technology and society domain

<bhill2> ... on w3c side responsible for trying to figure out what it means to keep the web secure and private while enabling all the things we want to do on the web

<bhill2> rbarnes: Mozillan, security agitator, trying to figure out how to deprecate insecure http

<bhill2> dveditz: Mozillan, also co-chair of WG

<bhill2> freddyb: Mozillan, co-editor of SRI

<rbarnes> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

<bhill2> francois: Mozillan, co-editor of SRI and implementor of it in Firefox, in security engineering group

<bhill2> jonathankingston: cyber.me a startup doing security training for developers, want to improve the security for the web

<bhill2> axel: observer Deutsche Telecom, research group, some issues with formally joining given legal structure of DT at the moment

axel: interested in secure elements, NFC

<JonathanKingston> Cyber-AMI

<bhill2> ... interested in web crypto, support for native applications, how to integrate native features accessing secure elements into the web platform

<bhill2> dveditz: browser vendors have gotten gun shy about launching binary blobs after the disasters that plugins and activeX have been, would be interested in better defining the security model

<bhill2> axel: for some years, url schemes worked, but may be multiple targets

<bhill2> dveditz: and may not be a communication path back

<bhill2> axel: and chrome started showing mixed content warnings when launching these schemes

<bhill2> ... also was a founding member of InfoCard foundation, board member of OpenID foundation and implemented Firefox plugins to enable these technologies

bhill2: I think FIDO Alliance is planning a member submission once they get through their IP process
... any discussion on SRI?

freddyb: Most of the discussion is minor editorial nits
... no formal objections
... clearer reference to CORS
... security considerations

dveditz: 15 open issues, How do those look?

francois: filter on milestones

freddyb: biggest issue for v2 is probably more subresources

francois: also caching

rbarnes: e.g. say "this defines no new caching behavior"

freddyb: for v2, cross-origin caching by hash, if we can do it smartly

<bhill2> freddyb: would be interesting to use SRI for import directive in CSS, but needs re-specification in terms of CSS, and may be easier to wait for CSS to redefine how that works in terms of fetch

<bhill2> ... in terms of nested content, for something like an iframe, just check the content and if that content wants to put integrity on its own resources, it can do that

<bhill2> ... but transitive descent is the job of each window to handle it's own resources

<bhill2> dveditz: why not images?

<bhill2> freddyb: wasn't considered in the threat model as compared to code execution possible with script and css

<bhill2> dveditz: image substitution can be damaging, e.g. a presidential campaign linking to an off-site image from a non-supporter

<bhill2> dveditz: any technical difficulties in adding this to arbitrary elements?

<bhill2> freddyb: we don't think so

<bhill2> francois: images easy, iframes harder

<bhill2> freddyb: mostly wanted to move fast, get code review, ship things

<bhill2> dveditz: objects & embeds, but those are tricky because we don't always do the loads for those

bhill2: what about HTML imports?

<bhill2> freddyb: can be tricky because of blocking

<bhill2> alexr: blocks paint, not parse

francois: probably landing in firefox this week

bhill2: does the test suite have full coverage?

francois: on my to-do list to review

bhill2: my impression is that it's in good shape

<bhill2> https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6263699-subresource-integrity

<bhill2> JonathanKingston: working on SRI support as a broccoli plugin for Ember.js

<bhill2> ... use it out of the box without any scary features

<bhill2> ... 3 examples: same origin (relative path), external, third option to specify the url is same as origin but w/absolute path

JonathanKingston: I might be interested in working on an IG note on same-origin policy

<bhill2> devditz: what is reasoning behind fail-open for non-CORS?

<bhill2> ... if developer has added an integrity attribute, aren't they asking for failure behavior

<bhill2> francois: pretty much only getting the hash wrong will block, everything else syntax-wise fails open to give us flexibility for future extensibility

<bhill2> dveditz: what is benefit of failing open if developer forgets to specify CORS mode

<bhill2> francois: we can always fail closed in the future, but don't want to close now because we may find a way in the future to avoid the CORS requirement

<bhill2> dveditz: actually can't move to fail closed in the future

<bhill2> ... if we find a way to avoid CORS requirement because we do something else, we can make that case succeed w/o CORS mode

<bhill2> ... if we integrated into another place in the fetch, we could maybe do something else

<bhill2> francois: also, old browsers would fail closed, even if a new mechanism to enable it existed

<bhill2> bhill2: are there any plausible scenarios in which we could avoid CORS fetch?

<bhill2> francois: not really

<francois> https://github.com/w3c/webappsec/issues/317 is where most of the discussion took place

bhill2: feel pretty comfortable saying we can't integrity-check an opaque response without leakage

<slightlyoff> where's the thread on github?

<slightlyoff> thanks

<freddyb> https://github.com/w3c/webappsec/issues/317#issuecomment-110844444

<freddyb> this comment

<bhill2> JonathanKingston: that everyone in this room needs some clarification is a good example of why this will be confusing and it should be changed

SRI

i/minor editorial nits

<freddyb> :)

Minutes approval

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-06-29-webappsec-minutes.html

<bhill2> minutes approved by unanimous consent

CfC on non-normative changes to CORS REC

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0094.html

<bhill2> unanimous consent to publish an edited recommendation as indicated

bhill: all of these are non-normative changes

Removing unsafe-redirect from CSP2

bhill2: mkwst's patch on potential leakage from different redirect depending on login state

dveditz: or where leaked path could reveal userid or security token
... blocked paths; issue that it's still cross-origin leakage

slightlyoff: problem in service workers too
... if you have an open redirect on your origin ... auto-xss
... how much info is too much? the fact of a redirect?
... it would be great if this group could make statements about what info about the presence of a redirect can be exposed
... e.g. the fact of a redirect

rbarnes: any utility to scoping to cross-origin redirects?

<bhill2> fyi: this is the patch being discussed: https://github.com/w3c/webappsec/commit/7456cb77e504fa70991b3cc54c852e62ebc7a2cc

dveditz: if it's same origin, no problem reaching into the iframe

JonathanKingston: you can turn off redirects in fetch

slightlyoff: yes: follow, error, or manual

bhill2: nobody implemented unsafe-redirect, so ripping it out
... but adding a CSP-active

<inserted> scribenick: bhill2

dveditz: 'unsafe-inline' will break existing users of CSP and attackers will not set it
... so we should fix reports to not report the violation, potentially even the origin

bhill2: but the original homakov exploit relied on onerror handling, whether resource loaded at all with CSP, not on reporting

slightlylate: response object could have 1 bit set indicating if a redirect was traversed

freddyb: just cross-origin or also same-origin?

rbarnes: what is the need for this?

slightlylate: large scale application composition or lack of global knowledge, may not know about flow of authority

dveditz: do SWs get any headers back?

slightlylate: for same-origin and CORS we can see almost everything, otherwise no

dveditz: with no-cache type directives, do we want SWs to cache?

slightlylate: we explicitly make this the programmer's program, and cache opaque responses opaquely
... that's the next question I wanted to get to - if redirects are OK, what else is?

dveditz: caching, vary?

rbarnes: can we handle this better declaratively? initiator can declare if he expects it to be cross-origin redirected instead of asking

<rbarnes> redirect-scope="same-origin"

<wseltzer> bhill2: you could already force that information leak in CSP

by setting a CSP policy for a specific fetch type with a policy that only allows one domain, you could detect by the CSP-generated error state whether a cross-origin redirect occurred anyway

<rbarnes> unsafe-allow-redirects=t.co

so if that information is already available in the platform, adding a bit to the API of a response to make it explicitly available is not introducing anything new

it's just syntactic sugar for an existing infoleak

bhill2: if surfacing this formally generates strong objections and good security reasons not to do it, should we change CSP?
... to allow the initial resource the implicit authority to delegate

dveditz: that would be a horrible hole in CSP in my opinion, really don't want to do that

CSP Level 2 and inline styles

<inserted> scribenick: bhill2

JonathanKingston: style-src without 'unsafe-inline' forbids setting of freeform text in style attribute but not setting individual attributes that affect the computed style

dveditz: this is by design, because individual properties have validators and prevent free-form setting of styling that might be more powerful
... maybe we should add a better explanation to the spec
... it was explained in long threads, but that may have not translated to our final text

JonathanKingston: this is broken everywhere, I've been advocating preventing setting of style in Ember and using individual attributes instead
... but can't point to spec text that says why one is OK and the other is not

raised https://github.com/w3c/webappsec/issues/423

<JonathanKingston> https://github.com/hillbrad/web-platform-tests/blob/7845ee1a94700b95aa9ef636aae66adae5e27efe/content-security-policy/blink-contrib/inline-style-allowed-while-cloning-objects.sub.html

<freddyb> https://bugzilla.mozilla.org/show_bug.cgi?id=883975

<freddyb> https://bugzilla.mozilla.org/show_bug.cgi?id=855326

<mkwst> I am, in theory, here.

<mkwst> Just need to find the entrance. :)

<mkwst> Found it! Probably! Waiting for an elevator.

<inserted> scribenick: wseltzer

[reconvene]

Mixed Content

mkwst: Mixed content is implmented in every major browser
... substantial test suite
... some failures around forms
... CfC on-list
... one thread on service workers
... operations on an opaque blob
... fetch from within a service worker
... Brian saying: with new stuff, we shouldn't support insecure practices
... Not sure we need to anservice workerser it all in the initial draft

dveditz: also some concerns about CSP and service workers

mkwst: service workers act as a network proxy
... page should have the ability to govern what loads on the page, not what's on the network

slightlyoff: the governing policy for the service worker needs to be sent with the service worker

dveditz: the CSP of the service workers may be different from any of the multiple pages that use the service workers

mkwst: a constructed response is similar to a blob URL
... we should enable pages to set policy that disallows constructed responses

slightlyoff: where will that policy come from?

mkwst: from the page or the service workers
... should the page have the ability to control the "washing" of requests / redirects through service workerss?

dveditz: if service workers is serving multiple pages, it may want to obey CSPs, but not know what they are?
... may be a good thing to hook on responses

bhill2: is there a security boundary that we could be enforcing?

mkwst: Mixed Content is asking: should the service workers be bound by the same policy as the page?
... seems like a different question from security policy
... currently, no way for service workerss to make insecure requests
... no problem if we don't change that.
... Other question, whether deprecated TLS needs to be in Mix
... Just rely on fetch.
... I suggest that we push it to PR

bhill2: Mixed content checks fire before HSTS upgrades
... 2 sides: mix first, since not all browsers support HSTS
... but now IE has HSTS
... and it may be more pain than benefit
... so now more inclined to make things easy for devs to start transitioning

francois: also consider instead of blocking, opportunistic upgrades
... keep the missing padlock, but try to improve

mkwst: relates to tanvi's question about upgrade-insecure and strict mode
... the different forbes websites at http and https

slightlyoff: I asked the crawl incidence: 99.7% conincidence between http https
... fuzzy, mostly based on text

mkwst: Adam Langley opposes changes the ordering of Mix - HSTS
... we should talk more with the network folks

dveditz: another possible level, in strict-mode, do before; in non-strict mode, do HSTS first

mkwst: strict mode also disables user decisions
... by blocking the request
... intent is not to show the user option to turn on the insecure

bhill2: some of the auto-upgrade may be suitable for level 2
... we'll have more options, e.g. automatic discovery

https://w3c.github.io/webappsec/specs/mixedcontent/#further-action

mkwst: how you choose not to load insecure resources is up to you

francois: what about potentially secure?

mkwst: language might need improvements between secure context / mixed content
... Mix uses secure to mean HTTPS

[discussion of localhost]

mkwst: I'm loath to carve out exception
... I don't like "install app locally and then need to talk to it from the open web" because of security considerations
... versus let devs test their apps on localhost before installing on HTTPS servers
... different treatment for RFC 1918 hosts @@
... loading RFC 1918 from the web

rbarnes: origin resolving to 1918 address, or the address itself?

mkwst: ideally, both
... would have liked to block those

<mkwst> https://www.chromestatus.com/metrics/feature/popularity

mkwst: but more widely used than I'd like

<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/530

<mkwst> ~0.6% of page views.

rbarnes: apps getting certs for local, then had to have the certs revoked
... so it's a good thing to block

mkwst: it's reasonable to want to have a single definition
... threat model of mix is attacker who can see what you're doing or interfere
... not the local host

bhill2: you could also say Mix is a contract of tranquility of the secure state
... violated by local resources even if no network attacker
... 3 issues
... block local network resources? - more discussion
... deprecated TLS. was listed at-risk
... we should remove the refs that now go to undef term
... and the service worker question

mkwst: EME issue
... get back an opaque blob to pass to elsewhere

<rbarnes> perhaps we just need EMEHR

mkwst: we block XHR and fetch, because they leak information
... if we could guarantee that it was just data being used, not executed, then we could do different things, possibly
... I'm not entirely convinced

rbarnes: have the page declare that the data will be used in only one way
... e.g. declare things browser accessible only

bhill2: I don't want to encourage people to put more edge cases into HTTP

mkwst: Agree. I've heard more requests for the localhost thing than anything else.
... editorial change on deprecation
... not going to do anything with localhost or fetch
... so group is more or less happy to push this out and come back if there are compelling use cases.

axel: what's your solution to web page talking to its associated location?

mkwst: there's not a current solution
... we need a better one.
... I'd suggest it needs at least 2 components: allow app to opt-in to communication
... and the user has to allow access to local net.
... and probably other things need to happen.

axel: I have an app I want to have used by many websites
... earlier working blocked by mixed content

mkwst: apps installed locally have high privilege, and it's dangerous to expose that privilege to the open web
... I think I agree there are good use cases for talking to something local
... but simply exposing the interface to the web is a bad idea

slightlyoff: navigator connect. one of the hopes for service workers is to let apps talk
... navigator connect lets apps post-message
... lets a service workers register to provide services located at a URL
... the whole thing ends up in the origin security model
... a thin abstraction over RPC for the web
... hoping to use it as a bootstrap for launching APIs
... make it easier to experiment
... without leaving trails of old things
... navigator.connect IPC bridge with short-term windows
... more science, less guessing

mkwst: postmessage from secure to insecure happens on ~5% of pageviews
... and from insecure to secure on ~3%

JonathanKingston: u2f?

mkwst: currently in chrome, it's an extension
... I think it's unfortunate that we shipped in a way that requires extension

<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/419 <-- secure to insecure, https://www.chromestatus.com/metrics/feature/timeline/popularity/420 <-- insecure to secure.

<JonathanKingston> wseltzer: sorry missed that: https://fidoalliance.org/specifications/overview/

<rbarnes> theme for the w3c https call: https://en.wikipedia.org/wiki/Just_Do_It#/media/File:JUST_DO_IT._%28NIKE%29.gif

HTTPS for w3.org

<dveditz> wseltzer: the numbers would be the ones listed here: https://wiki.mozilla.org/WeeklyUpdates except a differernt conference number

<dveditz> conference 95201#

<dveditz> and the # key after

<dveditz> jose-cdbtr: any luck?

<dveditz> we don't hear you

<dveditz> after the 92 did you hear an invitation to enter the conf number?

<dveditz> I think you needed 92#

<dveditz> possible... we're checking

<dveditz> rebooting our system

<dveditz> jose-cdbtr: are you saying anything? we can't hear you

<dveditz> yes, we can hear you

https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0099.html

<dveditz> jose-cdbtr: we hear it too. don't know the cause

<bhill2> wseltzer: thanks to webappsec for pushing w3c to upgrade to https and providing technologies to help do so

<bhill2> ... constraints are that w3c site is a huge mass of hand-written pages with lots of absolute links to http

<bhill2> ... want to enable secure connections to as much as can be securely accessed w/o going back to hand-tweak all those links

jose-cdbtr: we have multiple servers for different services
... and previously used service workersitch-SSL to service workersitch requests from HTTPS to HTTP for resources we didn't offer in HTTPS
... proposing to stop making that service workersitch
... Lots of historic content that we can't update
... many pages written individually, by hand

<rbarnes> mod_rewrite?

bhill2: are there things that you're aware of that are still broken where the browser could help upgrade more smoothly?

jose-cdbtr: some infinite loops with HSTS and redirects

<bhill2> mkwst: have you filed a bug against the browser which had this behavior?

<bhill2> jose-cdbtr: not yet

<rbarnes> i mean, if your HSTS-enabled page redirects to http://, you're gonna have a bad time

<bhill2> bhill2: was the CSP reporting issue related to HTTPS upgrades or a different policy you were trying to set?

<bhill2> ... e.g. were theses reports from setting something like default-src: *, or were you trying to do another kind of policy?

<bhill2> ... sorry default-src https:

<bhill2> mkwst: sounds like current upgrade strategy is dependent on upgrade-insecure-requests

<bhill2> ... what will you do for browsers that don't support that

<bhill2> jose-cdbtr: we will support http for some resources that are public

mkwst: the header that is now HTTPS:1 will soon be renamed
... it will allow distinguishing between browsers that support upgrade-insecure and those that don't

<rbarnes> let this be a lesson to you all -- scheme-relative URIs!

<freddyb> rbarnes: but relative is weak. you never know what your context is :-P the lesson is clearly HTTPS links only

<rbarnes> freddyb: well, if they'd planned for this in the first place...

<rbarnes> sorry, s/http:/https:/g

<freddyb> rbarnes: is this because you want root?

jose-cdbtr: we don't want to break old tools that rely on http:
... what will we do with DTDs and namespaces

mkwst: what do you mean tools that don't support HTTPS?

jose-cdbtr: we asked the TAG for advice

<rbarnes> jose-cdbtr: this tool might be helpful for finding mixed content: https://github.com/bramus/mixed-content-scan

jose-cdbtr: please try the test searver, email systeam if you find errors

<rbarnes> francois, freddyb: i see that upgrade-non-secure-requests has landed in Firefox. do we send a header to announce support?

mkwst: you might split, upgrade to HTTPS first, then HSTS

<slightlyoff> +1 to what mkwst suggested

<freddyb> rbarnes: dunno, can't find the bug off hand

<dveditz> https://bugzilla.mozilla.org/show_bug.cgi?id=1139297

<JonathanKingston> Can I ask where the best place for bug reports on this platform is?

<rbarnes> freddyb: Cmd-F "header" indicates probably not

<jose-cdbtr> sysreq@w3.org

Secure Context

mkwst: Neither Yan nor I has done much
... lately

rbarnes; some editorial suggestions

mkwst: send a pull request

<dveditz> mkwst: ancient (still open) 2004 Mozilla bug to change our handling of data: urls https://bugzilla.mozilla.org/show_bug.cgi?id=255107

mkwst: do we need to guarantee that a context can't be abused, e.g Netflix shim on webcrypto
... walking the ancestor tree

rbarnes: assume we have a unitary concept of secure, then we're worried about communication from secure to insecure

bhill2: we don't have a no write-down policy on the web today
... we assume origins are authoritative

rbarnes: that suggests we can't solve mkwest's shim problem

bhill2: you could do a latch like COWL
... tomorrow, let's talk about our inconsistent notions of security
... tranquility vs information flow contracts

mkwst: push-notification proxy for third-party origins
... roost
... if we want secure context to have meaning, should make it non-trivial to circumvent
... if you're using message ports as a capability token...
... some people asking for isolation
... e.g., separate cookie jar, no communication with the open web

slightlyoff: I want storage isolation
... local storage, cookie jar, cache separated

mkwst: like double keying

slightlyoff: yes. chrome apps already do this
... allows everyone else to live without the ambient authority

dveditz: firefox OS apps have taken that approach
... double-keyed, no pollution
... now they're tacking the other way, because logins don't persist

mkwst: as a blanket mechanism, it seems problematic
... as opt-in, seems good
... isolation writ large; second, what's sufficiently secure context; might be no write-down
... you can't post-message to insecure contexts, perhaps

bhill2: how do we evolve to a web where everything is secure?
... where that trust is on servers and browsers

mkwst: don't talk to insecure stuff

rbarnes: a sufficiently determined server could always route through for insecurity

bhill2: you can't prevent delegation

dveditz: would it make sense to change postmessage?

mkwst: conceptually, don't post to insecure things seems like a reasonable thing for a website to opt-into
... is that necessary to get access to these APIs?

JonathanKingston: good for encouraging upgrade

mkwst: current spec walks the ancestor tree
... apparently does the wrong thing in th ecase of workers
... and nothing in the case of new windows
... do we care?

bhill2: let's discuss tomorrow
... we have lots of pieces at work here: isolation, information flow, COWL
... incline to simpler, coherent policy for the long run
... rather than more complex to motivate changew