test shared-tetant-fes for android app

[martgil]

          Fixed shared-tenant-fes. Would be good to test:

• client configuration retrieval
  • (consumer) flowcrypt.com - doesn't use shared tenant - gets from fes.flowcrypt.com without checking shared-tenant
  • (consumer) gmail.com - gets client configuration without ever checking fes.gmail.com
  • (consumer) test.flowcrypt.com - tries fes.test.flowcrypt.com but ends up getting empty config from shared-tenant-fes. Check through browser network tab.
  • (enterprise) flowcrypt.com - doesn't use shared tenant - gets from fes.flowcrypt.com without checking shared-tenant
  • (consumer) gmail.com - I suppose this should show an error during setup?
  • (consumer) test.flowcrypt.com - tries fes.test.flowcrypt.com, no FES running there, shows error
• send message through web portal
  • (either build) flowcrypt.com uses fes.flowcrypt.com and works. Can also reply from the web portal
  • (either build) gmail.com uses flowcrypt.com/shared-tenant-fes and works. Can also reply from the web portal

Originally posted by @tomholub in FlowCrypt/flowcrypt-browser#4919 (comment)

[martgil]

client configuration retrieval (android):

what to test	working as described	comments
(consumer) flowcrypt.com - doesn't use shared tenant - gets from fes.flowcrypt.com without checking shared-tenant	yes	(retested and working as described)
(consumer) gmail.com - gets client configuration without ever checking fes.gmail.com	yes	(retested and working as described)
(consumer) test.flowcrypt.com - tries fes.test.flowcrypt.com but ends up getting an empty config from shared-tenant-fes. Check through browser network tab.	yes	(retested and working as described) returned config: {"clientConfiguration":{"flags":[]}}
(enterprise) flowcrypt.com - doesn't use shared tenant - gets from fes.flowcrypt.com without checking shared-tenant	yes	(retested and working as described) shared-tenant-fes endpoint was never called:
(enterprise) gmail.com - (enterprise) gmail.com - allow to proceed with setup by never checking fes.gmail.com, and getting an empty client configuration from shared-tenant-fes	yes	(retested - working as described via #2171 (comment)) a warning is shown that FlowCrypt enterprise is not usable for gmail.com user
(enterprise) test.flowcrypt.com - tries fes.test.flowcrypt.com, no FES running there, shows error	yes	a connection error occur:

send message through web portal:

what to test	working as described	comments
flowcrypt.com uses fes.flowcrypt.com and works. Can also reply from the web portal	yes	(retested - working as described)
(either build) gmail.com uses flowcrypt.com/shared-tenant-fes and works. Can also reply from the web portal	no	feature not yet implemented for regular users - #2177

[tomholub]

Thank you, I will have to think about this and write steps for Den to possibly address this, after current milestone is released, and before that PR is merged.

[tomholub]

• (enterprise) gmail.com - I suppose this should show an error during setup? - let's just document this for now, it's a bit of a special case since fes.gmail.com won't ever exist. Maybe it's not entirely wrong. Let's document what happens across the three clients, and then decide how to unify it after. Doesn't have to be addressed before the PR is merged.

• (enterprise) test.flowcrypt.com - tries fes.test.flowcrypt.com, no FES running there, shows error - this one the current behavior is definitely wrong. This is the whole point of the enterprise release - it should not automatically switch to shared-tenant-fes if fes.domain.com is missing. It can only switch to shared-tenant-fes if fes.domain.com returns a 404

[tomholub]

(consumer) test.flowcrypt.com - tries fes.test.flowcrypt.com but ends up getting an empty config from shared-tenant-fes. Check through browser network tab.

Please give me the complete details of the full URL, and what was received back, on these three API calls. I'd like to double check it.

[martgil]

(consumer) test.flowcrypt.com - tries fes.test.flowcrypt.com but ends up getting an empty config from shared-tenant-fes. Check through browser network tab.

Please give me the complete details of the full URL, and what was received back, on these three API calls. I'd like to double check it.

(overview) first, the android app looks on fes at fes.test.flowcrypt.com -> gets redirected to flowcrypt.com (this part depends on the server config - it can result to 404 most often) -> retrieve client configuration from https://flowcrypt.com:443/shared-tenant-fes/api/v1/client-configuration?domain=test.flowcrypt.com and returns an empty client configuration.

see screenshots:

1.)

2.)

3.)

[tomholub]

⚠️ ⚠️ ⚠️ this is a security vulnerability

See

$ curl https://fes.test.flowcrypt.com/api/
curl: (60) SSL: no alternative certificate subject name matches target host name 'fes.test.flowcrypt.com'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

https://fes.test.flowcrypt.com/api/ has a badly configured SSL and the redirect should NOT be followed

Nothing coming from any domain that has badly configured SSL should ever by used whatsoever, including redirects.

[tomholub]

@martgil this should have occurred to you when testing this, no? It was right under your nose. The app must not follow redirects coming from an insecure connection.

[tomholub]

Now I worry that this problem is present throughout the app. If it happened here, the same thing will probably happen when calling all other APIs, Gmail API, WKD and so on, and this all needs to be tested thoroughly. @martgil check similar situation on other APIs on master, see if this also happens.

[tomholub]

Unless that's a property of your testing mechanism. Are you able to test the difference?

[martgil]

@martgil this should have occurred to you when testing this, no? It was right under your nose. The app must not follow redirects coming from an insecure connection.

@tomholub we have received a report prior to this a couple of months ago -- and back then we don't consider it to be an issue at least that time.

subject: Vulnerability report - 3161

I have also given an emphasis to investigating on the said report after we decided not to accept it - (the GitHub issue wasn't closed either) https://github.com/FlowCrypt/flowcrypt-security/issues/233

@martgil this should have occurred to you when testing this, no? It was right under your nose. The app must not follow redirects coming from an insecure connection.

That is true - however, when using burpsuite - A cert from burpsuite tool is installed from our browser/android device to decrypt the encrypted HTTP data.

Unless that's a property of your testing mechanism. Are you able to test the difference?

The behavior you get from curl is the ideal one and so for web browser. the only difference is that I have to use a cert from the burp suite tool which would not cause the SSL error - that is.

I include all the significant info on https://github.com/FlowCrypt/flowcrypt-security/issues/233 back then.

[tomholub]

That's a completely different report.

The report you linked was about a misconfigured SSL domain, which really doesn't matter, if it's unused. It's a report about the server side.

My issue I'm raising here is that the app appears to follow redirects received from domains with misconfigured SSL which is a problem if true. It's a potential problem with the Android app.

Don't confuse the two.

The behavior you get from curl is the ideal one and so for web browser. the only difference is that I have to use a cert from the burp suite tool which would not cause the SSL error - that is.

Can you confirm that the problematic behavior is not present in the stock Android app without the burp suite?

[martgil]

Can you confirm that the problematic behavior is not present in the stock Android app without the burp suite?

Yes. Here is the actual request for a stock android app. It is the exact one used to call by the FlowCrypt android app.

And it is the standard behavior for example visiting fes.test.flowcrypt.com with chrome on android (stock):

Then the app calls the shared-tenant-fes endpoint to retrieve the client configuration.

[tomholub]

ok. is it possible to update burp suite to follow that behaviour as well? to be more realistic