> These people may have heard about a rule that it is good to upgrade your system, so their TB and enigmail is upgraded (semi)automagically.
This type of user behaviour has been exploited by the security services many-a-time. If that's who you're up against then somewhat counter-intuitively the advice is actually to run "old faithful" encryption suites which have been verified and just keep an eye on the changelog for any actual security issues (ignore feature updates).
If you have automatic updates turned on, there's nothing stopping them from MiTM-ling that and injecting a specially crafted (malware) version which will allow them to decrypt the traffic without you knowing (or just send them the private key(S)).
Now before you say "but the executable is signed!!!" well that's grand, but these guys have a CA in your certificate store. So they can generate fake certificates at a whim.
This logic also extends to any automatic updates on your system (e.g. Mac OSX system-updates have been exploited before in this way). A lot of software will download updates then run the "installer" in ring 0 (root). Even if you trust the source of the updates, do you trust all of the CAs in your CA store? I certainly do not.
Shouldn't the certs related to OS / app updates be self-signed (the root of trust being Microsoft/Apple/pkgmanager*), rather than anyone in your CA? Like, a new Java update should be signed by Oracle, not signed by Joe Schmo's Honest CA.
Also, forgive me if I'm wrong, but the original Evilgrade exploit for Apple was completely unencrypted, right?
Edit:
You use "these guys" to refer to the attacker quite a bit in your statement above, it'd be smart to think about your threat model a bit. For instance, it's likely that some actors can get a root WEB CA, and somewhat unlikely that they've gotten into Apple's chain of trust. These are different targets with different threat models.
> Shouldn't the certs related to OS / app updates be self-signed (the root of trust being Microsoft/Apple/pkgmanager*), rather than anyone in your CA?
Yes, this is how Debian works (they use a well known gpg key to sign their list of packages).
I believe the popular Mac OS X library Sparkle also works like this—the master public key is shipped with the App so that it only accepts updates that are signed by that particular key (if you use Apple's code signing then it only accepts new updates if they are signed by a key assigned to the developer).
That's the way Microsoft do it, yes. They have certificate pinning in the OS for updates (it isn't technically self-signed, but same principle).
FinFisher was exploiting insecure updates but they aren't the only game in town. There was, and still is, software around which only validates if the certificate is valid (via the OS) and little more, then will happily install the update as root.
As far as I know OS X is no longer vulnerable. I was just using that as an example to show that "anything" could be targeted that has automatic updates.
I remember when I first installed it that draft behavior was the default, but there's a config option to have it encrypt drafts before sending them to the server. As others have mentioned, it's pretty bad about deleting them when it's done, though. I think a better option is to just not have it save the drafts to the server at all (another option in the configuration).
You should check on that. I'm pretty sure I've seen lots of encrypted drafts on the server after I finish composing an email. I think it's bad at deleting them when it's finished.
>Also, I haven't checked, but I have a suspicion Thunderbird saves unencrypted drafts to the server while you're composing.
Fwiw, I use it regularly, and whenever my session expires and Thunderbird tries to auto-save an encrypted draft, it will require me to reauthenticate. Haven't actually looked at the auto-saved drafts on the server to confirm though.
What happens when A. you click a phishing link which takes your username and password, logs into the real site and downloads all of the data, B. the site is hacked and all of the mail on the site including archived stuff is leaked, or C. someone manages it MitM your network, uses a quasi-signed cert to spoof the actual website and reads all of your mail or finally D. the hosting provider is raided, and all data is handed over to an authority?
I don't think trusting a third-party with highly confidential financial data is very good practice.
"messaging" Implies that these notices travel from A to B likely in your own network, but you added "secure". This suggests the network itself is only password protected and is a compromise - or two? - away from revealing what is being sent. The purpose of encryption is to limit the damage should eavesdropping of the network occurs.
Ex: Your routers, switches, RAID storage etc. are not immune to rootkits. However, if your message from A to B is encrypted and only decrypted locally by B, you've limited the exposure of this information.
Everything is only a compromise or two away from being revealed. It may be one compromise away and we don't know it (yet). Cat and mouse my friend, that is all.
There are no passwords - we use our own CA system, PKI, carefully selected cipher suites, physical security, mutiple vendors' products, logical isolation, tiered architecture, an IDS system, mirrored environments, tamper detection and automatic key disposal.
And I still don't sleep because there are a thousand ways around it all.
That's a rather bleak outlook, but I don't blame you. Obviously you can't name which specific company you work in, but may I ask which sector in finance you do?
lol
i thought about explaining your folly, but then i remembered that i hate financial people. so i'm content to await the inevitable fate of your l33t financial "secure messaging service".
Exactly this. Business is not about providing optimum security - this is financially impossible unless you have a black ops size budget. It's about protecting one's ass as best as possible and having mitigation in place for anything that may be your fault.
> I understand your anger, but this is a volunteer. It seems obvous to me too that he messed up because the latest version is broken for me too. but let's cut him a little slack
I also don't agree. This project is featured on the homepage of add-ons list and I bet thousands of people rely on it. That's not how things work, software should be tested. https://addons.mozilla.org/en-US/thunderbird/
I try hard not to be the "you should ask for your money back" person, but I don't see that hand-wringing like this is any use as regards open-source software.
"Software should be tested" is indirect speech which leaves out the subject. Who should ensure that the tests are in the codebase? The creator? The writer of this update? If this was a first-time volunteer and his patches were acked by someone, the person who cleared them is arguably more at fault – the original contributor should not be blamed.
Developing OSS is a complex endeavor depending upon the donated time of hundreds of people. Sometimes I'm surprised that there are well-functioning, robust pieces of OSS out there at all.
I think it's a mistake to think that you need a "secure e-mail provider". You can't trust third parties, so we need trustworthy clients and a robust PKI. Then, as far as content goes, you can use NSA-spy-mail.gov.ru for your e-mail provider and it won't matter.
For metadata, I don't know that there's a good solution using the existing e-mail infrastructure. Maybe some sort of onion-style remailer could be put in place, but again, you can't just trust that lavaboom will be able to throw away that information even if they were the only ones who were capable of gathering it.
This type of user behaviour has been exploited by the security services many-a-time. If that's who you're up against then somewhat counter-intuitively the advice is actually to run "old faithful" encryption suites which have been verified and just keep an eye on the changelog for any actual security issues (ignore feature updates).
If you have automatic updates turned on, there's nothing stopping them from MiTM-ling that and injecting a specially crafted (malware) version which will allow them to decrypt the traffic without you knowing (or just send them the private key(S)).
Now before you say "but the executable is signed!!!" well that's grand, but these guys have a CA in your certificate store. So they can generate fake certificates at a whim.
This logic also extends to any automatic updates on your system (e.g. Mac OSX system-updates have been exploited before in this way). A lot of software will download updates then run the "installer" in ring 0 (root). Even if you trust the source of the updates, do you trust all of the CAs in your CA store? I certainly do not.