[Big Mac]

You know what bothers me about many professionals who are outside of technical fields? None of the ones I deal with use [edit] encryption. Although the chances are pretty remote under most circumstances that unencrypted emails will be intercepted in transit, it just annoys the geek in me that I have to communicate sensitive information over insecure channels with CPAs and lawyers and the like. I guess more of us young professionals have to replace the previous generations before we'll see widespread use of encryption. (When I started this thread I thought all email encryption was PGP based; I didn't know that Thawte certs are SSL based instead.)

[rickey939]

PGP Keys are the hotness.®

[Eug]

You know what bothers me about the technical types? They haven't integrated PGP in most email software so that anyone is easily able to use it.

[Big Mac]

If they did, they'd have to use self-signed certs, which doesn't seem to be a very popular choice.

[Doofy]

Originally Posted by Eug 

You know what bothers me about the technical types? They haven't integrated PGP in most email software so that anyone is easily able to use it.

It's not like installing PGP Email (the actual official commercial product, not the open source freebie one) is difficult.

I concur with Biggy. Folks not using PGP pisses me off.
In fact, I demand that PGP is used for sensitive data or I find myself another professional. I mean, for the sake of £95 and a few minutes work they don't want my business? Screw that.

[besson3c]

Originally Posted by Big Mac 

If they did, they'd have to use self-signed certs, which doesn't seem to be a very popular choice.

Why? PGP is different than email SSL certificates, so I don't see how this applies.

All you would need to support PGP in an email program is the PGP libraries, and a key creation and management interface.

[besson3c]

I think part of the problem is the battle between two competing standards: SSL email certs, and PGP. IMHO, PGP is superior, especially since anybody can go and create themselves a free email cert which really tells the receiver nothing except "somebody requested an SSL cert".

The problem is, PGP is a little harder to setup and get going, and there are issues such as mismatching public/private keys when you are on a computer where your private key is unavailable, the responsibility being on the user to indicate which keys he/she trusts, and of course users being unable to decrypt encrypted messages without a compatible client and the user's public key installed. So, you get convenience with SSL email certs, and better technology with PGP.

[Big Mac]

Originally Posted by besson3c 

Why? PGP is different than email SSL certificates, so I don't see how this applies.

All you would need to support PGP in an email program is the PGP libraries, and a key creation and management interface.

Shows how much I know - I didn't know of the distinction between the two.

[The Crook]

I'm gonna put myself in the non-tech related professional category here.

I thought all you had to do was:

[besson3c]

Well, OS X Mail doesn't support PGP natively at all. There is a bundle/hack type thing you can install to shim in PGP support though. OS X Mail does support SSL email certs. If you are using OS X Mail and haven't install GPGMail and gnupg separately, you either are using SSL email certs or nothing.

[Big Mac]

Is there any particular reason one could point to as to why Apple refuses to support PGP?

[Doofy]

Originally Posted by besson3c 

If you are using OS X Mail and haven't install GPGMail and gnupg separately, you either are using SSL email certs or nothing.

Complete crap. I didn't install GPGMail and gnupg and I've got OS X Mail working with PGP.

[Doofy]

Originally Posted by Big Mac 

Is there any particular reason one could point to as to why Apple refuses to support PGP?

It doesn't refuse to support PGP. Bess is talking crap because he knows little about the world outside of his little freetard linux universe.

[besson3c]

Originally Posted by Doofy 

Complete crap. I didn't install GPGMail and gnupg and I've got OS X Mail working with PGP.

How? Is there a commercial product for OS X Mail?

[besson3c]

Originally Posted by Big Mac 

Is there any particular reason one could point to as to why Apple refuses to support PGP?

My theories:

1) OS X Mail is already pretty light on features, maybe Apple doesn't think there is money/interest in PGP support

2) Like I said, it is more complicated to setup and maintain

[Doofy]

Originally Posted by besson3c 

How? Is there a commercial product for OS X Mail?

http://www.pgp.com/downloads/desktop...toptrial2.html

[besson3c]

Originally Posted by Doofy 

http://www.pgp.com/downloads/desktop...toptrial2.html

Did Apple write this? You'll notice that I wrote:

Well, OS X Mail doesn't support PGP natively at all

natively meaning it is not a part of OS X Mail written by Apple.

[Doofy]

Originally Posted by besson3c 

Did Apple write this?

Did Apple provide the specs to the people who did? Yes. So does Apple support it? Yes.

What you actually wrote, Bess, was this:

Originally Posted by besson3c 

If you are using OS X Mail and haven't install GPGMail and gnupg separately, you either are using SSL email certs or nothing.

...which is clearly complete shite.

Since you've started moving the goalposts in your usual weasely way, this conversation ends here. You're just plain wrong. Go back to your linux shitbox.

[besson3c]

Originally Posted by Doofy 

Did Apple provide the specs to the people who did? Yes. So does Apple support it? Yes.

Technically, no. My understanding of Apple's bundle thing is that it's basically "here if you want to use it", but there is no API for it like there is for Mozilla plug-ins, for instance, This is why when you update Safari or Mail sometimes these add-ons break. I could be wrong about this though...

What you actually wrote, Bess, was this:



...which is clearly complete shite.

Since you've started moving the goalposts in your usual weasely way, this conversation ends here. You're just plain wrong. Go back to your linux shitbox.

Dude, settle down, I don't want to rile you up. I'm wrong in what I wrote, I admit, I wasn't thinking about the commercial PGP solution. You know that I don't run Linux as a Desktop OS, so stop trying to troll.

[Eug]

I understood bess's qualifier "natively" perfectly.

In any case, I don't bother with any of this, cuz nobody else I know does ether.

In my little world, sensitive emails are not supposed to beyond my workplace's intranet, and everything else is a phone call.

[besson3c]

Originally Posted by Eug 

I understood bess's qualifier "natively" perfectly.

In any case, I don't bother with any of this, cuz nobody else I know does ether.

In my little world, sensitive emails are not supposed to beyond my workplace's intranet, and everything else is a phone call.

Yeah, I think that's a philosophy that a lot of companies take, but I've heard about sensitive information or proprietary information being sent to non company accounts all the time. Hell, didn't some of those emails involving the firing of that relative of Sarah Palin's involve a Yahoo account?

I agree with Big Mac that it's high time that we step up on email content signing and encryption. I like the idea of sort of forcing the issue and making it so easy that it is almost harder to *not* do things the secure way. It is too easy for some non-tech savvy to fire away an email outside of the intranet without even thinking twice about it.

If a significant population of users were into PGP signing of emails, we could build some much better anti-phishing controls into email clients. It seems like a much better solution to inspect the keys to determine whether an email is spoofed rather than relying on some long list of phishing sites/emails that is a constantly moving target, or even relying solely on return path/envelope address info. With a large enough email system like GMail, illegitimate mail can be transferred via absolutely legit SMTP servers that match the domain in the from address in the email header.

[Doofy]

Originally Posted by besson3c 

I like the idea of sort of forcing the issue and making it so easy that it is almost harder to *not* do things the secure way.

It's already this easy.

Originally Posted by besson3c 

It is too easy for some non-tech savvy to fire away an email outside of the intranet without even thinking twice about it.

Here's what PGP commercial does:

If it finds a public key for the recipient, it'll encrypt.

If it doesn't find a public key for the recipient, you can set it to either stop the message, clearsign it or let it through with no modification. On a per domain basis if required.

It's completely transparent - you're not even aware that you're using PGP unless you look at incoming headers or pick a message straight off the server. There's no little extra check boxes or menus in Mail - it's totally automatic.
Set-up correctly, it's impossible for someone to send an unencrypted message outside of the intranet.

[besson3c]

Originally Posted by Doofy 

It's already this easy.



Here's what PGP commercial does:

If it finds a public key for the recipient, it'll encrypt.

If it doesn't find a public key for the recipient, you can set it to either stop the message, clearsign it or let it through with no modification. On a per domain basis if required.

It's completely transparent - you're not even aware that you're using PGP unless you look at incoming headers or pick a message straight off the server. There's no little extra check boxes or menus in Mail - it's totally automatic.
Set-up correctly, it's impossible for someone to send an unencrypted message outside of the intranet.

Yeah, the config for what I use is similar. I agree that it can be quite easy and transparent for users once it's setup and configured. It's the setup and configuration part that I think is the challenge - i.e. intelligent and non-irritating defaults, bundling it into common clients and having it ready to go out-of-the-box with new computer purchases, etc.

The other thing is that the recipient needs support for this too, which means we'd have to get all of the major free Webmail providers and Microsoft onboard too.

[mattyb]

What bothers me most ... isn't just PGP or the non-usage of, but the level of IT security in general.

Email is the least of our worries people. Ever heard of SOx? No, nothing to do with baseball. A joke, just like most ISO and quality controls. Great big steaming piles of lies.

Today I had the pleasure of finding a fairly important MySQL database that one could access without a username OR a password.

[Doofy]

Originally Posted by besson3c 

Yeah, the config for what I use is similar. I agree that it can be quite easy and transparent for users once it's setup and configured. It's the setup and configuration part that I think is the challenge - i.e. intelligent and non-irritating defaults

I'm using the default settings on mine. Works a treat.

Originally Posted by besson3c 

bundling it into common clients and having it ready to go out-of-the-box with new computer purchases, etc.

The other thing is that the recipient needs support for this too, which means we'd have to get all of the major free Webmail providers and Microsoft onboard too.

Yep. That's the problem. Most people simply don't think they need it.
However, the professionals that this thread refers to have absolutely no excuse.

[besson3c]

Originally Posted by mattyb 

What bothers me most ... isn't just PGP or the non-usage of, but the level of IT security in general.

Email is the least of our worries people. Ever heard of SOx? No, nothing to do with baseball. A joke, just like most ISO and quality controls. Great big steaming piles of lies.

Today I had the pleasure of finding a fairly important MySQL database that one could access without a username OR a password.

You mean no root password, or somehow configured to allow any user full access to it? What hosts were allowed to connect to it remotely? I'm wondering because I'm trying to get a sense of how common these sorts of setups are, how common cross site scripting attacks are attempted, and how common the two are taken advantage of in combination. I have this sort of sense that a lot of web programmers aren't sys admins who think about this sort of stuff.

[besson3c]

Originally Posted by Doofy 

I'm using the default settings on mine. Works a treat.



Yep. That's the problem. Most people simply don't think they need it.
However, the professionals that this thread refers to have absolutely no excuse.

Yeah. The other thing is the whole legal angle. A cleartext, unsigned, unchecksummed email is not a valid legal document, whereas a PGP protected one is. What if you run a company and one of your employees decides to start the next 9/11 and sends email out through your network? All his legal defense would have to do is play the "not a valid legal document" card and this guy would probably get off free.

Why doesn't every company in the world cover their asses this way?

[alligator]

I use it, but I hate how difficult it is to use.

[turtle777]

I'm using SSL certs (a.k.a. X.509).

Free certs are available at Thawte.com.

It's easier to install than PGP, but still not idiot proof.
Plus, you need to apply for a new cert every year.

-t

[besson3c]

Originally Posted by turtle777 

I'm using SSL certs (a.k.a. X.509).

Free certs are available at Thawte.com.

It's easier to install than PGP, but still not idiot proof.
Plus, you need to apply for a new cert every year.

-t

Also mostly just providing a deterrence security wise, it is pretty easy to circumvent the security of an email SSL cert.

[turtle777]

Originally Posted by besson3c 

Also mostly just providing a deterrence security wise, it is pretty easy to circumvent the security of an email SSL cert.

Really ? How's that ?

I never heard that X.509 is inherently less secure. Unless you are talking about breaking into the main key server.

-t

[besson3c]

Originally Posted by turtle777 

Really ? How's that ?

I never heard that X.509 is inherently less secure. Unless you are talking about breaking into the main key server.

-t

I'm talking about me going to the free cert website and saying "hey, I'm turtle777, not to be confused with turtle776... Cough up my free cert!", installing that cert and posing as you.

[turtle777]

Originally Posted by besson3c 

I'm talking about me going to the free cert website and saying "hey, I'm turtle777, not to be confused with turtle776... Cough up my free cert!", installing that cert and posing as you.

How exactly is this different than creating your own PGP cert with a false identity ?

True, the standard Thwate cert has no name in it.

But if you get "certified" by independet third parties ("web of trust"), your name appears as part of the cert. That's gonna be much harder to forge.
Plus, my email address is my firstname@mylastname.net. Someone posing as me would need to hack my mailserver or account, too. So in combination, I don't see how this is any less secure.

-t

[besson3c]

PGP works based off of the web of trust, and public key servers that help prevent public keys associated with duplicate email addresses circulating. While you could email somebody a fraudulent public key for them to manually install, searching the key server for a user's key is the way most clients are setup to operate.

[Cipher13]

Originally Posted by Big Mac 

You know what bothers me about many professionals who are outside of technical fields? None of the ones I deal with use PGP.

So, they're just like the vast majority of "professionals" that *are* tech-based?

[turtle777]

Originally Posted by besson3c 

PGP works based off of the web of trust, and public key servers that help prevent public keys associated with duplicate email addresses circulating. While you could email somebody a fraudulent public key for them to manually install, searching the key server for a user's key is the way most clients are setup to operate.

I found the public key server concept a big strength and weakness and the same time.
For a while, I used PGP, but somehow, my keys would show up in some key servers, in others they wouldn't. Plus, if you don't take good care and lose your private or revocation key, they key servers will end up with "dead" public keys, and there is NO way to clean that up.

Just imagine someone who's not tech savvy trying PGP, and ending up with 3 or more PGP public keys listed. What then ? You are screwed.

Overall, I don't think PGP is inherently better.

-t

[mattyb]

Originally Posted by besson3c 

You mean no root password, or somehow configured to allow any user full access to it? What hosts were allowed to connect to it remotely? I'm wondering because I'm trying to get a sense of how common these sorts of setups are, how common cross site scripting attacks are attempted, and how common the two are taken advantage of in combination. I have this sort of sense that a lot of web programmers aren't sys admins who think about this sort of stuff.

Not sure how well you know MySQL's security methodology, but you can have the same user with a different password with different privileges from two different hosts. You can also not allow root logins remotely, or any user for that matter. There was one line in the user table of the mysql database that had just the hostname, no password and no username. Oh and it had ALL privileges. So, if you were logged onto the host as any bog standard user, you could just type :

/usr/local/bin/mysql

And you would have the equivalent of root access to the MySQL instance. Drop away !!!

Besides that, the root user didn't have a password. Shoddy setup, somebody should be shot - btw it was Unix sys admins who setup the MySQL security in this case.

Luckily its (the management of the MySQL instance and its databases) being handed over to me next week.

[besson3c]

Originally Posted by turtle777 

I found the public key server concept a big strength and weakness and the same time.
For a while, I used PGP, but somehow, my keys would show up in some key servers, in others they wouldn't. Plus, if you don't take good care and lose your private or revocation key, they key servers will end up with "dead" public keys, and there is NO way to clean that up.

Just imagine someone who's not tech savvy trying PGP, and ending up with 3 or more PGP public keys listed. What then ? You are screwed.

Overall, I don't think PGP is inherently better.

-t

It is if you are savvy enough to not have these sorts of problems, but I agree that it takes more know-how. This is sort of what I was alluding to.

[besson3c]

Originally Posted by mattyb 

Not sure how well you know MySQL's security methodology, but you can have the same user with a different password with different privileges from two different hosts. You can also not allow root logins remotely, or any user for that matter. There was one line in the user table of the mysql database that had just the hostname, no password and no username. Oh and it had ALL privileges. So, if you were logged onto the host as any bog standard user, you could just type :

/usr/local/bin/mysql

And you would have the equivalent of root access to the MySQL instance. Drop away !!!

Besides that, the root user didn't have a password. Shoddy setup, somebody should be shot - btw it was Unix sys admins who setup the MySQL security in this case.

Luckily its (the management of the MySQL instance and its databases) being handed over to me next week.

I see...

The previous owner must have been a complete numbskull then to go out of their way to do the hostname, wildcard user, no password thing. I was thinking that not even a popular tool like phpMyAdmin would allow a wildcard user, but I was wrong!

[ghporter]

So what's the big difference between the freeware version and the commercial version nowadays? I've been in a "I haven't had a need to send anything sensitive" situation for several years, and I haven't kept up.

By the way, in MY setting, you need encryption to send sensitive stuff (patient information, for example) WITHIN the local intranet. And a lot of physicians just can't be bothered to get their certificates loaded onto the smart cards everyone has for logging in and such.

[besson3c]

Originally Posted by ghporter 

So what's the big difference between the freeware version and the commercial version nowadays? I've been in a "I haven't had a need to send anything sensitive" situation for several years, and I haven't kept up.

By the way, in MY setting, you need encryption to send sensitive stuff (patient information, for example) WITHIN the local intranet. And a lot of physicians just can't be bothered to get their certificates loaded onto the smart cards everyone has for logging in and such.

The main difference is probably just that the commercial version offers a GUI and is more consumer friendly. Gnupg (the open source version) is used by all sorts of ISPs and applications, it is secure and pretty commonly found on Unix servers and web-based email systems, it just doesn't offer a GUI - that part is left up to vendors that make use of it. There is a list of frontends that use gnupg on their project website, if you are interested.

PGP technology is not synonymous with email, it can be used to digitally sign any files, and encrypt any cleartext files.

[Doofy]

Originally Posted by ghporter 

So what's the big difference between the freeware version and the commercial version nowadays?

Freeware:

Originally Posted by alligator 

I use it, but I hate how difficult it is to use.

Commercial:

Originally Posted by Doofy 

It's completely transparent - you're not even aware that you're using PGP unless you look at incoming headers or pick a message straight off the server. There's no little extra check boxes or menus in Mail - it's totally automatic.

Technically, I guess the difference is that the freeware version is some kind of extension to your email app while the commercial version is actually a proxy which sits between your email app and the server.
http://aldoblog.com/2005/08/pgp-desk...-for-mac-os-x/

[ghporter]

Originally Posted by Doofy 

Technically, I guess the difference is that the freeware version is some kind of extension to your email app while the commercial version is actually a proxy which sits between your email app and the server.
http://aldoblog.com/2005/08/pgp-desk...-for-mac-os-x/

Thanks, Doofy. I'll look into it.

[besson3c]

I'll let Doofy speak to the commercial version more since I've never used it, but just to clarify his comment about the free version, it is not an extension to anything. It is simply a command line utility that can accept input and generate output. It can also be used independently of any data source via the command line. It is consistent with Unix programming design, just a specialized tool that focuses on doing its one task. However, it does go a little further than other Unix tools in having a pretty comprehensive interactive command line shell for doing things such as assigning trust level to keys.

The Enigmail plug-in for Thunderbird provides a pretty solid GUI for setting everything up, if I recall. You might want to install Thunderbird and Enigmail to set things up. Once you are setup, it's a setup and leave it kind of thing. You can drop Thunderbird/Enigmail and use it with OS X Mail, via the command line, or whatever.

[turtle777]

Originally Posted by besson3c 

The Enigmail plug-in for Thunderbird provides a pretty solid GUI for setting everything up, if I recall. You might want to install Thunderbird and Enigmail to set things up. Once you are setup, it's a setup and leave it kind of thing. You can drop Thunderbird/Enigmail and use it with OS X Mail, via the command line, or whatever.

Really, it will work with OS X MAil as well, set up via Thunderbird ?

Interesting. Have to take a look at that.

-t

[besson3c]

Originally Posted by turtle777 

Really, it will work with OS X MAil as well, set up via Thunderbird ?

Interesting. Have to take a look at that.

-t

Yup... gnupg and the various email clients are separate entities that are not tethered to each other. You can use any GUI you can find to setup gnupg. GPGMail (for OS X Mail), Enigmail (for Thunderbird) are just the bridge that allows the email client to speak to gnupg.

[turtle777]

Ah, ok, but you still need some sort of plugin for Apple Mail to handle it, right ?
It doesn't handle PGP right our of the box, AFAIR.

-t

[Doofy]

Originally Posted by besson3c 

The Enigmail plug-in for Thunderbird provides a pretty solid GUI for setting everything up, if I recall. You might want to install Thunderbird and Enigmail to set things up. Once you are setup, it's a setup and leave it kind of thing. You can drop Thunderbird/Enigmail and use it with OS X Mail, via the command line, or whatever.

Now you know why people don't bother using it. Most folks think that you have to go through all that crap you just explained to get it working, when for £63 (I was wrong earlier when I said £95) it's as easy as installing and using any other OS X app.

Blinded by geekery = "I won't bother with that then".

[besson3c]

Originally Posted by turtle777 

Ah, ok, but you still need some sort of plugin for Apple Mail to handle it, right ?
It doesn't handle PGP right our of the box, AFAIR.

-t

Yes, you need to install gnupg and GPGMail, and I believe GPGMail looks for gnupg in /usr/local/bin, so you may need to symlink to it depending on where you have it installed.

[besson3c]

Originally Posted by Doofy 

Now you know why people don't bother using it. Most folks think that you have to go through all that crap you just explained to get it working, when for £63 (I was wrong earlier when I said £95) it's as easy as installing and using any other OS X app.

Blinded by geekery = "I won't bother with that then".

If one wants to spend the money, great, I don't think there is anything wrong with that. If you are having a hard time justifying the expense though, with some work you can have a technologically sound alternative that is a complete replacement minus the graphical stuff. If you are looking to buy for your corporation, the commercial PGP is probably also a better fit since you can get it to do stuff like run your own key server, AFAIK.