4 ms·

Related: does anyone know why the Signal-Server code allows for toggling request logging? [0] If this allows for logging raw HTTP(S) requests server-side, presu

Related: does anyone know why the Signal-Server code allows for toggling request logging? [0] If this allows for logging raw HTTP(S) requests server-side, presumably this could be grabbing the passwords generated and held on each device used for authentication [1]? There's also no mention of TLS termination in the Signal-Server repository on GitHub, or TLS between the Redis cluster in use. If FBI or NSA has compromised the AWS VPC, then all of this network traffic would be in the clear to be picked up behind the load balancer(s). The Account DynamoDB table [2] also seems to indicate more information is tied to the phone number in cleartext than what is indicated by the response? [0]: https://github.com/signalapp/Signal-Server/blob/14f5271c20128d9f222c86af55a55a08094cd282/service/src/main/java/org/whispersystems/textsecuregcm/workers/SetRequestLoggingEnabledTask.java https://github.com/signalapp/Signal-Server/blob/14f5271c2012... [1]: https://github.com/signalapp/Signal-Server/blob/14f5271c20128d9f222c86af55a55a08094cd282/service/src/main/java/org/whispersystems/textsecuregcm/auth/BaseAccountAuthenticator.java https://github.com/signalapp/Signal-Server/blob/14f5271c2012... [2]: https://github.com/signalapp/Signal-Server/blob/14f5271c20128d9f222c86af55a55a08094cd282/service/src/main/java/org/whispersystems/textsecuregcm/storage/Account.java https://github.com/signalapp/Signal-Server/blob/14f5271c2012...

ViViDboarder 5y ago
The HTTP request does not have the users private keys. That never leaves your phone. The DB table looks like signal creates UUIDs to represent users and devices. This isn’t really sensitive information but really just how you can see and revoke devices associated with your account. Maybe I’m misreading something tough. Do you have any reason to believe otherwise?
- thrownoverboard 5y ago
  Agreed that network compromise on the surface isn't a huge concern because of the Signal protocol itself. However, if the password (generated on each linked device) used for authentication is compromised, presumably it could be used to generate different keys altogether for an account. If the device password is compromised, then it seems feasible (but difficult) for some sort of attack be to be pulled off that could eventually lead to the compromise of messaging itself, or adding of another (shadow) linked device. The subpoena explicitly asks for: >Online Behaviors: Including device data, site interactions, and cookies if available >Activity Log: Including logs of click-stream data if available I would think device data would include things such as the number of devices associated with the phone number, which appear to be stored in the clear in the table, regardless of whether or not it is sensitive. Looking at the Device DynamoDB table, which is linked to the phone number, you'd also have things like the associated auth token + salt, GCM / APN IDs, public prekeys, etc. AWS DynamoDB is potentially going to have request logs for these requests as well, using the UUIDs, to associate finer-grained access timestamps. That may be useful for this case. It seems odd not to be using TLS within the VPC and storing these seemingly insensitive values encrypted within DynamoDB / SQS / etc. Doing so would ensure that compromise of the hosting provider is irrelevant. Why not terminate TLS on the Signal server itself, behind the load balancer? Why not use TLS for communications between the Signal server and the Redis cluster it uses? Why not encrypt phone numbers before storing them in DynamoDB?

ViViDboarder 5y ago

The HTTP request does not have the users private keys. That never leaves your phone. The DB table looks like signal creates UUIDs to represent users and devices. This isn’t really sensitive information but really just how you can see and revoke devices associated with your account. Maybe I’m misreading something tough. Do you have any reason to believe otherwise?

thrownoverboard 5y ago
Agreed that network compromise on the surface isn't a huge concern because of the Signal protocol itself. However, if the password (generated on each linked device) used for authentication is compromised, presumably it could be used to generate different keys altogether for an account. If the device password is compromised, then it seems feasible (but difficult) for some sort of attack be to be pulled off that could eventually lead to the compromise of messaging itself, or adding of another (shadow) linked device. The subpoena explicitly asks for: >Online Behaviors: Including device data, site interactions, and cookies if available >Activity Log: Including logs of click-stream data if available I would think device data would include things such as the number of devices associated with the phone number, which appear to be stored in the clear in the table, regardless of whether or not it is sensitive. Looking at the Device DynamoDB table, which is linked to the phone number, you'd also have things like the associated auth token + salt, GCM / APN IDs, public prekeys, etc. AWS DynamoDB is potentially going to have request logs for these requests as well, using the UUIDs, to associate finer-grained access timestamps. That may be useful for this case. It seems odd not to be using TLS within the VPC and storing these seemingly insensitive values encrypted within DynamoDB / SQS / etc. Doing so would ensure that compromise of the hosting provider is irrelevant. Why not terminate TLS on the Signal server itself, behind the load balancer? Why not use TLS for communications between the Signal server and the Redis cluster it uses? Why not encrypt phone numbers before storing them in DynamoDB?