Summary
Before Cryptomator connects to unknown URLs (i.e. when unlocking a Hub vault), users have to review and trust these URLs. Currently, such URLs are trusted independently. This means once trusted, these URLs can be mixed (i.e. in a Hub vault config). To increase security, we should extend the trust concept to sets of URLs. If two already-trusted URLs belong to two different sets, they are not trusted in combination.
This is the Android counterpart of cryptomator/cryptomator#4309.
Motivation
The Hub vault config contains two endpoints: authEndpoint and apiBaseUrl. Cryptomator follows the TOFU principle to trust these URLs.
The app-internal trust check (HubHostTrustValidator) validates both against a flat, app-wide trusted-hosts set (trustedHubAuthorities) independently, without confirming that they belong to the same trusted Hub instance. This means a vault config is still accepted when it is edited such that authEndpoint/tokenEndpoint point to an already-trusted Hub host A, but apiBaseUrl points to a different, also already-trusted host B.
Such edits should be made visible to the user, and trust should be requested again for that specific combination.
Considered Alternatives
No response
Anything else?
This affects the stored shape of trustedHubAuthorities, the trust prompt, and the "Trusted Hub Hosts" settings screen. We also have to decide what happens to entries that users already trusted.
This issue was found by Aakarshit Bargotra and they responsibly disclosed it to us.
Note that this is not a vulnerability, because the TOFU principle still holds: Both URLs have to be trusted.
Summary
Before Cryptomator connects to unknown URLs (i.e. when unlocking a Hub vault), users have to review and trust these URLs. Currently, such URLs are trusted independently. This means once trusted, these URLs can be mixed (i.e. in a Hub vault config). To increase security, we should extend the trust concept to sets of URLs. If two already-trusted URLs belong to two different sets, they are not trusted in combination.
This is the Android counterpart of cryptomator/cryptomator#4309.
Motivation
The Hub vault config contains two endpoints:
authEndpointandapiBaseUrl. Cryptomator follows the TOFU principle to trust these URLs.The app-internal trust check (
HubHostTrustValidator) validates both against a flat, app-wide trusted-hosts set (trustedHubAuthorities) independently, without confirming that they belong to the same trusted Hub instance. This means a vault config is still accepted when it is edited such thatauthEndpoint/tokenEndpointpoint to an already-trusted Hub host A, butapiBaseUrlpoints to a different, also already-trusted host B.Such edits should be made visible to the user, and trust should be requested again for that specific combination.
Considered Alternatives
No response
Anything else?
This affects the stored shape of
trustedHubAuthorities, the trust prompt, and the "Trusted Hub Hosts" settings screen. We also have to decide what happens to entries that users already trusted.This issue was found by Aakarshit Bargotra and they responsibly disclosed it to us.
Note that this is not a vulnerability, because the TOFU principle still holds: Both URLs have to be trusted.