The cwa-server uses encrypted connections for external and internal communication. The main configuration for the external communication channel can be found here (see section server). The current settings will only allow TLS version 1.2 and 1.3. The offered ciphers are chosen in accordance to the recommendations in BSI-TR-02102-2.
Internal communication is configured for instance in the feign client.
Database connections are established via TLS and are enabled for mutual authentication, see here.
The TLS configuration previously described can be changed to enable certain test scenarios. It is important to realize that this degradation of security is only possible by setting a Spring profile, while the default behavior will always use the most secure configuration. To prevent misconfiguration in production, multiple controls are implemented. This includes among others configuration-as-code deployments, explicit log messages for unsafe configurations and monitoring of deployed configurations. The relevant profiles are:
| Profile | Description |
|---|---|
disable-ssl-client-postgres |
Disables SSL with a trusted certificate for the connection to the postgres database. |
Apart from those configuration options, the debug profile will never be used in production to prevent leakage of data for security and privacy concerns reasons.
Fake (or "dummy") requests are sent by the mobile devices in randomized intervals. These requests do not trigger any server-side processing or storage and simply result in an HTTP response after an dynamically calculated delay. The fake requests are intended to prevent an attacker from using network and traffic analysis to find out whether a user was actually tested positive and is now submitting his keys.
The implementation details on fake request handling can be found here FakeRequestController.
The mobile apps are collecting keys based on their install date. When a user uploads his keys (after being tested positive), the payload will normally contain 1-13 keys. Although the traffic between mobile & server is secured, an attacker may still sniff the packages in the network and predict, based on the request size, how many keys are probably part of the submission request. This could lead to additional information for the attacker in an attempt to deanonymize a user.
In order to mitigate this kind of information leakage, the submission payload contains padding. The padding hides the true size of the request - making it difficult for an adversary to extract knowledge.
The Padding is specified in the corresponding Protocol.
The Submission Service ensures that padded Payloads do not exceed the maximum request size. Implementation details can be found here