Issue D. A Receiver Can Suppress File Encryption With No Warning to Others

[fpietrosanti]

No description provided.

[fpietrosanti]

• By default, GlobaLeaks should refuse Tips unless the files will be encrypted, only accepting unencrypted submissions after the Node administrator explicitly opts-in to receiving plaintext files.

• Whistleblowers should be warned before uploading files that will not be encrypted.

• Warn the node administrator that some receivers do not have public keys configured, or make the existing warnings more prominent.

• Warn other receivers when the file has been encrypted to them but is in plaintext for another receiver

[evilaliv3]

@defuse @zooko:

we are going to add a boolean configuration flag to "enable unsecure operations". if this flag will be disabled (default) on all conditions where encryption and other secure operations won't be available, the system will prevent to do fallbacks on insecure ones.

example:
flag off, no PGP availablle: file marked unavailable
flag on, no PGP available: file stored in plaintext

additional warnings will be also added to make users aware of the various conditions.

[fpietrosanti]

I would not call the configuration "unsecure" but "unencrypted" because a system can be secure, in it's own threat model, also without encryption

[evilaliv3]

i was thinking to the word unsecure due to the fact that i intend to use same flag for all the conditions where secure operations are not available, but ok for the moment we can use "enable unencrypted operations"

[nathan-at-least]

I like the approach of this setting, and making the default provide more protection.

When @evilaliv3 proposes that "flag off, no PGP availablle: file marked unavailable", does this mean file uploads are disabled and prevented? In general, I propose disallowing operations rather than merely warning against certain operations, since many users ignore warnings.

I'd agree with @fpietrosanti that a more specific term besides "secure" is advisable.

The term "secure" is quite overloaded: If I "disable security" does that mean "do not use hidden services"? Does it mean "do not use HTTPS"? Does it mean "turn off DOS protections"? etc...

OTOH, it sounds like @evilaliv3 wants to have a bundle of features which are enabled with a single setting. In that case, I recommend a name like "standard_protections" with a default of True / on. In addition, the default config file comments and documentation should have a clear list of features which define the "standard_protections", along these lines:

The "standard_protections" flag, when On (the default) enables these protection features:

* Disallow submissions to receivers who have not configured their PGP key.
* Refuse connections detected from ``tor2web`` and ``onion.to``
* ...

(These are just examples and not literally part of our recommendation.)

If the use cases require operating without these protections, then I agree that bundling them altogether with a single configuration setting simplifies reasoning about security, in contrast to having many separate toggles for different protections.

[nathan-at-least]

Another thought: suppose an admin decides unencrypted submissions are acceptable. Should a whistleblower be allowed to decide, orthogonally, whether or not to require that all receivers have configured PGP keys?

This is more complexity, and I haven't discussed this with the other Least Authoritarians yet... Just a thought.

[evilaliv3]

yep @nathan-at-least the idea is exactly to implement a single configuration setting.

so probably on the admin configuration i will put something like this:
"[x] prevent to save any non encrypted file" that:

1. if checked will prevent to make a copy of files in plaintext when no encryption method is available.
2. if not checked will show a warning both on admin (next to the config checkbox) and on whistleblower/receivers pages with the text: warning: the system is configured to save plaintext files in case no encryption is available".

regarding your last idea i think that this will only complicate things, but we will think about it.
in fact i think if i am a Whistleblower, and node is not configured properly (super secure and so on), it does not matter what I want to enforce on the system, the system is not secure probably also for other reasons and the only thing i want is a big warning so to understand it and hopefully for me decide to chose an other possible leak platform.

[fpietrosanti]

Let's be focused on the end-user, i suggest:
Flag is: "enable unencrypted operations: ON/OFF" .
By default is OFF.

When it's OFF a receiver cannot be enabled without a PGP key (can't receive leaks)
When it's OFF a receiver without PGP it's not displayed on submission interface.
When it's OFF, a receiver that remove it's own PGP at a later stage, it's not displayed on submission interface.

When it's ON:

• All the warning are displayed on all of the users

[defuse]

@fpietrosanti I like that solution. There's one more thing that needs to happen when it's OFF:

When it's OFF, when a whistleblower submits a Tip to a receiver without PGP, the Tip gets rejected and the whistleblower's files are deleted.

Otherwise, the following scenario may happen:

1. Admin leaves the setting "OFF"
2. Receiver configures a PGP key.
3. Whistleblower selects that receiver.
4. Receiver removes their PGP key (they are now removed from the list, but it's too late, the Whistleblower already selected them).
5. Whistleblower finishes submitting the Tip.
6. The Tip is submitted in plain text to the Receiver.

[evilaliv3]

yep @defuse, it's exactly what we are thining and implementing. thanks

[fpietrosanti]

I would suggest to avoid a receiver from being selectable/recipient of a submission when it's OFF and the receiver is without PGP. That way we don't have any extraordinary operations to be done at a later stage.

[defuse]

@fpietrosanti Yes, but beware of race conditions and TOCTOU bugs, like the example scenario.

[evilaliv3]

yep @fpietrosanti i strongly agree with @defuse so that both approach are useful to be implemted.

1. the glbackend must provide to glclient only PGP configured receivers
2. the backend must validate in the later stage validating against the status at the end of the submission.

[evilaliv3]

@defuse:
in current devel branch we implemented the following:

• an allow_unencrypted boolean (with default False) has been introduced in order to allow rollback on plaintext files in situations where is not possible to apply encryption.
• based on the presence of the PGP and the setting of allow_unencrypted boolean we discern:
  • if allow / not allow submissions for each specific receiver (marking it unselectable on the submission interface)
  • no race condition exists anymore if the receiver removes the key or if the key becomes unavailable after the submission time and before the PGP encryption time; i.e. if the key is not valid at the time it need to be used the system with allow_unencrypted=false will mark the file not available for that receiver.

can this ticket be considered addressed?

[defuse]

@evilaliv3 That sounds really good. If you point me to the code that checks the allow_unencrypted upon tip creation I'll take a quick look at it.

Are users warned when their files won't be encrypted? Or have we decided not to do that?

[evilaliv3]

in case of allow_unencrypted=false and receiver without PGP the receiver is showed disabled with a clear message. (i'm going to paste all the related screeshots of the interface)

on the backend side:

https://github.com/globaleaks/GLBackend/blob/devel/globaleaks/handlers/submission.py#L71
here we avoid using provided receivers if they lack PGP key in case of a malicious client proposing them or key removal during submission time.

https://github.com/globaleaks/GLBackend/blob/devel/globaleaks/jobs/delivery_sched.py#L371
while processing file delivery we mark the file as missing with the special marker 'nokey' if the key is missing.

[fpietrosanti]

As a side notes, we should make a wiki page with all our "security awareness" features

[evilaliv3]

possibility to enable allow_unencrypted with a lot of warning messages for the admin:

allow_unencrypted=false: receiver disabled due to missing pgp key (the whistleblower cannot select it)

allow_unencrypted=true:
receiver enabled and security awareness messages:

[fpietrosanti]

Security Awareness documentation ticket at #864