Investigate mitigation against reply exfiltration of data

[eloquence]

An attacker who manages to gain control of the sd-app VM (or exclusively of the client application within it) could attempt to create a new source via the news organization's source interface, and then submit decrypted messages or files as replies to that source. Given a client exploit, the attacker may be able to conceal this process entirely. Let's consider mitigation options, keeping in mind that:

• A throttling or detection algorithm implemented to mitigate against reply exfiltration could be inspected by an attacker, and the attack could be performed in a manner designed to avoid detection.

• Further separation of display vs. reply operations may mitigate against this, but could incur significant UX complexity and performance penalties.

[emkll]

The reply exfiltration could be possible for both sd-app and sd-proxy VMs, with sd-app having access to significantly more information.

To mitigate against reply-based exfiltration in sd-app, one idea that comes to mind is to use sd-proxy. A popup from that vm stating "Are you sure you want to send a reply to $SOURCE?" message, with the ability to cancel. This would introduce complexity in sd-proxy, but would be at the proxy<->client level, perhaps returning a specific HTTP code in the rejected case. (replies are encrypted by GPG from the client, so we cannot inspect replies in proxy)

To mitigate against reply-based exfiltration in sd-proxy, we could sign the replies in the client with the submission key, and have the server reject any reply that does not have a valid GPG signature.

To guard against compromise of both VMs, heuristics or further separation should be considered.

[eloquence]

Update from 2022-08-11 review with @tina-ux @nathandyer @l3th3 @eloquence:

• Still relevant for future discussion/investigation, keeping open.

[zenmonkeykstop]

Planned changes to RiiRed proxyv3 could render the sd-proxy exfil route moot. We still need a plan for sd-app.

[legoktm]

To expand, the (theoretical) proxy v3 plan is that instead of a custom HTTP-over-qrexec protocol, we just talk TCP to the proxy. Currently the proxy has access to the login session token and can read all HTTP requests in the clear, which means it can also send its own, authenticated requests. If we want to guard against that we could have some sort of setup where sd-app creates a TLS-encrypted request, passes it through the proxy (which can't decrypt it) and then received by the server. Note that most SDs don't have TLS (and TLS for onion services is annoyingly hard) and onion service authentication is with its own key.

I'm also not yet sold that this is an attack we need to defend against.