WebRTC vaulnerability debate

17:30	caitp	shachar: as one of the commentors said, "immature dtls implementation, sctp stack in userland, etc" -- but even if this wasn't the case, peer to peer networking of any kind is a pretty huge attack surface to contain in the browser
17:31	caitp	i'm not sure how it's getting access to the filesystem, but if it somehow is, and you can convince a client to talk to you, you suddenly have unauthorized access to their filesystem
17:31	shachar	caitp: well that's what webrtc is about, and I think containing that in the browser is making it safer not more pentratable
17:32	caitp	and nevermind all the regular legal issues with filesharing pirated content
17:32	jesup	caitp: yes, though any attacker with access to your link (see coffeeshops) can do similar things to client-server links
17:32	caitp	which means that law enforcement and third parties will want their noses up in it
17:32	ekr	caitp: I don't think that's actually a very accurate assessment of the state of the world. the attack surface of the WebRTC  networking stack isn't inherently much greater than the existing Web attack surface (though it is of course newer)
17:32	abr	caitp -- we already have that problem with encrypted media. Cf. the push to introduce SDES.
17:33	caitp	oh I agree ekr -- I'm not saying it's inherently greater
17:33	ekr	caitp: and it's not at all difficult to get arbitrary people to connect to your Web site.
17:33	ekr	(See, for instance, any paper which uses ad networks as a study tool)
17:33	caitp	but I think that there is probably an opportunity for mischief, especially in the early days of it
17:34	jesup	caitp: and filesharing still requires the normal file-access user requests to give the JS app access to a file
17:34	caitp	which is good
17:35	ekr	caitp: I guess my point is that I'm not sure it's useful to distinguish P2P from CS in this case.
17:36	jesup	And certainly we're looking very hard at all the new network surfaces, as is google.
17:38	caitp	anyways I'm not saying that you can't also perform mischief with CS style networking like man in the middle attacks or modifying a response from the server or something
17:38	shachar	how can you man in the middle if the signaling done directly between 2 peers (via server) and the peerconnection is secured afterwards
17:39	ekr	caitp: I'm not sure I follow your threat model.
17:40	caitp	okay, lets be hypothetical
17:40	ekr	Are you primarily concerned about people attacking the communications channel or about them compromising the browser
17:42	caitp	it's not so much a concern -- it's an active interest in finding holes in it
17:42	caitp	and there are always holes
17:43	ekr	caitp: again, what's your threat model. What is the attacker trying to do?
17:44	caitp	so suppose, hypothetically, an attacker leads a user to some site and asks for a datachannel connection
17:44	ekr	caitp: sure.
17:45	caitp	hypothetically, they might find a way to convince the remote users browser to let them see their filesystem
17:46	caitp	how they'll do this, that's a harder problem
17:47	caitp	if the browser needs to grant permission to the js app to leave its sandbox that's one thing, but probably isn't completely insurmountable
17:47	shachar	caitp: your attack model is nothing new towards WebRTC you can do that with youSendIt/Mega/WeTransfer/etc' etc'
17:47	caitp	yeah I agree
17:48	caitp	but it is a bit different for the reasons that commentor mentioned, one being the immature dtls impl
17:48	caitp	which could potentially make the transport layer easier to sneak into
17:48	caitp	would have to research that
17:50	caitp	it's not about it being new and exciting or easy, it's really about demonstrating it happening, and I think you can probably expect that to happen, especially if people do use it for file transfers
17:50	caitp	it's not too hard to picture certain communities on dalnet getting excited about that and finding ways to cause problems