Cwa-app-android: [BSI][0.5.4-alpha] No Pinning

[BSI-TF-CWA]

Rating: Medium

Description:
Certificate or public key pinning is when an app communicates with entites with specific TLS Certificates/Public Key. Any other communication is denied by the app, even if the TLS Certificate is signed by a trusted CA. This provides extra protection against Man in the Middle (MitM) attacks.

Android app does not implement this secure measure, and this increases the possibility of a MitM attack.

[uschindler]

When doing this, there's the risk that an app can't talk to the infrastructure anymore because of some hot replacement of certificates (security breach). Doing this would require to ship an update to all users, which overweighs the security issues described here.
As alternative, it might be better to do pinning on the intermediate certs, so the certificates can be replaced as long as they have same chain.

[veehaitch]

Certificate pinning is a security best practice which the apps should implement. The concern raised by @uschindler is usually mitigated by a backup pin.

[uschindler]

I was just mentioning this because many banks regularly have exactly that issue, causing trouble with non working apps. As Google Play store updates take a while to roll out to every user, this can keep some users with non working apps for longer time.

[mohe2015]

The idea in some other issue was to show a warning to the user and not prevent the app completely from working as a mitm may be forced somewhere anyways (usually in corporate environments).

[Giszmo]

If the app keeps true to its current documented design, the communication to the server is not too critical. The MITM could basically only spy on data that is public anyway. Or not?

[mh-]

If the app keeps true to its current documented design, the communication to the server is not too critical. The MITM could basically only spy on data that is public anyway. Or not?

If users upload Diagnosis Keys, they want them to be published, but without revealing the users' identities.

[mohe2015]

I think the problem may be that the user identity could be revealed as a company or so probably knows which ip address belongs to which worker. So I personally would prefer pinning with opt-out but it may be too much work for the MVP (Minimum Viable Product) or hard to understand for an average person.

[uschindler]

Hi,
I fully agree with the pinning: To me pinning the public key seems the best solution. Nevertheless, I think T-Systems should have a backup private key available somewhere (not used for any certificates yet, just stored at a secure place) and the hash of its public key should be shipped with the app.

In case of a security incident, T-Systems can create new certificates with the backup key and they would be accepeted by app from beginning.

This is also recommended (and recently required) by the related HPKP standards, although we don't use HPKP here (the public key hash is delivered with app).

@mohe2015 I don't think that it should be allowed to disable pinning for end-user. If some cooperate environment does Great-Chinese-Firewall-like certificate misuse, the app should not communicate with T-Systems servers. At some point the person will switch back to mobile networks and the synchronization can be started again.

[uschindler]

P.S.: I already answered to this request because of @BSI-TF-CWA 's comment: "Certificate or public key pinning" - certificate pinning is a bad idea, public key pinning is fine (if you have a backup key pair, with the backup's public key published with the app) - that was my main issue. Anyways, it was a good discussion here!

[jakobmoellersap]

Maybe a little update from dev perspective here: Pinning of Public Key of the Intermediate is planned, however I am not sure if a backup pin will be immediately available during the first release.

[jakobmoellersap]

Pinning is implemented and caught accordingly if the process fails during SSL Handshake with a custom Error Message. No Backup Pin is included currently, but this might be updated later on. Thanks to everyone for your helpful discussions and help on this issue. If any other concern regarding the specifics arise, please open another issue.