IRC log of webappsec on 2015-07-13

Timestamps are in UTC.

08:04:32 [RRSAgent]
RRSAgent has joined #webappsec
08:04:32 [RRSAgent]
logging to http://www.w3.org/2015/07/13-webappsec-irc
08:04:42 [francois]
francois has joined #webappsec
08:04:50 [Zakim]
Zakim has joined #webappsec
08:05:13 [bhill2]
Meeting: WebAppSec Berlin F2F, Day 1, 13-July-2015
08:05:15 [freddyb]
freddyb has joined #webappsec
08:05:16 [bhill2]
Agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md
08:05:25 [bhill2]
Chairs: bhill2, dveditz
08:05:42 [JonathanKingston]
JonathanKingston has joined #webappsec
08:06:17 [bhill2]
opening webex shortly
08:06:21 [wseltzer_berlin]
present+ wseltzer
08:06:22 [rbarnes]
rbarnes has joined #webappsec
08:06:34 [bhill2]
present+ bhill2
08:06:47 [bhill2]
rrsagent, draft minutes
08:06:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html bhill2
08:06:51 [dveditz]
present+ dveditz
08:06:52 [bhill2]
rrsagent, make logs world
08:07:00 [francois]
present+ francois
08:07:11 [freddyb]
present+ freddyb
08:08:13 [JonathanKingston]
present+ JonathanKingston
08:08:31 [wseltzer]
scribenick: wseltzer
08:08:38 [wseltzer]
topic: Introductions
08:09:09 [wseltzer]
bhill2: Genesis of this meeting, conversations about "what would it take to get all the Web commiunication secure"
08:09:41 [wseltzer]
... what are the edge cases, how do optimistic/opportunistic upgrades work
08:09:58 [wseltzer]
... upgrades, mixed content and interaction with same-origin
08:10:10 [wseltzer]
... tomorrow's agenda focused on that conversation, with TAG
08:10:23 [wseltzer]
... what do we want to build here? sponsor in IETF? work with TAG?
08:10:41 [wseltzer]
agenda: https://github.com/w3c/webappsec/blob/master/admin/berlin-f2f-july-2015-agenda.md
08:11:01 [wseltzer]
bhill2: SRI is about ready to head to CR, so we could talk about that too
08:11:12 [wseltzer]
... agenda has room for other discussion
08:11:27 [bhill2]
wseltzer: leads w3c's technology and society domain
08:11:52 [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
08:12:15 [bhill2]
rbarnes: Mozillan, security agitator, trying to figure out how to deprecate insecure http
08:12:26 [bhill2]
dveditz: Mozillan, also co-chair of WG
08:12:50 [bhill2]
freddyb: Mozillan, co-editor of SRI
08:13:03 [rbarnes]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
08:13:12 [bhill2]
francois: Mozillan, co-editor of SRI and implementor of it in Firefox, in security engineering group
08:13:48 [bhill2]
jonathankingston: cyber.me a startup doing security training for developers, want to improve the security for the web
08:14:37 [bhill2]
axel: observer Deutsche Telecom, research group, some issues with formally joining given legal structure of DT at the moment
08:15:45 [wseltzer]
axel: interested in secure elements, NFC
08:15:54 [JonathanKingston]
Cyber-AMI
08:16:04 [bhill2]
... interested in web crypto, support for native applications, how to integrate native features accessing secure elements into the web platform
08:16:49 [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
08:17:09 [bhill2]
axel: for some years, url schemes worked, but may be multiple targets
08:17:26 [bhill2]
dveditz: and may not be a communication path back
08:17:40 [bhill2]
axel: and chrome started showing mixed content warnings when launching these schemes
08:20:11 [bhill2]
... also was a founding member of InfoCard foundation, board member of OpenID foundation and implemented Firefox plugins to enable these technologies
08:22:29 [wseltzer]
bhill2: I think FIDO Alliance is planning a member submission once they get through their IP process
08:23:27 [wseltzer]
... any discussion on SRI?
08:23:38 [wseltzer]
freddyb: Most of the discussion is minor editorial nits
08:23:45 [wseltzer]
... no formal objections
08:23:59 [wseltzer]
... clearer reference to CORS
08:24:05 [wseltzer]
... security considerations
08:24:14 [wseltzer]
dveditz: 15 open issues, How do those look?
08:24:31 [wseltzer]
francois: filter on milestones
08:25:16 [wseltzer]
freddyb: biggest issue for v2 is probably more subresources
08:25:24 [wseltzer]
francois: also caching
08:25:48 [wseltzer]
rbarnes: e.g. say "this defines no new caching behavior"
08:26:21 [wseltzer]
freddyb: for v2, cross-origin caching by hash, if we can do it smartly
08:27:52 [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
08:28:38 [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
08:29:11 [bhill2]
... but transitive descent is the job of each window to handle it's own resources
08:29:46 [bhill2]
dveditz: why not images?
08:30:30 [bhill2]
freddyb: wasn't considered in the threat model as compared to code execution possible with script and css
08:31:00 [bhill2]
dveditz: image substitution can be damaging, e.g. a presidential campaign linking to an off-site image from a non-supporter
08:31:14 [bhill2]
dveditz: any technical difficulties in adding this to arbitrary elements?
08:31:21 [bhill2]
freddyb: we don't think so
08:31:31 [bhill2]
francois: images easy, iframes harder
08:31:58 [bhill2]
freddyb: mostly wanted to move fast, get code review, ship things
08:32:36 [bhill2]
dveditz: objects & embeds, but those are tricky because we don't always do the loads for those
08:33:55 [wseltzer]
bhill2: what about HTML imports?
08:34:25 [bhill2]
freddyb: can be tricky because of blocking
08:34:31 [bhill2]
alexr: blocks paint, not parse
08:34:55 [bhill2]
present+ AlexRussell
08:36:29 [wseltzer]
francois: probably landing in firefox this week
08:36:45 [wseltzer]
bhill2: does the test suite have full coverage?
08:37:24 [wseltzer]
francois: on my to-do list to review
08:37:47 [wseltzer]
bhill2: my impression is that it's in good shape
08:39:03 [bhill2]
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6263699-subresource-integrity
08:40:54 [bhill2]
JonathanKingston: working on SRI support as a broccoli plugin for Ember.js
08:41:01 [bhill2]
... use it out of the box without any scary features
08:41:50 [bhill2]
... 3 examples: same origin (relative path), external, third option to specify the url is same as origin but w/absolute path
08:42:32 [wseltzer]
JonathanKingston: I might be interested in working on an IG note on same-origin policy
08:42:47 [bhill2]
devditz: what is reasoning behind fail-open for non-CORS?
08:43:17 [bhill2]
... if developer has added an integrity attribute, aren't they asking for failure behavior
08:43:39 [bhill2]
francois: pretty much only getting the hash wrong will block, everything else syntax-wise fails open to give us flexibility for future extensibility
08:44:11 [bhill2]
dveditz: what is benefit of failing open if developer forgets to specify CORS mode
08:45:51 [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
08:46:40 [bhill2]
dveditz: actually can't move to fail closed in the future
08:47:11 [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
08:47:54 [bhill2]
... if we integrated into another place in the fetch, we could maybe do something else
08:49:41 [bhill2]
francois: also, old browsers would fail closed, even if a new mechanism to enable it existed
08:52:18 [bhill2]
bhill2: are there any plausible scenarios in which we could avoid CORS fetch?
08:52:24 [bhill2]
francois: not really
08:54:22 [francois]
https://github.com/w3c/webappsec/issues/317 is where most of the discussion took place
08:56:45 [slightlyoff]
slightlyoff has joined #webappsec
08:59:40 [wseltzer]
bhill2: feel pretty comfortable saying we can't integrity-check an opaque response without leakage
09:02:20 [slightlyoff]
where's the thread on github?
09:02:39 [slightlyoff]
thanks
09:02:56 [freddyb]
https://github.com/w3c/webappsec/issues/317#issuecomment-110844444
09:02:59 [freddyb]
this comment
09:13:31 [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
09:15:26 [wseltzer]
i/minor editorial nits
09:15:33 [wseltzer]
i/minor editorial nits/Topic: SRI/
09:15:55 [freddyb]
:)
09:44:19 [bhill2]
rrsagent, draft minutes
09:44:19 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html bhill2
09:44:36 [freddyb]
freddyb has left #webappsec
09:44:36 [freddyb]
freddyb has joined #webappsec
09:46:52 [bhill2]
TOPIC: Minutes approval
09:47:08 [bhill2]
http://www.w3.org/2011/webappsec/draft-minutes/2015-06-29-webappsec-minutes.html
09:47:29 [bhill2]
minutes approved by unanimous consent
09:47:41 [rbarnes]
rbarnes has joined #webappsec
09:49:09 [bhill2]
TOPIC: CfC on non-normative changes to CORS REC
09:49:11 [bhill2]
https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0094.html
09:51:32 [bhill2]
unanimous consent to publish an edited recommendation as indicated
09:52:12 [wseltzer]
bhill: all of these are non-normative changes
09:54:18 [wseltzer]
Topic: Removing unsafe-redirect from CSP2
09:56:17 [wseltzer]
bhill2: mkwst's patch on potential leakage from different redirect depending on login state
09:56:30 [wseltzer]
dveditz: or where leaked path could reveal userid or security token
09:56:53 [wseltzer]
... blocked paths; issue that it's still cross-origin leakage
09:57:09 [wseltzer]
slightlyoff: problem in service workers too
09:58:11 [wseltzer]
... if you have an open redirect on your origin ... auto-xss
09:58:31 [wseltzer]
... how much info is too much? the fact of a redirect?
09:58:50 [wseltzer]
... it would be great if this group could make statements about what info about the presence of a redirect can be exposed
09:58:59 [wseltzer]
... e.g. the fact of a redirect
09:59:08 [wseltzer]
rbarnes: any utility to scoping to cross-origin redirects?
09:59:11 [bhill2]
fyi: this is the patch being discussed: https://github.com/w3c/webappsec/commit/7456cb77e504fa70991b3cc54c852e62ebc7a2cc
09:59:31 [wseltzer]
dveditz: if it's same origin, no problem reaching into the iframe
10:00:35 [wseltzer]
JonathanKingston: you can turn off redirects in fetch
10:01:16 [wseltzer]
slightlyoff: yes: follow, error, or manual
10:01:34 [wseltzer]
bhill2: nobody implemented unsafe-redirect, so ripping it out
10:02:07 [wseltzer]
... but adding a CSP-active
10:04:14 [bhill2]
dveditz: 'unsafe-inline' will break existing users of CSP and attackers will not set it
10:04:37 [bhill2]
... so we should fix reports to not report the violation, potentially even the origin
10:05:20 [bhill2]
bhill2: but the original homakov exploit relied on onerror handling, whether resource loaded at all with CSP, not on reporting
10:07:54 [bhill2]
slightlylate: response object could have 1 bit set indicating if a redirect was traversed
10:08:09 [bhill2]
freddyb: just cross-origin or also same-origin?
10:10:24 [bhill2]
rbarnes: what is the need for this?
10:11:16 [bhill2]
slightlylate: large scale application composition or lack of global knowledge, may not know about flow of authority
10:11:35 [bhill2]
dveditz: do SWs get any headers back?
10:11:52 [bhill2]
slightlylate: for same-origin and CORS we can see almost everything, otherwise no
10:12:21 [bhill2]
dveditz: with no-cache type directives, do we want SWs to cache?
10:12:38 [bhill2]
slightlylate: we explicitly make this the programmer's program, and cache opaque responses opaquely
10:12:55 [bhill2]
... that's the next question I wanted to get to - if redirects are OK, what else is?
10:12:59 [bhill2]
dveditz: caching, vary?
10:13:39 [bhill2]
rbarnes: can we handle this better declaratively? initiator can declare if he expects it to be cross-origin redirected instead of asking
10:14:20 [Zakim]
Zakim has left #webappsec
10:14:25 [rbarnes]
redirect-scope="same-origin"
10:20:16 [wseltzer]
bhill2: you could already force that information leak in CSP
10:22:01 [bhill2]
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
10:22:05 [rbarnes]
unsafe-allow-redirects=t.co
10:22:53 [bhill2]
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
10:23:04 [bhill2]
it's just syntactic sugar for an existing infoleak
10:24:43 [bhill2]
bhill2: if surfacing this formally generates strong objections and good security reasons not to do it, should we change CSP?
10:25:01 [bhill2]
... to allow the initial resource the implicit authority to delegate
10:25:13 [bhill2]
dveditz: that would be a horrible hole in CSP in my opinion, really don't want to do that
10:27:34 [bhill2]
TOPIC: CSP Level 2 and inline styles
10:29:04 [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
10:29:36 [bhill2]
dveditz: this is by design, because individual properties have validators and prevent free-form setting of styling that might be more powerful
10:29:50 [bhill2]
... maybe we should add a better explanation to the spec
10:30:02 [bhill2]
... it was explained in long threads, but that may have not translated to our final text
10:30:45 [bhill2]
JonathanKingston: this is broken everywhere, I've been advocating preventing setting of style in Ember and using individual attributes instead
10:30:57 [bhill2]
... but can't point to spec text that says why one is OK and the other is not
10:37:02 [bhill2]
raised https://github.com/w3c/webappsec/issues/423
10:37:17 [JonathanKingston]
https://github.com/hillbrad/web-platform-tests/blob/7845ee1a94700b95aa9ef636aae66adae5e27efe/content-security-policy/blink-contrib/inline-style-allowed-while-cloning-objects.sub.html
10:55:45 [freddyb]
https://bugzilla.mozilla.org/show_bug.cgi?id=883975
10:55:47 [freddyb]
https://bugzilla.mozilla.org/show_bug.cgi?id=855326
11:06:18 [mkwst]
I am, in theory, here.
11:06:38 [mkwst]
Just need to find the entrance. :)
11:10:00 [mkwst]
Found it! Probably! Waiting for an elevator.
11:34:21 [rbarnes]
rbarnes has joined #webappsec
11:42:28 [mkwst]
present+ mkwst
11:42:47 [wseltzer]
[reconvene]
11:43:17 [wseltzer]
Topic: Mixed Content
11:43:50 [wseltzer]
mkwst: Mixed content is implmented in every major browser
11:44:02 [wseltzer]
... substantial test suite
11:44:26 [wseltzer]
... some failures around forms
11:45:20 [wseltzer]
... CfC on-list
11:45:43 [wseltzer]
... one thread on service workers
11:46:02 [wseltzer]
... operations on an opaque blob
11:46:15 [wseltzer]
... fetch from within a service worker
11:48:06 [wseltzer]
... Brian saying: with new stuff, we shouldn't support insecure practices
11:49:11 [wseltzer]
... Not sure we need to answer it all in the initial draft
11:49:24 [wseltzer]
dveditz: also some concerns about CSP and service workers
11:49:42 [wseltzer]
mkwst: service workers act as a network proxy
11:50:06 [wseltzer]
... page should have the ability to govern what loads on the page, not what's on the network
11:50:38 [wseltzer]
slightlyoff: the governing policy for the service worker needs to be sent with the service worker
11:50:58 [wseltzer]
dveditz: the CSP of the sw may be different from any of the multiple pages that use the sw
11:52:21 [wseltzer]
mkwst: a constructed response is similar to a blob URL
11:54:00 [wseltzer]
mkwst: we should enable pages to set policy that disallows constructed responses
11:54:16 [wseltzer]
slightlyoff: where will that policy come from?
11:54:21 [wseltzer]
mkwst: from the page or the sw
11:56:24 [wseltzer]
mkwst: should the page have the ability to control the "washing" of requests / redirects through sws?
11:57:04 [wseltzer]
dveditz: if sw is serving multiple pages, it may want to obey CSPs, but not know what they are?
11:57:12 [wseltzer]
... may be a good thing to hook on responses
11:57:27 [wseltzer]
bhill2: is there a security boundary that we could be enforcing?
11:59:36 [wseltzer]
mkwst: Mixed Content is asking: should the sw be bound by the same policy as the page?
11:59:47 [wseltzer]
... seems like a different question from security policy
12:02:05 [wseltzer]
... currently, no way for sws to make insecure requests
12:02:11 [wseltzer]
... no problem if we don't change that.
12:02:38 [wseltzer]
... Other question, whether deprecated TLS needs to be in Mix
12:02:46 [wseltzer]
... Just rely on fetch.
12:02:58 [wseltzer]
... I suggest that we push it to PR
12:03:27 [wseltzer]
bhill2: Mixed content checks fire before HSTS upgrades
12:04:46 [wseltzer]
... 2 sides: mix first, since not all browsers support HSTS
12:05:02 [wseltzer]
... but now IE has HSTS
12:05:18 [wseltzer]
... and it may be more pain than benefit
12:05:46 [wseltzer]
... so now more inclined to make things easy for devs to start transitioning
12:06:09 [wseltzer]
francois: also consider instead of blocking, opportunistic upgrades
12:06:35 [wseltzer]
... keep the missing padlock, but try to improve
12:06:55 [wseltzer]
mkwst: relates to tanvi's question about upgrade-insecure and strict mode
12:07:19 [wseltzer]
... the different forbes websites at http and https
12:08:34 [wseltzer]
slightlyoff: I asked the crawl incidence: 99.7% conincidence between http https
12:08:47 [wseltzer]
... fuzzy, mostly based on text
12:09:56 [wseltzer]
mkwst: Adam Langley opposes changes the ordering of Mix - HSTS
12:10:10 [wseltzer]
... we should talk more with the network folks
12:10:48 [wseltzer]
dveditz: another possible level, in strict-mode, do before; in non-strict mode, do HSTS first
12:11:01 [wseltzer]
mkwst: strict mode also disables user decisions
12:11:06 [wseltzer]
... by blocking the request
12:14:11 [wseltzer]
... intent is not to show the user option to turn on the insecure
12:14:59 [wseltzer]
bhill2: some of the auto-upgrade may be suitable for level 2
12:15:14 [wseltzer]
... we'll have more options, e.g. automatic discovery
12:15:51 [wseltzer]
https://w3c.github.io/webappsec/specs/mixedcontent/#further-action
12:16:47 [wseltzer]
mkwst: how you choose not to load insecure resources is up to you
12:17:05 [wseltzer]
francois: what about potentially secure?
12:17:28 [wseltzer]
mkwst: language might need improvements between secure context / mixed content
12:17:39 [wseltzer]
... Mix uses secure to mean HTTPS
12:20:37 [wseltzer]
[discussion of localhost]
12:20:54 [wseltzer]
mkwst: I'm loath to carve out exception
12:21:51 [wseltzer]
... I don't like "install app locally and then need to talk to it from the open web" because of security considerations
12:22:12 [wseltzer]
... versus let devs test their apps on localhost before installing on HTTPS servers
12:22:26 [wseltzer]
... different treatment for RFC 1918 hosts @@
12:22:46 [wseltzer]
... loading RFC 1918 from the web
12:23:21 [wseltzer]
rbarnes: origin resolving to 1918 address, or the address itself?
12:23:24 [wseltzer]
mkwst: ideally, both
12:23:37 [wseltzer]
... would have liked to block those
12:23:45 [mkwst]
https://www.chromestatus.com/metrics/feature/popularity
12:23:50 [wseltzer]
... but more widely used than I'd like
12:23:57 [mkwst]
https://www.chromestatus.com/metrics/feature/timeline/popularity/530
12:24:03 [mkwst]
~0.6% of page views.
12:24:44 [wseltzer]
rbarnes: apps getting certs for local, then had to have the certs revoked
12:24:48 [wseltzer]
... so it's a good thing to block
12:25:21 [wseltzer]
mkwst: it's reasonable to want to have a single definition
12:25:36 [wseltzer]
... threat model of mix is attacker who can see what you're doing or interfere
12:25:46 [wseltzer]
... not the local host
12:26:21 [wseltzer]
bhill2: you could also say Mix is a contract of tranquility of the secure state
12:26:35 [wseltzer]
... violated by local resources even if no network attacker
12:28:39 [wseltzer]
bhill2: 3 issues
12:28:50 [wseltzer]
... block local network resources? - more discussion
12:29:01 [wseltzer]
.... deprecated TLS. was listed at-risk
12:29:17 [wseltzer]
... we should remove the refs that now go to undef termm
12:29:21 [wseltzer]
s/termm/term/
12:30:34 [wseltzer]
... and the service worker question
12:33:51 [wseltzer]
mkwst: EME issue
12:34:43 [wseltzer]
... get back an opaque blob to pass to elsewhere
12:35:31 [rbarnes]
perhaps we just need EMEHR
12:35:39 [wseltzer]
... we block XHR and fetch, because they leak information
12:36:16 [wseltzer]
... if we could guarantee that it was just data being used, not executed, then we could do different things, possibly
12:36:30 [wseltzer]
... I'm not entirely convinced
12:37:54 [wseltzer]
rbarnes: have the page declare that the data will be used in only one way
12:38:24 [wseltzer]
... e.g. declare things browser accessible only
12:38:47 [wseltzer]
bhill2: I don't want to encourage people to put more edge cases into HTTP
12:39:32 [wseltzer]
mkwst: Agree. I've heard more requests for the localhost thing than anything else.
12:41:00 [wseltzer]
mkwst: editorial change on deprecation
12:41:09 [wseltzer]
... not going to do anything with localhost or fetch
12:41:31 [wseltzer]
... so group is more or less happy to push this out and come back if there are compelling use cases.
12:41:45 [wseltzer]
axel: what's your solution to web page talking to its associated location?
12:41:53 [wseltzer]
mkwst: there's not a current solution
12:41:57 [wseltzer]
... we need a better one.
12:42:19 [wseltzer]
... I'd suggest it needs at least 2 components: allow app to opt-in to communication
12:42:28 [wseltzer]
... and the user has to allow access to local net.
12:42:43 [wseltzer]
... and probably other things need to happen.
12:43:44 [wseltzer]
axel: I have an app I want to have used by many websites
12:43:56 [wseltzer]
... earlier working blocked by mixed content
12:44:50 [wseltzer]
mkwst: apps installed locally have high privilege, and it's dangerous to expose that privilege to the open web
12:45:12 [wseltzer]
... I think I agree there are good use cases for talking to something local
12:45:33 [wseltzer]
... but simply exposing the interface to the web is a bad idea
12:46:03 [wseltzer]
slightlyoff: navigator connect. one of the hopes for sw is to let apps talk
12:46:20 [wseltzer]
... navigator connect lets apps post-message
12:46:40 [wseltzer]
... lets a sw register to provide services located at a URL
12:47:28 [wseltzer]
... the whole thing ends up in the origin security model
12:47:36 [wseltzer]
... a thin abstraction over RPC for the web
12:47:51 [wseltzer]
s/sw/service workers/G
12:48:13 [wseltzer]
... hoping to use it as a bootstrap for launching APIs
12:48:53 [wseltzer]
... make it easier to experiment
12:49:08 [wseltzer]
... without leaving trails of old things
12:49:54 [wseltzer]
... navigator.connect IPC bridge with short-term windows
12:50:15 [wseltzer]
... more science, less guessing
12:55:04 [wseltzer]
mkwst: postmessage from secure to insecure happens on ~5% of pageviews
12:55:15 [wseltzer]
... and from insecure to secure on ~3%
12:55:49 [wseltzer]
JonathanKingston: u2f?
12:55:56 [wseltzer]
mkwst: currently in chrome, it's an extension
12:57:58 [wseltzer]
... I think it's unfortunate that we shipped in a way that requires extension
12:58:14 [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.
12:59:45 [jose-cdbtr]
jose-cdbtr has joined #webappsec
13:00:26 [JonathanKingston]
wseltzer: sorry missed that: https://fidoalliance.org/specifications/overview/
13:01:35 [rbarnes]
theme for the w3c https call: https://en.wikipedia.org/wiki/Just_Do_It#/media/File:JUST_DO_IT._%28NIKE%29.gif
13:03:42 [jose-cdbtr]
present +jose
13:04:44 [wseltzer]
Topic: HTTPS for w3.org
13:09:25 [dveditz]
wseltzer: the numbers would be the ones listed here: https://wiki.mozilla.org/WeeklyUpdates except a differernt conference number
13:10:04 [dveditz]
conference 95201#
13:10:51 [dveditz]
and the # key after
13:12:59 [dveditz]
jose-cdbtr: any luck?
13:13:05 [dveditz]
we don't hear you
13:14:13 [dveditz]
after the 92 did you hear an invitation to enter the conf number?
13:14:20 [dveditz]
I think you needed 92#
13:15:30 [dveditz]
possible... we're checking
13:16:45 [dveditz]
rebooting our system
13:18:40 [dveditz]
jose-cdbtr: are you saying anything? we can't hear you
13:19:37 [dveditz]
yes, we can hear you
13:20:35 [wseltzer]
https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0099.html
13:23:24 [dveditz]
jose-cdbtr: we hear it too. don't know the cause
13:23:25 [bhill2]
wseltzer: thanks to webappsec for pushing w3c to upgrade to https and providing technologies to help do so
13:23:41 [bhill2]
... constraints are that w3c site is a huge mass of hand-written pages with lots of absolute links to http
13:23:56 [bhill2]
... want to enable secure connections to as much as can be securely accessed w/o going back to hand-tweak all those links
13:24:07 [rbarnes]
rbarnes has joined #webappsec
13:25:28 [wseltzer]
jose-cdbtr: we have multiple servers for different services
13:26:01 [wseltzer]
... and previously used switch-SSL to switch requests from HTTPS to HTTP for resources we didn't offer in HTTPS
13:26:22 [wseltzer]
... proposing to stop making that switch
13:26:48 [wseltzer]
... Lots of historic content that we can't update
13:27:54 [wseltzer]
... many pages written individually, by hand
13:28:11 [rbarnes]
mod_rewrite?
13:28:43 [wseltzer]
bhill2: are there things that you're aware of that are still broken where the browser could help upgrade more smoothly?
13:29:19 [wseltzer]
jose-cdbtr: some infinite loops with HSTS and redirects
13:30:47 [bhill2]
mkwst: have you filed a bug against the browser which had this behavior?
13:31:18 [bhill2]
jose-cdbtr: not yet
13:31:43 [rbarnes]
i mean, if your HSTS-enabled page redirects to http://, you're gonna have a bad time
13:34:17 [bhill2]
bhill2: was the CSP reporting issue related to HTTPS upgrades or a different policy you were trying to set?
13:34:47 [bhill2]
... e.g. were theses reports from setting something like default-src: *, or were you trying to do another kind of policy?
13:34:58 [bhill2]
... sorry default-src https:
13:35:27 [bhill2]
mkwst: sounds like current upgrade strategy is dependent on upgrade-insecure-requests
13:35:38 [bhill2]
... what will you do for browsers that don't support that
13:36:33 [bhill2]
jose-cdbtr: we will support http for some resources that are public
13:38:13 [wseltzer]
mkwst: the header that is now HTTPS:1 will soon be renamed
13:38:31 [wseltzer]
... it will allow distinguishing between browsers that support upgrade-insecure and those that don't
13:39:32 [rbarnes]
let this be a lesson to you all -- scheme-relative URIs!
13:40:24 [freddyb]
rbarnes: but relative is weak. you never know what your context is :-P the lesson is clearly HTTPS links only
13:41:03 [rbarnes]
freddyb: well, if they'd planned for this in the first place...
13:42:17 [rbarnes]
sorry, s/http:/https:/g
13:42:17 [freddyb]
rbarnes: is this because you want root?
13:43:05 [wseltzer]
jose-cdbtr: we don't want to break old tools that rely on http:
13:43:31 [wseltzer]
... what will we do with DTDs and namespaces
13:44:30 [wseltzer]
mkwst: what do you mean tools that don't support HTTPS?
13:45:52 [wseltzer]
jose-cdbtr: we asked the TAG for advice
13:47:06 [rbarnes]
jose-cdbtr: this tool might be helpful for finding mixed content: https://github.com/bramus/mixed-content-scan
13:47:17 [wseltzer]
jose-cdbtr: please try the test searver, email systeam if you find errors
13:48:16 [rbarnes]
francois, freddyb: i see that upgrade-non-secure-requests has landed in Firefox. do we send a header to announce support?
13:49:18 [wseltzer]
mkwst: you might split, upgrade to HTTPS first, then HSTS
13:49:26 [slightlyoff]
+1 to what mkwst suggested
13:49:42 [freddyb]
rbarnes: dunno, can't find the bug off hand
13:53:22 [dveditz]
https://bugzilla.mozilla.org/show_bug.cgi?id=1139297
13:54:55 [JonathanKingston]
Can I ask where the best place for bug reports on this platform is?
13:54:57 [rbarnes]
freddyb: Cmd-F "header" indicates probably not
13:55:02 [jose-cdbtr]
sysreq@w3.org
14:46:16 [wseltzer]
Topic: Secure Context
14:46:32 [wseltzer]
mkwst: Neither Yan nor I has done much
14:46:39 [wseltzer]
... lately
14:46:54 [wseltzer]
rbarnes; some editorial suggestions
14:46:58 [wseltzer]
mkwst: send a pull request
14:47:08 [dveditz]
mkwst: ancient (still open) 2004 Mozilla bug to change our handling of data: urls https://bugzilla.mozilla.org/show_bug.cgi?id=255107
14:47:43 [wseltzer]
mkwst: do we need to guarantee that a context can't be abused, e.g Netflix shim on webcrypto
14:47:49 [wseltzer]
... walking the ancestor tree
14:50:28 [wseltzer]
rbarnes: assume we have a unitary concept of secure, then we're worried about communication from secure to insecure
14:51:27 [wseltzer]
bhill2: we don't have a no write-down policy on the web today
14:51:41 [wseltzer]
... we assume origins are authoritative
14:52:24 [wseltzer]
rbarnes: that suggests we can't solve mkwest's shim problem
14:52:32 [wseltzer]
bhill2: you could do a latch like COWL
14:53:06 [wseltzer]
bhill2: tomorrow, let's talk about our inconsistent notions of security
14:53:34 [wseltzer]
... tranquility vs information flow contracts
14:55:59 [wseltzer]
mkwst: push-notification proxy for third-party origins
14:56:04 [wseltzer]
... roost
14:56:20 [wseltzer]
... if we want secure context to have meaning, should make it non-trivial to circumvent
14:57:45 [wseltzer]
mkwst: if you're using message ports as a capability token...
14:59:57 [wseltzer]
mkwst: some people asking for isolation
15:00:31 [wseltzer]
... e.g., separate cookie jar, no communication with the open web
15:00:41 [wseltzer]
slightlyoff: I want storage isolation
15:00:50 [wseltzer]
... local storage, cookie jar, cache separated
15:01:04 [wseltzer]
mkwst: like double keying
15:01:14 [wseltzer]
slightlyoff: yes. chrome apps already do this
15:01:25 [wseltzer]
... allows everyone else to live without the ambient authority
15:01:54 [wseltzer]
dveditz: firefox OS apps have taken that approach
15:02:00 [wseltzer]
... double-keyed, no pollution
15:02:10 [wseltzer]
... now they're tacking the other way, because logins don't persist
15:02:25 [wseltzer]
mkwst: as a blanket mechanism, it seems problematic
15:02:32 [wseltzer]
... as opt-in, seems good
15:04:00 [wseltzer]
mkwst: isolation writ large; second, what's sufficiently secure context; might be no write-down
15:04:18 [wseltzer]
... you can't post-message to insecure contexts, perhaps
15:04:32 [wseltzer]
bhill2: how do we evolve to a web where everything is secure?
15:04:55 [wseltzer]
... where that trust is on servers and browsers
15:05:26 [wseltzer]
mkwst: don't talk to insecure stuff
15:06:25 [wseltzer]
rbarnes: a sufficiently determined server could always route through for insecurity
15:06:33 [wseltzer]
bhill2: you can't prevent delegation
15:08:54 [wseltzer]
dveditz: would it make sense to change postmessage?
15:09:41 [wseltzer]
mkwst: conceptually, don't post to insecure things seems like a reasonable thing for a website to opt-into
15:09:52 [wseltzer]
... is that necessary to get access to these APIs?
15:10:28 [wseltzer]
JonathanKingston: good for encouraging upgrade
15:11:06 [wseltzer]
mkwst: current spec walks the ancestor tree
15:11:18 [wseltzer]
... apparently does the wrong thing in th ecase of workers
15:11:27 [wseltzer]
... and nothing in the case of new windows
15:11:30 [wseltzer]
... do we care?
15:11:36 [wseltzer]
bhill2: let's discuss tomorrow
15:11:42 [wseltzer]
rrsagent, make minutes
15:11:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html wseltzer
15:12:15 [wseltzer]
bhill2: we have lots of pieces at work here: isolation, information flow, COWL
15:12:44 [wseltzer]
... incline to simpler, coherent policy for the long run
15:12:52 [wseltzer]
... rather than more complex to motivate changew
15:13:29 [wseltzer]
i/unsafe-inline/scribenick: bhill2
15:13:42 [wseltzer]
i/reconvene/scribenick: wseltzer
15:13:51 [wseltzer]
rrsagent, make minutes
15:13:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html wseltzer
15:19:24 [wseltzer]
i/attackers will not set it/scribenick: bhill2/
15:19:36 [wseltzer]
rrsagent, make minutes
15:19:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html wseltzer
15:21:12 [wseltzer]
present+ Axel
15:21:54 [wseltzer]
rrsagent, make minutes
15:21:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/07/13-webappsec-minutes.html wseltzer
15:24:29 [bhill2]
bhill2 has joined #webappsec
16:07:12 [rbarnes]
rbarnes has joined #webappsec
16:07:53 [jose-cdbtr]
jose-cdbtr has left #webappsec
16:51:54 [tanvi]
tanvi has joined #webappsec
18:02:44 [tanvi]
tanvi has joined #webappsec
18:42:40 [tanvi1]
tanvi1 has joined #webappsec
21:27:41 [rbarnes]
rbarnes has joined #webappsec
22:05:28 [renoirb]
renoirb has joined #webappsec