Comments
Natanael L • March 15, 2013 3:04 PM
I guess the PGP tags aren’t really helping.
In plaintext we need less visual tags for signatures, and the client software that displays it should hide it entirely as long as it can’t verify it. When it can confirm it is either valid or invalid, then it should notify the user.
Natanael L • March 15, 2013 3:05 PM
Also, I want to add that we need better integration of encryption in pretty much all software we use, including email clients.
Kevin Ballard • March 15, 2013 3:18 PM
Don’t forget to read the alt text on the comic!
Bill Stewart • March 15, 2013 3:32 PM
I’ve used “^—–BEGIN PGP” in messages as a SpamAssassin weight – spammers just don’t use it.
Doug D • March 15, 2013 3:40 PM
This is actually why I prefer S/MIME myself. A large number of GUI clients evaluate stuff automatically and present the result in a comprehensible way.
Sure, in the early adopter days, PGP was easier for sophisticated users to graft onto infrastructure that wasn’t aware of it, but that’s not the way to go in the long run.
max630 • March 15, 2013 5:13 PM
Doug D
There are MIME extension to use pgp signature, described rfc2015 and rfc3156. But “the mail clients” fail to even read such messages, let alone verify them. So no wonder nobody uses them.
I used to be a writer; hard SF, wanted stuff to be as realistic as possible. When a plot called for a PGP-signed message to be shown, I generated the text with PGP so the hash would be right.
Eventually, I realized that people actually read/watch Star Drek, so I quit bothering. Then I quit writing.
-sigh-
At least I don’t drink as much anymore.
pfogg • March 15, 2013 9:41 PM
People don’t use PGP enough to make it worth spoofing, so when it’s present it’s reasonable to assume it’ll test out to be valid and match the author, even though it’d be trivial to fake (since no one’s going to check it).
The author will typically be asked not to render emails unreadable with PGP text in an annoyed response, and this can serve as a proof of delivery.
Nick P • March 15, 2013 9:50 PM
This reminds me of the labelling issue back in the MLS heyday. The Orange Book standard for higher assurance security required trusted displays with unspoofable labels on the windows. Browsers have a built-in way of telling you if a site has SSL and if it passed basic validation.
I think the solution is to have email clients clearly indicate the security status of the message. Might have to standardize on S/MIME or PGP (one or the other, that is). Then, have maybe an envelope with a lock on it or something. The thing is every email to be opened is checked, validated and its type is indicated to user.
There might be a setting to require a manual override for non-validated emails in an organization that almost exclusively uses cryptographic mail. The untrusted email might be opened in a sandboxed, deprivileged process. And so on.
Thoughts?
Leif S. • March 16, 2013 12:47 AM
I think this is a good one on security. My favorite xkcd on security in the real world is no 538
sshdoor • March 16, 2013 5:39 AM
Same problem for fingerprints of ssh keys. I don’t even know how to check them.
Besides, even if anyone checked ssh’s fingerprints, any unix/linux computer with at least one user, which is not using a password safe, is vulnerable to any future ssh worm:
- some user doesn’t bother to invent enough different passwords, and happens to share passwords between two unix accounts
- this user uses ssh from one clean machine to an infected machine, which presents a clean host fingerprint
- the worm gets his password[1] and logs back to the clean machine
- the worm uses a local escaliation vulnerability[2]
- the worm infects the clean machine, without effect on its fingerprint
It is scary.
It would be time to change the ssh protocol before this actually happens.
For this, it is not necessary need to change passwords, or salting mechanism of /etc/shadow (unlike the patch patch Secure Remote Password (SRP) for openssh).
[1] available naturally in the ssh protocol http://blog.eset.com/2013/01/24/linux-sshdoor-a-backdoored-ssh-daemon-that-steals-passwords
[2] https://isc.sans.edu/diary/Fedora+RedHat+Vulnerabilty+Released/15172 or any other, there is a continuous flow of them, even on openbsd.
Jonathan Wilson • March 16, 2013 7:13 AM
Its 2013 and there is no excuse for email clients not supporting encryption out of the box.
Paeniteo • March 16, 2013 7:31 AM
@Natanel L: “the client software that displays it should hide it entirely as long as it can’t verify it”
How is a client software that has no clue about PGP supposed to do that?
The PGP-compatible email clients that I know of hide these metadata lines when they have processed them.
Marcos • March 16, 2013 9:58 AM
@ Nick P
I think the solution is to have email clients clearly indicate the security status of the message.
KMail does that. But I guess it’s the only thing that KMail actualy does right, so it doesn’t matter.
@ sshdoor
There is no way to make a remote access software invunerable to that. If you make it safe, it won’t permit remote access anymore.
Forbiding ssh password authentication is a step on the right way, but nothing will completely solve the problem.
sshdoor • March 16, 2013 10:35 AM
@Markos: “There is no way to make a remote access software invunerable to that.”
There is such a way:
- the sshd daemon gives the content of the salt to the ssh client (making it rather public).
- the ssh client computes the content of /etc/shadow relative to the account asked (asking the password to the user).
- the ssh client computes a hash with that content, and send it to the daemon.
- the sshd daemon also computes the same hash and check that the ssh client is providing the same hash.
@Markos: “Forbiding ssh password authentication is a step on the right way, but nothing will completely solve the problem.”
It is a working solution, indeed, but with a transition that the user will be aware of and reluctant to make.
Bobby • March 16, 2013 3:57 PM
i have recieved these messages from SANS. Did not really give it much thought, but now i see the futility of the whole caboodle. Thought the email client inserts the lines when it reads the PGP encoding. I now need to read on the topic.
dandraka • March 18, 2013 2:41 AM
@ Nick P
I think the solution is to have email clients clearly indicate the security status of the message.
7-8 years ago, I tried (and actually succeeded) to get my midsized (100-120 employees) company to mandate that all emails are sent with S/MIME.
Since everybody was using Outlook and email certs were available for free with a simple registration -can’t remember which CA it was, but it wasn’t Verisign or Thawte- I got everyone onboard. I wrote a simple step by step howto, complete with screenshots, did 2-3 training sessions and before you know it (well, sort of) everybody was using it. No problems, and everbody was happy.
Well, for some time anyway.
After a year, when the certs expired, Outlook started popping up warning messages. And if there’s anything C-level execs ABSOLUTELY HATE, it’s worrying messages using technical language.
The problem was that &%*&% Outlook thinks that, when an email was signed with a now-expired certificate, the email is invalid/dangerous/scary/whatever.
WHY THE %&%& WOULD IT THINK THAT, THE CERTIFICATE WAS PERFECTLY GOOD WHEN THE BLOODY MAIL WAS SENT. OFCOURSE ITS NOT VALID AFTER ITS EXPIRATION DATE, THAT’S WHAT IT’S THERE FOR.
I got blamed for this failure, had some horrible meetings and ofcourse the project was quickly abandoned.
I’ve always wondered how other email clients treat the same issue. Is it just MS nonsense ?
Dirk Praet • March 18, 2013 10:26 AM
@ NickP, Dandraka
I think the solution is to have email clients clearly indicate the security status of the message. Might have to standardize on S/MIME or PGP (one or the other, that is).
Thunderbird does that. So does Outlook and several other MUA’s.
In my experience, a working S/MIME or PGP setup in pretty much any organisation is an exercise in futility unless there is a serious business case such as legal or regulatory obligations. The cost of deployment, maintenance and training is just too high to explain to any exec or beancounter most of whom don’t really care about security in the first place if there is no significant RoI (return on investment/risk of incarceration).
Many of the hurdles are summed up quite well in the Wikipedia article found at http://en.wikipedia.org/wiki/S/MIME#Obstacles_to_deploying_S.2FMIME_in_practice , and the BYOD age where everyone posesses multiple non-company owned mobile and other computing devices hasn’t made it any easier either.
Personally, and for certain types of sensitive communications with certain correspondents, I use both S/MIME and GnuPG with multiple email accounts on multiple machines, operating systems and applications. It’s a friggin’ nightmare to maintain.
Although free certificates for personal use can still be obtained from Comodo, I have to deploy them to all my devices and MUA’s every year, and for multiple accounts. Reasonably straight-forward for common GUI desktop applications such as Thunderbird, Outlook, Apple Mail and the like but an utter pain in the lower backside when dealing with tablets and smartphones, providing the mail apps on them already support S/MIME in the first place. Webmail most of the time also requires installation and maintenance of the appropriate plugins/controls on your browser (eg. OWA S/MIME control for Internet Explorer, Gmail S/MIME for Firefox, Mozilla S/MIME Toolkit).
Same thing when using PGP/GnuPG, with the additional burden of keeping your key chains in sync between multiple devices. Keeping those in the cloud may not be the best idea unless you have them securely encrypted (eg. Boxcryptor/EncFS) and a means on every of your platforms to access and decrypt them. I have been looking into more user friendly solutions like Enlocked, but wasn’t particularly keen on key escrow and encryption/decryption happening on their servers.
For what it’s worth, I don’t believe S/MIME-PGP scales particularly well beyond individuals and small outfits/workgroups who have a legitimate need for it and know what they’re doing. Corporations that don’t want to invest in a PKI may look into PGP gateway solutions such as the one offered by Symantec, which has the advantage of solving many the more common client-side issues. And for the average John Doe in the street owning an iPhone/IPad there is Wickr nowadays, coming soon to Android too.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Aj Reznor • March 15, 2013 2:59 PM
Nailed it.