J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Description • 11 years ago

We'd like to be able to debugging remote devices over Wi-Fi to simplify the UX involved. 

I've drafted a few proposals of how this could work:

https://docs.google.com/a/mozilla.com/document/d/16xDiRnRmNUldsrEKRSXgQYh4-O_14ccE64htaOpL22M/edit

You should be able to make comments on this doc.  Please do so, and I'll fold them in to new versions as needed.

Any feedback on security, UX, or anything else would be greatly appreciated!

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 1 • 11 years ago

I am in particular interested in what the security team thinks of each proposal.  Not sure who's the best fit to review this in detail...  Hopefully you can decide! :)

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 2 • 11 years ago

I've made a start and put some comments in the document. The biggest thing that scares me is leaving a network port open permanently. Avoiding that (perhaps by requiring the user to initiate the process on the phone) I think would greatly lower the risk.

Depending on how we do mutual authentication, I can imagine that we could greatly simplify the UX too. As a comparison, I believe later versions of android support ssh authenticated debugger connections without a prompt the user ( maybe, not sure, never tried it myself).  See  also bug 842747 & 845193. 

I'm in a work week at the moment but I started a braindump of threats at the moment. We might decide that we don't mitigate all the threats (e.g we might choose to warn the developer about the risks of debugging over untrusted wifi) but this is a start anyways.

1. Remote compromise of the phone
	- attacking network stack (v. unlikely I assume, and probably a shared risk with something like webrtc peerconnection)
	- attacking pre-authentication debugger protocol
	- DoS the phone by spamming network connection to the device? (either via popus or battery)

2. Unauthorized debugging connection
	- brute force the pin?
	- eaves drop the pin
	- convince the user to hit accept, even though the pin is wrong

3. Disclosure of sensitive information while debugging
	- observe wifi traffic
	- intercept network traffic/mitm/arp spoof etc
	- user forgets they are debugging, and change networks (e.g im debugging on my laptop at home, then I go into work.)

	Guillaume Destuynder [:kang] [this account is no longer active]
	Comment 4 • 11 years ago

I made some comments in the document as well. In a nutshell, for both proposal:

- when communication over wifi, communication should be encrypted, authenticated (the TLS proposal is fine, for example - AFAIK adb doesn't support encryption over the tcp transport so it'd need that feature)

- authentication with the user is quite nice in secure adb (bug 842747): both phone and computer have a RSA key, and when you try to connect to the phone from the computer, the phone display a prompt with the computer's RSA key fingerprint. You can choose to accept & save and it will never ask again. if using TLS instead of adb, the issue is creating the RSA key on the computer side. In this case it's probably easier to tie to a Firefox Account - or even use a uuid/pin [this solution is spoofable so not as safe]).

- mac addresses are spoofable and can't be used for authentication

	Philipp Kewisch [:Fallen] [:📆][:🧩]
	Comment 5 • 11 years ago

Just a random thought I had when reading this bug, I don't know if its been proposed. Possibly on top of another secure mechanism, you could restrict debugging to specific wifi networks (i.e. "Always allow debugging in this network?"). This would save the port from being open on public wifi networks, but be very convenient when you are at home and debugging.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 6 • 11 years ago

Thanks for all the feedback so far!  I've revised the proposal significantly to resemble secure ADB in many ways, and I think it's now more secure and simpler to use.  The document lists a more complete change log at the top.

Please take another look.  If things are looking good I'll start filing various bugs to plan out the work here.

I do have one question that's worth focusing on here.  How critical is encryption in this case?  Obviously, the data can easily be overheard without it, but I am not convinced this is that bad if we are up front about it.  Would you say encryption should be required to ship this feature?  Or could we instead show a popup or something when enabling Wi-Fi debugging, reminding the user that the data is sent in the clear and can be overheard?  There's quite a bit of additional effort needed to make encryption possible, so I just wanted to get a sense of just how critical we believe it to be here.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 7 • 11 years ago

(In reply to Philipp Kewisch [:Fallen] from comment #5)
> Just a random thought I had when reading this bug, I don't know if its been
> proposed. Possibly on top of another secure mechanism, you could restrict
> debugging to specific wifi networks (i.e. "Always allow debugging in this
> network?"). This would save the port from being open on public wifi
> networks, but be very convenient when you are at home and debugging.

Yes, that's an interesting idea.  I think we could look at that as a potential enhancement once the core of this is in place.  It does make the UX more complex (prompting for particular networks, possibly managing a list, checkbox for saying you don't care, etc.), so that's why I am a little wary, just because I like "one click" appeal of the current proposal.  But you are right, perhaps many would feel more comfortable with this type of safety mechanism.

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 8 • 11 years ago

Didn't mean to remove my need info, just adding some people in the cc list. Still looking...

	Guillaume Destuynder [:kang] [this account is no longer active]
	Comment 9 • 11 years ago

this looks good to me. Sorry for the delay!

juste one note for the UX, it would be valuable if its possible to have the public cert/key fingerprint presented on both the phone and the computer for the first authentication (unknown computer), so that someone who wants to make sure hes the one initiating the connection can(adb does that, too).

I'm mentioning it as i know a fingerprint isn't always super user friendly - but since it's to put the phone in "dev mode" i would assume the devs would find that just fine.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 10 • 11 years ago

Brian, I was hoping you may have some high level thoughts on the encryption implementation here.

If you look over the proposal (comment 0), you'll see I mention using TLS and self-signed client auth certs in the later "Encryption" section.

Does this seem like a reasonable strategy?

Assuming it does, this is my understanding of the major pieces of work we would need to achieve the encryption part:

* On the remote (B2G) side, we'd need a TLS server, which does not currently exist in Gecko (similar to bug 242448)
* When someone tries to connect over Wi-Fi for the first time using the App Manager in Firefox desktop, it would need to generate a self-signed cert for use in client authentication (I am not aware of a current mechanism to generate certs in Firefox)

Does this sound correct?  Are there other large things to implement that I am missing here?

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 11 • 11 years ago

(In reply to Guillaume Destuynder [:kang] (use NEEDINFO!) from comment #9)
> this looks good to me. Sorry for the delay!
> 
> juste one note for the UX, it would be valuable if its possible to have the
> public cert/key fingerprint presented on both the phone and the computer for
> the first authentication (unknown computer), so that someone who wants to
> make sure hes the one initiating the connection can(adb does that, too).
> 
> I'm mentioning it as i know a fingerprint isn't always super user friendly -
> but since it's to put the phone in "dev mode" i would assume the devs would
> find that just fine.

Yes, that's a good idea, I've added it to the doc.  Thanks!

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 12 • 11 years ago

Bug 755513 has some related historical discussion of encryption / authentication with the Dev Tools.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 13 • 11 years ago

Clearing needinfo.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 14 • 10 years ago

Honza, would you be able to respond to the questions I originally directed to Brian in comment 10?  Or alternatively, perhaps you know who to direct them to.

	Honza Bambas (:mayhemer)
	Comment 15 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #14)
> Honza, would you be able to respond to the questions I originally directed
> to Brian in comment 10?  Or alternatively, perhaps you know who to direct
> them to.

I think you may try :keeler

In one comment you suggest you want to mimic secure ADB [1].  Your suggestion from comment 10 however indicates a different solution adding between authentication also encryption of the communication, is that so?

I assume you will run a self-signed cert on the device's TLS server and an arbitrary client cert on the client (desktop browser?) side.  It means you will have to add a cert exception for the device's server cert on the client side.  Hence you will need to let both the client and the device display their fingerprints and let user accept it on each contra-sides.  If you except any server cert on the client side then you are not protected against mitm.  Can't we rather use some built-in ssh of android? (I'm no android/adb expert.)


[1] http://nelenkov.blogspot.cz/2013/02/secure-usb-debugging-in-android-422.html

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 16 • 10 years ago

(In reply to Honza Bambas (:mayhemer) from comment #15)
> (In reply to J. Ryan Stinnett [:jryans] from comment #14)
> > Honza, would you be able to respond to the questions I originally directed
> > to Brian in comment 10?  Or alternatively, perhaps you know who to direct
> > them to.
> 
> I think you may try :keeler

Great, thanks, I'll do that.

> In one comment you suggest you want to mimic secure ADB [1].  Your
> suggestion from comment 10 however indicates a different solution adding
> between authentication also encryption of the communication, is that so?

Sorry for the confusion.  But you're correct, initially I hoped to mimic secure ADB's authentication, so parts of this bug and the proposal still describe.  However, to really feel safe with this feature, encryption is likely needed as well, so that's why I brought up the questions in comment 10.

> I assume you will run a self-signed cert on the device's TLS server and an
> arbitrary client cert on the client (desktop browser?) side.

Yes, that's right, and I briefly mention that in the Encryption section of the proposal doc (linked in comment 0).  Sorry if it's hard to follow the current state, I hope to update the proposal soon once I better understand the work needed to go down the encryption path.

> It means you
> will have to add a cert exception for the device's server cert on the client
> side.  Hence you will need to let both the client and the device display
> their fingerprints and let user accept it on each contra-sides.  If you
> except any server cert on the client side then you are not protected against
> mitm.

Ah, that's a good point.  Though, in this case, the private information in on the device / server side, so I think it would be safe, as long as the user agrees on device (server) to trust the client's fingerprint.  The server talks first over the debugger protocol, so the MitM wouldn't see anything of value from the client.  If the MitM forwards the client's cert, etc. to device, then it can't decrypt messages coming back from the server.  If the MitM sends it's own new cert to device, it won't be authenticated with the device, since it would have a bad fingerprint.

It's easily possible I am missing an attack angle here...  In any case, it's a good thing to consider for further safety.

> Can't we rather use some built-in ssh of android? (I'm no android/adb
> expert.)

That's also an interesting idea...  Android / FxOS don't have SSH servers today, so I guess we could potentially add one that ships disabled, but that we can enable / configure if the user turns this feature on.  We're explicitly trying to avoid ADB here because the client is hard for us to work with from a UX perspective, and it's possible we'd have the same issues with an SSH approach, since I guess we'd have to start / stop / manage the SSH client and server.  The debugger server currently listens on a Unix domain socket, to prevent nefarious device apps from connecting to it.  So we'd need the SSH server to listen on a TCP port (only on the WiFi interface) that forwards to the Unix domain socket, maybe using netcat / socat or something.  It sounds potentially possible, so another good idea to consider.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 17 • 10 years ago

David, would you be able to respond to the questions in comment 10?  Honza suggested you may know the answers.

To summarize the context, we are considering the use of TLS to secure the debugger protocol over WiFi.  The remote device (phone) would have the TLS server with self-signed cert, and desktop Firefox would be the TLS client, using a self-signed client auth cert.

I am trying to gauge what platform work may be needed to support this through my questions in comment 10.

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews)
	Comment 18 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #10)
> If you look over the proposal (comment 0), you'll see I mention using TLS
> and self-signed client auth certs in the later "Encryption" section.
> 
> Does this seem like a reasonable strategy?

Yes, if you use TLS for the entire communication between client and server. Otherwise, it doesn't make much sense.

> Assuming it does, this is my understanding of the major pieces of work we
> would need to achieve the encryption part:
> 
> * On the remote (B2G) side, we'd need a TLS server, which does not currently
> exist in Gecko (similar to bug 242448)

This is correct.

> * When someone tries to connect over Wi-Fi for the first time using the App
> Manager in Firefox desktop, it would need to generate a self-signed cert for
> use in client authentication (I am not aware of a current mechanism to
> generate certs in Firefox)

The capability is there, but it's not exposed in a useful way (or at all).

> Does this sound correct?  Are there other large things to implement that I
> am missing here?

I think that's about it.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 19 • 10 years ago

I spent some time today testing out the current flow for client auth certs with HTTPS.  It's quite confusing in general.  I am not too surprised by this, since essentially no (public) sites make use of client auth certs today.

Firefox desktop defaults to prompting for the user to choose their client auth cert every time.  In this case where we'd be generating one for them, the user wouldn't really understand the existence of the cert at all so that would quite confusing.  At the very least, we'd need to:

* Override client auth cert handling so this "special" one we're making is accepted, since we don't want the user to think about it to start with
* Override handling of self-signed certs so that both our client and server self-signed certs are accepted

In general, it's an awkward fit for TLS certs because everything self-signed, which is not the "expected" model.  Plus, the certs expire after some time, etc.  It's not the best solution here.

I think one of the following approaches may be better:
* TLS-SRP
  * Password becomes enough for authenticating client & server
  * A previous debugger security discussion suggested this approach (bug 755513 comment 5)
  * Needs TLS-SRP support added to NSS (bug 405155)
  * No certs are needed in this case, so it's more natural for this problem
* Firefox Accounts
  * It's possible we could use this for authentication if user is signed into their account on both desktop and phone
  * Unclear to me exactly how we'd use this together with TLS
  * I'll mail the Firefox Accounts team to discuss further with them
  * This approach would (likely) mean that active Internet connection is required to reach the verification server, not just a WiFi connection between the two devices

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 20 • 10 years ago

To follow up, I mailed the Firefox Accounts team, after some discussion[1] we agreed that FxA itself doesn't make sense for this use case right now.

I've also been asked to focus on this for a bit to prototype a working implementation.  My current plan is to exchange secrets via QR code (which is neither of the options outlined above).  During the prototyping phase, I don't plan to update the proposal document for now.  I'll bring it up to speed after the prototyping phase.  Ping me if you are very curious and want more info before then. :)

[1]: https://mail.mozilla.org/pipermail/dev-fxacct/2014-April/000762.html

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 21 • 10 years ago

I have moved the design document from Google Docs to the wiki[1].  The document in comment 0 also has a note about the new location.  It will not be updated anymore.

Also, I have now (finally) updated the design to include details of the TLS, self-signed cert approach.  As I mentioned in comment 20, devices are authenticated by out-of-band info, which is where QR codes will be used.  Please check the wiki page if you want more details.

[1]: https://wiki.mozilla.org/DevTools/WiFi_Debugging/Design

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 22 • 9 years ago

All portions of the design[1] are now complete.  The feature is currently still disabled by default, but I plan to enable it soon in bug 1027454.  I'll mail / blog / etc. more news about this feature once it's enabled.

Follow up bugs should block bug 1142741.

Now seems like a fine time to do a security review of the feature.

[1]: https://wiki.mozilla.org/DevTools/WiFi_Debugging/Design

	Will Bamberg [:wbamberg]
	Comment 23 • 9 years ago

I've copied your blog post into https://developer.mozilla.org/en-US/docs/Tools/WebIDE/Setting_up_runtimes#Connecting_a_Firefox_OS_device. Please let me know if I've mangled anything.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 24 • 9 years ago

(In reply to Will Bamberg [:wbamberg] from comment #23)
> I've copied your blog post into
> https://developer.mozilla.org/en-US/docs/Tools/WebIDE/
> Setting_up_runtimes#Connecting_a_Firefox_OS_device. Please let me know if
> I've mangled anything.

Overall it looks good!

The page intro only mentions USB and 3 runtimes types, so this section should be updated.

It might be good to emphasize that "Scan and Remember" allows you skip scanning on future connections from the same computer, as my hope is that everyone will choose that option.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 25 • 9 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #24)
> (In reply to Will Bamberg [:wbamberg] from comment #23)
> > I've copied your blog post into
> > https://developer.mozilla.org/en-US/docs/Tools/WebIDE/
> > Setting_up_runtimes#Connecting_a_Firefox_OS_device. Please let me know if
> > I've mangled anything.
> 
> Overall it looks good!
> 
> The page intro only mentions USB and 3 runtimes types, so this section
> should be updated.
> 
> It might be good to emphasize that "Scan and Remember" allows you skip
> scanning on future connections from the same computer, as my hope is that
> everyone will choose that option.

We'll also likely want to update the "troubleshooting" page to address cases that arise for WiFi, since the page currently assumes USB issues.

	Will Bamberg [:wbamberg]
	Comment 26 • 9 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #25)
> (In reply to J. Ryan Stinnett [:jryans] from comment #24)
> > (In reply to Will Bamberg [:wbamberg] from comment #23)
> > > I've copied your blog post into
> > > https://developer.mozilla.org/en-US/docs/Tools/WebIDE/
> > > Setting_up_runtimes#Connecting_a_Firefox_OS_device. Please let me know if
> > > I've mangled anything.
> > 
> > Overall it looks good!
> > 
> > The page intro only mentions USB and 3 runtimes types, so this section
> > should be updated.
> > 
> > It might be good to emphasize that "Scan and Remember" allows you skip
> > scanning on future connections from the same computer, as my hope is that
> > everyone will choose that option.

Thanks, I've done these.

> We'll also likely want to update the "troubleshooting" page to address cases
> that arise for WiFi, since the page currently assumes USB issues.

I've added a section on Wi-Fi troubleshooting.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Assignee
	Comment 27 • 9 years ago

Thanks Will, it looks great!