jens/flipper
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add toggle in the settings for cert exchange medium

Browse Source 
Summary:
This diff adds a toggle setting in wilde which will enable certificate exchange through www.
Right now it just sends the information about which medium to be used for cert exchange to Flipper JS and its client side. But its implementation is not done yet.

### Flow for Wilde

Whenever user changes the setting(or when user logs out) we set the state of exchange medium and accordingly set/reset authtoken. Note at no given point we remove already existing certificates.

### Context for OSS

With this diff we introduce another way to do certificate exchange. Before this diff, we did certificate exchange by accessing the file system of app. But it turns out it's not possible to do that in applications signed by enterprise certs. Thus with this diff one can write their FlipperKitCertificateProvider and fetch the certificate from WWW.

Reviewed By: jknoxville

Differential Revision: D22896320

fbshipit-source-id: 55aef7028a62e71ba9c02f9f79acaab41d09c0c6
This commit is contained in:
Pritesh Nandgaonkar
2020-08-12 04:42:26 -07:00
committed by Facebook GitHub Bot
parent 4bb110f319
commit 293de19c2b
16 changed files with 215 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/extending/establishing-a-connection.mdx
View File

@@ -25,9 +25,12 @@ This is achieved through the following steps:
* Desktop app starts an insecure server on port 8089.
* Mobile app connects to localhost:8089 and sends a Certificate Signing Request to the desktop app.
* Desktop app uses it's private key (this is generated once and stored in ~/.flipper) to sign a client certificate for the mobile app.
* The desktop uses ADB (for Android), or the mounted file system (for iOS simulators) to write the following files to the mobile app's private data partition
* Along with the Certificate Signing Request, mobile app also lets the desktop app know which certificate exchange medium to use.
* If the chosen Certificate Exchange Medium is FS_ACCESS, the desktop uses ADB (for Android), or the mounted file system (for iOS simulators) to write the following files to the mobile app's private data partition
* Server certificate that the mobile app can now trust.
* Client certificate for the mobile app to use going forward.
* If the chosen Certificate Exchange Medium is WWW, the desktop app will use your implementation of Certificate Uploader to upload the certificates.
* Once uploaded the desktop app will reply back with the device id, which can be used by Certificate Provider on the client side to fetch those certificates.
* Now the mobile app knows which server certificate it can trust, and can connect to the secure server.
This allows the mobile app to trust a certificate if and only if, it is stored inside its internal data partition. Typically it's only possible to write there with physical access to the device (i.e. through ADB or a mounted simulator).
@@ -42,6 +45,7 @@ localhost:8089/sonar?os={OS}
&device={DEVICE}
&app={APP}
&sdk_version={SDK_VERSION}
&medium={CERTIFICATE_EXCHANGE_MEDIUM}
```
On that connection, send the following payload:
@@ -49,15 +53,20 @@ On that connection, send the following payload:
Request = {
"method": "signCertificate",
"csr": string,
"destination": string
"destination": string,
"medium": int
}
```
Where `csr` is a Certificate Signing Request the client has generated, and `destination` identifies a location accessible to both the client and Flipper desktop, where the certificate should be placed.
The Subject Common Name (CN=...) must be included in the CSR, and your `CertificateProvider` implementation in Flipper may use this in combination with the `destination` to determine where to put the certificate.
The Subject Common Name (CN=...) must be included in the CSR, and your `CertificateProvider` implementation in Flipper may use this in combination with the `destination` to determine where to put the certificate.
This will ask Flipper desktop to generate a client certificate, using the CSR provided, and put it into the specified `destination`.
Depending on the client, `destination` can have a different meaning. A basic example would be a file path, that both the desktop and the client have access to. With this Flipper desktop could write the certificate to that path. A more involved example is that of the Android Client, where destination specifies a relative path inside an app container. And the Subject Common Name determines which app container. Together these two pieces of information form an absolute file path inside an android device.
For Flipper desktop to work with a given Client type, it needs to be modified to know how to correctly interpret the `destination` argument, and deploy certificates to it. You can see the current implementations in [CertificateProvider.tsx](https://github.com/facebook/flipper/blob/master/desktop/app/src/utils/CertificateProvider.tsx).
For Flipper desktop to work with a given Client type, it needs to be modified to know how to correctly interpret the `destination` argument, and deploy certificates to it.
`destination` field may not be relevant if your `medium` value is more than 1. `medium=1`(default) means Flipper should do certificate exchange by directly putting certificates at `destination` in the sandbox of the app. `medium=2` means Flipper will use Certificate Uploader and Provider to upload certificates and download it on the client side respectively.
You can see the current implementations in [CertificateProvider.tsx](https://github.com/facebook/flipper/blob/master/desktop/app/src/utils/CertificateProvider.tsx).