Enigmail did not encrypt email to recipients
sourceforge.net
sourceforge.net
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.
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.
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.
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).
If it was important, I would probably encrypt on the command line, on a more trustworthy device than my regular PC.
Also, I haven't checked, but I have a suspicion Thunderbird saves unencrypted drafts to the server while you're composing.
However if I write the message before specifying that I want it encrypted, it gets sent to the server unencrypted.
Which kind of makes sense I suppose, but seems like a bit of a usability gotcha.
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.
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.
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.
Still, we have insurance.
Integration between various companies, nothing more. We're a hub.
1. Get an email at your normal email that you have a message at secure email provider
2. Click link, get taken to a web page where you need to make an account to read the mail
3. Read mail at the link, you can reply and attach stuff to it, and that's it. No create mail functionality.
So you end with up with "email conversation as a link" sort of feeling. Very odd when you're used to dealing with any other "normal" webmail site.
I don't think trusting a third-party with highly confidential financial data is very good practice.
> 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/
"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.
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.