Issue: It's currently possible for attackers to create and control remote debugger connections. Remediation: There are a range of possible solutions from prompting at the debuggee before accepting connections to use of zrtp; this would be a good place to discuss eventual solutions and any possible interim measures.

Jim Blandy and I discussed this in detail at the Devtools Work Week. We considered leveraging the ZRTP Protocol during the Diffie-Hellman key exchange, to avoid the threat of MITM without having a pre-determined shared secret between the Debugger and the Debuggee (ex: Laptop and Mobile Device). * http://en.wikipedia.org/wiki/ZRTP#Authentication. The pin is the Short Authentication String. * To prevent mitm, Bob commits to g^b ahead of time by sending hash(g^b) - http://seclab.stanford.edu/pcl/cs259/WWW06/projects/project05/05-Writeup.pdf How it works: Computer sends Phone the X=hash(g^b) (committing to b) Phone sends Computer g^a Computer sends Phone g^b. Phone checks that the hash(g^b)=X PHone and Computer compute g^ab and use that to generate their shared symmetric secret to encrypt/decrypt messages. The phone and computer both compute hash(g^a, g^b) and converts it to a ~6 digit pin. The computer displays the 6 digit code to the developer, and the developer enters that into the phone. If the pin does not match on the phone, there is a man in the middle and the connection terminates. This ensures that the connection is between the user's computer and the phone, and hasn't been man in the middle'd with a g^a' and a g^b' by an attacker. Potential Issues: You could cause a DOS. If the pin is always wrong (because you are always being mitm), then the device and the computer can never talk to each other. However, I don't think we are too worried about the DOS threat here. We can discuss more int he security review. (Note we are only using a portion of the ZRTP protocol. In the ZRTP protocol, the pin is communicated by voice instead of by typing a pin. Attacks to the ZRTP protocol involve attacks to the portion of a conversation where the voice is communicated, which is not an issue in our case.) Would love to get more eyes on this proposal - bsmith, badida?

I talked to Tanvi today. She is going to report back on whether we can use the existing J-PAKE-based mechanism that we already have for the current version of Sync to do this, so we don't have to do all new crypto bits. We also discussed the possibility of doing this on top of WebRTC and/or on top of SSL, to avoid creating a new transport security protocol for the debugger. I think Tanvi is going to approach the people implementing the debugger to discuss some other things that got brought up in the chat.

Thanks Brian for your note! A few other things that I discussed with Brain today... * Will a mobile device (debuggee) that is constantly listening on port 6000 for debuggers cause battery life issues for the phone? * Have we considered debugging over bluetooth? * Does ZRTP have a patent that limits our ability to use it? We should discuss authentication more and figure out the best way to achieve both the usability and security goals.

Marionette uses the remote debugger as its transport layer. A Marionette client (either Python or JS, but not necessarily a gecko process) connects to the Marionette server over a remote debugger connection. Will this security mechanism be compatible with non-Gecko clients?

J-PAKE (or any PAKE protocol) seems like a better match than an SAS scheme (such as ZRTP) here. The basic security model is that we want to authenticate the user (i.e., the debugging computer) to the phone. So why not have the phone generate a PIN that the developer types into the computer. This has a number of advantages, including: (a) You can have a fixed PIN that is printed on the phone if you like (b) You can give out the PIN to others for temporary access. [and indeed have multiple PINs] (c) You don't need to have the phone in your hand at the same time as you want to connect to it. (d) You are entering the PIN into the device that is the master and so you don't need to worry if the device only barely is functional. (e) PAKE for TLS is already standardized, though admittedly you would need to use SRP, not J-PAKE. Note that you can always run PAKE in a "single-use PIN" mode, so it's basically dominant here.

One more observation: you're probably going to want to be able to permanently authorize a debugger for a phone (or at least long-term authorize it) so that it doesn't require PIN interaction every time, just as a convenience. This can obviously be done by having some cached authorization credential, even if you use an SAS rather than PAKE scheme, but with PAKE it's super-natural, since you can just have the debugger memorize the PIN.

(In reply to Jonathan Griffin (:jgriffin) from comment #4) > Marionette uses the remote debugger as its transport layer. A Marionette > client (either Python or JS, but not necessarily a gecko process) connects > to the Marionette server over a remote debugger connection. > > Will this security mechanism be compatible with non-Gecko clients? I can't answer that question, but in the meeting yesterday I believe there was consensus when I suggested that we would leave connections over the loopback interface unencrypted and unauthenticated. Marionette only uses the loopback interface, right?

(In reply to Panos Astithas [:past] from comment #7) > (In reply to Jonathan Griffin (:jgriffin) from comment #4) > > Marionette uses the remote debugger as its transport layer. A Marionette > > client (either Python or JS, but not necessarily a gecko process) connects > > to the Marionette server over a remote debugger connection. > > > > Will this security mechanism be compatible with non-Gecko clients? > > I can't answer that question, but in the meeting yesterday I believe there > was consensus when I suggested that we would leave connections over the > loopback interface unencrypted and unauthenticated. Marionette only uses the > loopback interface, right? No it doesn't; we use it with e.g., B2G devices where the Marionette client is running on a separate machine.

(In reply to Jonathan Griffin (:jgriffin) from comment #8) > (In reply to Panos Astithas [:past] from comment #7) > > (In reply to Jonathan Griffin (:jgriffin) from comment #4) > > > Marionette uses the remote debugger as its transport layer. A Marionette > > > client (either Python or JS, but not necessarily a gecko process) connects > > > to the Marionette server over a remote debugger connection. > > > > > > Will this security mechanism be compatible with non-Gecko clients? > > > > I can't answer that question, but in the meeting yesterday I believe there > > was consensus when I suggested that we would leave connections over the > > loopback interface unencrypted and unauthenticated. Marionette only uses the > > loopback interface, right? > > No it doesn't; we use it with e.g., B2G devices where the Marionette client > is running on a separate machine. And you don't use USB debugging with 'adb forward' for those?

> > > > > > I can't answer that question, but in the meeting yesterday I believe there > > > was consensus when I suggested that we would leave connections over the > > > loopback interface unencrypted and unauthenticated. Marionette only uses the > > > loopback interface, right? > > > > No it doesn't; we use it with e.g., B2G devices where the Marionette client > > is running on a separate machine. > > And you don't use USB debugging with 'adb forward' for those? We do at present, although I'm not 100% sure this will be the case when we start running tests with real devices in continuous integration.

I also think J-PAKE is a better idea for this scenario. Further, I wonder if we can invert it a bit: the browser can pick a key, and show a QR code. The developer only needs to hold the phone running the debugger in front of the screen, and the phone snaps a picture and automatically connects. I feel this will be a nicer UX.

A couple of summary comments: 1) Marionette, a Python process uses the Debug Protocol to drive its automation. We need to continue to support that. 2) (J-)PAKE seems to be a preferred authentication scheme. It's short, it's simple, it's relatively pleasant and we can reuse the implementation that came with Sync. 3) We've discussed using DOMCrypt during our review as an easy to use, available crypto solution but it's not in tree yet. 4) We should consider making an option for always allowing connections on mobile devices. Can we consider making a plain-text, unencrypted version of the protocol available for use in the automation scenario? We could do some preference juggling to ensure that humans can't actually turn this on without going through some complicated hoops if that's deemed necessary.

Can we close this now that bug 758696 is landed? Alternatively, I can make that bug block our debugger tracking bug 676586 and keep this one open.

(In reply to Rob Campbell [:rc] (:robcee) from comment #13) > Can we close this now that bug 758696 is landed? Alternatively, I can make > that bug block our debugger tracking bug 676586 and keep this one open. We should keep this open until we implement encryption.

I'm going to mark this effectively done, by implementing the WiFi auth strategy described in bug 962308. If we want to bring such protections to additional types of remote debugging, let's file new bugs for those things.