See also: IRC log
<bhill2> opening webex shortly
<wseltzer> scribenick: wseltzer
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> 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
i/minor editorial nits
<freddyb> :)
<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-06-29-webappsec-minutes.html
<bhill2> minutes approved by unanimous consent
<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
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
<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
<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]
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
<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
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) WARNING: Bad i/// command: i/minor editorial nits Succeeded: i/minor editorial nits/Topic: SRI Succeeded: s/termm/term/ Succeeded: s/sw/service workers/G Succeeded: i/unsafe-inline/scribenick: bhill2 Succeeded: i/reconvene/scribenick: wseltzer Succeeded: i/attackers will not set it/scribenick: bhill2 Found ScribeNick: wseltzer Found ScribeNick: bhill2 Found ScribeNick: bhill2 Found ScribeNick: wseltzer Inferring Scribes: wseltzer, bhill2 Scribes: wseltzer, bhill2 ScribeNicks: wseltzer, bhill2 Present: wseltzer bhill2 dveditz francois freddyb JonathanKingston AlexRussell mkwst jose Axel Agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md Got date from IRC log name: 13 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/13-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]