I agree; however the really good way to get your data (I mean virtually everything about your private life) harvested, analysed, and sold, is to use Gmail for email 
Or some other large webmail provider.
All the time you use “normal” email, with your (little local) ISP providing a POP box or whatever, or running your own POP server and using some 3rd party email filtering service (I use Messagelabs; not cheap but outstanding) there isn’t likely to be anybody reading and analysing your emails.
And if you use secure email of some sort, nobody is likely to see who you are communicating with. Well, the GCHQ/NSA probably have links to ISPs but who cares about that?
I agree that public key publication is very tricky from the privacy point of view because, of necessity, anybody needs to be able to see it and verify it.
In this day and age of big data and intrusive personal data harvesting, the OpenPGP web of trust (and any similar structure) is also a “who knows who / has met who” graph, easily collectable. The balance of risks, and its perception, has changed. The backtrack we had on secured (yet highly federated) communication is part of what I emotionally consider the geek/hacker’s dream failure, and one of the reasons that computer enthusiasts (of that kind) now think “I don’t like computers anymore”. They have gone from tools of empowerment to tools of oppression. The writing was on the wall, we could have seen it, but we, as a group, largely didn’t. Computers multiply power; when only the “little guys” were using them (effectively), they empowered “anybody technically proficient”, with the hope that it would soon be “anybody”. Now, they just increase the power gap between the already powerful and the commoners.
Peter wrote:
That is surely complete bunk, in security terms
You could run different servers on the same hardware, under VMs, and nobody could tell from the outside that you are doing it.
That’s perfectly acceptable under PCI-DSS. They require services to be containerised, and virtualisation is a perfectly acceptable way of achieving that. In any case, the public IP address(es) tell you nothing about the underlying architecture, so no PCI-DSS assessor should be making an assessment based on what’s on a particular IP, and if they attempt to do so, they aren’t doing their job. You can just as easily have multiple IPs going to the same container or virtual machine as you can have one IP address going to 18 different ones. A PCI assessor that tries to judge what’s going on by the number of services behind an IP isn’t doing a competent job (especially as it’s getting increasingly hard to get more than one public IP address per organisation, due to the shortage of IPv4 address space. The last justification was for SSL websites needing unique IP addresses, but now with SNI being ubiquitous, that excuse has gone away).
Also if you’re doing a certain volume of transactions, they don’t just look from ‘the outside’, for high volume transaction organisations you get actual auditors coming in, as well as internal penetration testing (not merely a scan) and they want to see architectural diagrams and evidence that the architectural diagrams actually represent reality, they want to see firewall rules, they want to see examples of safe software development practises etc. etc. When we were doing high volume work using payment cards, the report of compliance involved a full six weeks of auditing. It was a bit more than scanning your public IP space!
PCI-DSS doesn’t prohibit services being on the same IP address. It does generally require services be separated out onto different servers
That is surely complete bunk, in security terms
You could run different servers on the same hardware, under VMs, and nobody could tell from the outside that you are doing it.
One thing I don’t get is why ISPs (I use the word in the context of who provides incoming email filtering, for most email users) don’t provide a user interface which would enable the customer to configure whitelisted domains while stipulating that should be a hard whitelist if DKIM passes. That might drive DKIM adoption, over time. It would also provide a base for end to end email security, with those people. The large number of “secure email” providers just ensures that most people will not bother – except those who need to communicate securely only with a small group of other people.
PCI-DSS doesn’t prohibit services being on the same IP address. It does generally require services be separated out onto different servers (but these servers can still share the same public IP address – which is easy to do with any firewall made within the last 20 years. They don’t have to be on different physical machines either, virtual servers or other similar containers are fine). We have dozens of different services behind the same public IP address and reverse proxy, for example, and the auditors are just fine with that.
Of course the way cardholder not present transactions are done is yet another example of the tremendous inertia that stops simple improvements being made. IMHO, all cardholder not present transactions should require at least two factor authentication – relying on a static number printed in plain text on a plastic card is not really good enough in this day and age, and the PCI instead of actually fixing the root cause are instead pushing the costs onto everyone else to protect this awfully insecure way of doing payments. Even in fully compliant organisations you can easily end up with a breach and a bunch of fraud (the auditor for our ROC told us about the one company who had a staff member who simply memorised card numbers and CVVs, and then would run up a bunch of fraudulent charges. Their IT network was absolutely perfectly secure from a PCI-DSS standpoint, but when you take credit cards over the phone all it takes is a person with a good memory, something that would be prevented by 2FA)
There’s also an interesting book called “Other People’s Money: The Rise and Fall of Britain’s Most Audacious Fraudster” written by a credit card fraudster, and basically he defrauded people of a lot of money by social engineering and exploting the holes the credit card issuers left in.
Hmmm I recognise a few of the above disasters, starting with PCI-DSS which forced my little firm to pay almost double the commission for credit card processing – because we could no longer deal with the exhausting requirements, e.g. they would port scan our server and if they found we run an SMTP server on the same IP as the online shop they would throw us out
SSL/TLS only encrypts the data between the email client and the server. That happens anyway if you are accessing webmail (e.g. gmail) which uses https.
I guess the answer to my original Q is that few people care about who reads the stuff.
But none of this deals with authentication of incoming emails. At least I would have expected to see a big takeup of DKIM, perhaps with email app functionality to use it even if the email provider doesn’t.
The problem is that email is a massively, decentralised federated system that is accepted everywhere. To change it, you have to get pretty much everyone to change at once – some things can be changed easily (like mail servers these days typically using TLS rather than sending stuff unencrypted), but even things like using PGP to sign emails is hard.
The problem is until enough people are doing it, 99.9% of people/orgs will not do it because not enough people are doing it (so you get the feedback loop of nothing being done).
It would require “force” to get people to use even the easy stuff. Broken SSL/TLS was in use for years and no one cared about improving the situation until the PCI (payment card industry) DSS (data security standards) forced the issue (meaning you would not be able to take credit cards online unless you fixed your broken HTTPS configuration) but even the PCI had to delay two years things like getting rid of broken TLS 1.0 due to industry lethargy (even relatively recent versions of MSIE didn’t have TLS 1.2 enabled by default until reasonably recently, meaning if you shut off TLS 1.0 on the original deadline of June 2016, about 2/3rds of your users would no longer be able to connect).
We do business with a Very Large Media Company (who outsource some of their IT to a Very Large IT Supplier) and we had a big problem with them due to this cutoff date (it didn’t just affect TLS, but anywhere where CBC modes were being used). They tried to do everything to avoid having to make the required change (only starting work 3 weeks before the deadline – which they’ve now missed so we’ve had to implement a workaround for them). Ironically this same Very Large Media Company required us to do a security audit questionnaire which required us to certify we don’t use the same deprecated CBC modes that their IT supplier was insisting that we had to support! (The weaknesses in CBC modes have now been known for ten years). Their IT supplier tried to get us to support an alternative configuration which relied on MD5 checksums, which have been known to be weak since the 1990s. Incidentally, the software we use to provide SFTP has supported aes-ctr since 2003 and deprecated HMAC-MD5 about 5 years ago. None of these things should have been hard for them to support but they suffer enormous organisational inertia (they are for example using a version of Solaris that was superceded in the early 2000s). I suspect this kind of thing is hardly unique, and not only that, anyone who deals with this stuff could have seen as long ago as 10 years back that this change was going to end up being required by security standards like PCI-DSS. Yet this extremely large and profitable IT company still managed to miss this very visible deadline that people have been talking about for years.
These days, the sending around is typically done over encrypted links, but the content of the email is going though every server in plain text, and how it is processed and stored there depends on the server.
The reason for this is quite simple: Many tech giants who provide the infrastructure have a strong interest in NOT having encrypted e-mail. Fore example, Google is reading all e-mail going through gmail and uses the data gathered for advertising and in other ways to make money. So do other providers. End-to-end encryption would scupper this, so while they can’t prevent it, they certainly have no interest in providing it.
Combine that with this being a “hard” problem due to the need for standardisation, and the result is that only those both in need of security AND savvy enough to do it are protected.
Yah I wondered about secure email a year or so ago, and lost interest very quickly … my interest was piqued by people still putting a PGP key on their profile on a website, but it all got too nerdy very quickly.
Is email basically sent around the internet as plain text?
Wickr is used by a lot of people needing secure interactions, I don’t know / understand the tech behind it though.
