- 1 Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]
- 2 Any security threats already considered in the design and why?
- 3 Threat Brainstorming (30-40 minutes)
- 4 Conclusions / Action Items (10-20 minutes)
Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]
SimplePush Server is a go based implementation of the SimplePush protocol. In order to provide greater scale, several corners were cut with the agreement of the Client side engineers.
SimplePush Server stores no user data, has limited utility as a hacking or griefing vector, and makes such hacks/griefs very difficult.
The system operates by a client connecting via websocket to the proxy server and identifying itself with a GUID4 UserAgentID, unique to the device. The server accepts the connection, and replies back with any GUID4 channels that have received notifications since the last time the client had connected.
A client can request a new Entrypoint for a third party server that's associated with a GUID4 channelid. The Entrypoint consists of the UAID and the ChannelID (optionally hashed via simple AES key to prevent disclosure of UAID) which the third party PUTS on an event of interest to the remote app. The client portion of SimplePush is not part of this security review, however I am happy to discuss how that portion works. If the client is actively connected to the proxy server, the client receives a notification event, otherwise the data is stored for up to 3 days pending device connection.
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
In short, it's easy for mobile devices to connect to servers, it's harder for servers to connect to mobile phones. SimplePush attempts to solve that by providing a connection proxy to relay an event notification back to the mobile client. This solution also reduces battery demand by limiting the number of polling processes, and when available, providing the ability to allow proprietary out-of-band Wake Up pings to the remote device.
What solutions/approaches were considered other than the proposed solution?
XMPP, Thialfi, Google Cloud Messaging
Why was this solution chosen?
Less data than XMPP, simpler for end users and developers than Thialfi, not reliant on restricted, proprietary network.
Any security threats already considered in the design and why?
- Actual data exchange is considered out-of-band for this protocol.
- A successful attack on the system would merely wake the remote app.
- In addition to obscuring the UserAgent (and ownership), the AES hashing further complicates attempts to attack the system.