No description provided.
• 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
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.
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.
I would not call the configuration "unsecure" but "unencrypted" because a system can be secure, in it's own threat model, also without encryption
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"
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.
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.
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:
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.
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:
@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:
yep @defuse, it's exactly what we are thining and implementing. thanks
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.
@fpietrosanti Yes, but beware of race conditions and TOCTOU bugs, like the example scenario.
yep @fpietrosanti i strongly agree with @defuse so that both approach are useful to be implemted.
in current devel branch we implemented the following:
can this ticket be considered addressed?
@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?
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:
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.
while processing file delivery we mark the file as missing with the special marker 'nokey' if the key is missing.
As a side notes, we should make a wiki page with all our "security awareness" features
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)
receiver enabled and security awareness messages:
Security Awareness documentation ticket at #864