1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Overview
--------
### Remote Debugging Today
Connecting to the Dev Tools debugging server on a remote device (like
B2G) via USB (which requires ADB) is too complex to setup and use.
Dealing with ADB is confusing, especially on Windows and Linux where
there are driver issues / udev rules to set up first. We have made
various attempts to simplify this and probably will continue to try our
best, but it doesn't seem like the UX will ever be great with ADB
involved.
### Wi-Fi
We're interested in making the debugging server available over Wi-Fi,
mainly in an attempt to simplify the UX. This of course presents new
security challenges to address, but we must also keep in mind that **if
our plan to address security results in a complex UX, then it may not be
a net gain over the USB & ADB route**.
To be clear, we are not trying to expose ADB over Wi-Fi at all, only the
Dev Tools debugging server.
### Security
TLS is used to provide encryption of the data in transit. Both parties
use self-signed certs to identify themselves. There is a one-time setup
process to authenticate a new device. This is explained in many more
details later on in this document.
Definitions
-----------
- **Device / Server**: Firefox OS phone (or Fennec, remote Firefox,
etc.)
- **Computer / Client**: Machine running desktop Firefox w/ WebIDE
Proposal
--------
This proposal uses TLS with self-signed certs to allow Clients to
connect to Servers through an encrypted, authenticated channel. After the
first connection from a new Client, the Client is saved on the Server
(if the user wants to always allow) and can connect freely in the future
(assuming Wi-Fi debugging is still enabled).
### Default State
The device does not listen over Wi-Fi at all by default.
### Part A: Enabling Wi-Fi Debugging
1. User goes to Developer menu on Device
2. User checks "DevTools over Wi-Fi" to enable the feature
- Persistent notification displayed in notification bar reminding
user that this is enabled
3. Device begins listening on random TCP socket via Wi-Fi only
4. Device announces itself via service discovery
- Announcements only go to the local LAN / same subnet
- The announcement contains hash(DeviceCert) as additional data
The Device remains listening as long as the feature is enabled.
### Part B: Using Wi-Fi Debugging (new computer)
Here are the details of connecting from a new computer to the device:
1. Computer detects Device as available for connection via service
discovery
2. User chooses device to start connection on Computer
3. TLS connection established, authentication begins
4. Device sees that ComputerCert is from an unknown client (since it is
new)
5. User is shown an Allow / Deny / Always Allow prompt on the Device
with Computer name and hash(ComputerCert)
- If Deny is chosen, the connection is terminated and exponential
backoff begins (larger with each successive Deny)
- If Allow is chosen, the connection proceeds, but nothing is
stored for the future
- If Always Allow is chosen, the connection proceeds, and
hash(ComputerCert) is saved for future attempts
6. Device waits for out-of-band data
7. Computer verifies that Device's cert matches hash(DeviceCert) from
the advertisement
8. Computer creates hash(ComputerCert) and K(random 128-bit number)
9. Out-of-band channel is used to move result of step 8 from Computer
to Device
- For Firefox Desktop -\> Firefox OS, Desktop will make a QR code,
and FxOS will scan it
- For non-mobile servers, some other approach is likely needed,
perhaps a short code form for the user to transfer
10. Device verifies that Computer's cert matches hash(ComputerCert) from
out-of-band channel
11. Device sends K to Computer over the TLS connection
12. Computer verifies received value matches K
13. Debugging begins
### Part C: Using Wi-Fi Debugging (known computer)
Here are the details of connecting from a known computer (saved via
Always Allow) to the device:
1. Computer detects Device as available for connection via service
discovery
2. User choose device to start connection on Computer
3. TLS connection established, authentication begins
4. Device sees that ComputerCert is from a known client via
hash(ComputerCert)
5. Debugging begins
### Other Details
- When there is a socket listening for connections, they will only be
accepted via Wi-Fi
- The socket will only listen on the external, Wi-Fi interface
- This is to ensure local apps can't connect to the socket
- Socket remains listening as long as the feature is enabled
### UX
This design seems convenient and of relatively low burden on the user.
If they choose to save the Computer for future connections, it becomes a
one click connection from Computer to Device, as it is over USB today.
### Possible Attacks
Someone could try to DoS the phone via many connection attempts. The
exponential backoff should mitigate this concern. ([bug
1022692](https://bugzilla.mozilla.org/show_bug.cgi?id=1022692))
### Comparison to ADB
While it would be nice if we could instead leverage ADB here, that
doesn’t seem viable because:
- ADB comes with a lot of setup / troubleshooting pain
- Users don’t understand it or why it is needed for us
- Each OS has several UX issues with ADB that make it annoying to
use
- ADB has a much larger attack surface area, simply because it has
many more lower level functions than the Developer Tools protocol we
are exposing here
Acknowledgments
---------------
- J. Ryan Stinnett started this project from the DevTools team
- Brian Warner created many of the specific details of the authentication
protocol
- Trevor Perrin helped vet the authentication protocol
|
