DevTools/WiFi Debugging/Design: Difference between revisions

Jump to navigation Jump to search

DevTools/WiFi Debugging/Design (view source)

Revision as of 22:26, 9 July 2014

653 bytes removed ,  9 July 2014
no edit summary
No edit summary
No edit summary
Line 29: Line 29:
# Device announces itself via service discovery
# Device announces itself via service discovery
#* Announcements only go to the local LAN / same subnet
#* 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.
The Device remains listening as long as the feature is enabled.
Line 36: Line 37:


# Computer detects Device as available for connection via service discovery
# Computer detects Device as available for connection via service discovery
# User presses "Connect to device Foo" on computer
# User choose device to start connection on Computer
# Initial connection established, authentication begins
# TLS connection established, authentication begins
# Device sends a random number to Computer
# Device sees that ComputerCert is from a unknown client (since it is new)
# Computer signs the number using its private key, sends to Device
# Device waits for out-of-band data
# Since the Computer is new, Device will fail to verify the signature
# Computer verifies that Device's cert matches hash(DeviceCert) from the advertisement
# Computer presents it public key to the Device
# Computer creates hash(ComputerCert) + K(random 128-bit number)
# Computer displays hash of public key for visual verification during step 9
# Out-of-band channel is used to move result of step 7 from Computer to Device
# User is shown a Allow / Deny / Always Allow prompt on the Device with Computer name and hash of the public key
#* 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
# Device verifies that Computer's cert matches hash(ComputerCert) from out-of-band channel
# User is shown a 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 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 Allow is chosen, the connection proceeds, but nothing is stored for the future
#* If Always Allow is chosen, the connection proceeds, and the Computer’s public key is saved for future attempts
#* If Always Allow is chosen, the connection proceeds, and hash(ComputerCert) is saved for future attempts
# Device sends K to Computer over the TLS connection
# Computer verifies received value matches K
# Debugging begins


=== Using Wi-Fi Debugging (known computer) ===
=== Using Wi-Fi Debugging (known computer) ===
Line 52: Line 59:


# Computer detects Device as available for connection via service discovery
# Computer detects Device as available for connection via service discovery
# User presses "Connect to device Foo" on computer
# User choose device to start connection on Computer
# Initial connection established, authentication begins
# TLS connection established, authentication begins
# Device sends a random number to Computer
# Device sees that ComputerCert is from a known client via hash(ComputerCert)
# Computer signs the number using its private key, sends to Device
# Debugging begins
# Since the Computer is known, Device can verify signature using matching public key
# Connection proceeds


=== Other Details ===
=== Other Details ===
Line 68: Line 73:


=== Possible Attacks ===
=== Possible Attacks ===
Someone could try to DoS the phone via many connection attempts. The exponential backoff should mitigate this concern.
Someone could try to DoS the phone via many connection attempts. The exponential backoff should mitigate this concern. ([https://bugzilla.mozilla.org/show_bug.cgi?id=1022692 bug 1022692])
 
All of the data is unencrypted, so it can be overheard in transit. The main cases I can think of where potentially private data would go over the wire is the Network tab's view of request data, but there may be other concerns depending on the apps being debugged. Even then, I don't know that this is a large concern, assuming we loudly announce this case when enabling Wi-Fi debugging.
 
=== Encryption ===
(Note: This section is in flux and still being discussed. See also the Security section in the overview.)
 
This proposal could be strengthened against overhearing data by using TLS to encrypt the data in transit. If that decision is made, it seems logical to the replace the RSA key exchange for authentication with a self-signed client auth certificate, so that TLS would then handle both the authentication and encryption. In slightly more detail:
 
* The listening socket on the Device would only accept TLS connections
* User would approve a hash of a new client auth certificate on first connection


=== Comparison to ADB ===
=== Comparison to ADB ===
This proposal (at least in unencrypted form) is quite similar to secure debugging with ADB. In fact it would be nice to just use this ADB feature, but that doesn’t seem viable because:
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
* ADB comes with a lot of setup / troubleshooting pain
Jryans
Confirmed users
177

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/995901"

Navigation menu