That's not a specific example related to TLS or encryption, it's a vague attack classification. The reason I'm asking the question is to find out if there is an actual issue, and so a vague answer like this cannot help our understanding any.

Oh well. OpenSSL apparently has a vulnerability too. sigh :-/

No. The word "reality" doesn't apply here, because what you're describing isn't what's being actually done for SMTP.

No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.

Actually it's quite common for email providers to support TLS transfers today. And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.

If you look at the mail headers for email you receive, you're likely to find "smtps" or "esmtps" in the Received: lines which indicates that it was sent via a TLS transfer. Most mailing list traffic is often done without TLS, though there are exceptions -- Debian's mailing lists still use TLS transfers, which is good.

I understand what you're trying to get at; you'd like to have a log of the failure. However unfortunately that wouldn't tell you what you needed to know in this case; if you did have logging on this, the result you'd get would be "client authenticated" even though it was possible that the authentication actually didn't succeed. :-(

The unfortunate truth is that software bugs happen, and bugs that report success are harder to find than bugs that cause a failure.

I think you mean ESMTPS. And no, usually TLS certificates are not checked by default (they can be, optionally); many TLS certificates used for ESMTPS are not signed by a CA, so there's nothing to check them against. There's also a new DANE protocol where domains that are using DNSSEC can specify TLS certificate details for mail in the DNS record for the domain, but this is currently not popular (supposedly only about 20 domains are using it). Other issues with this are that a number of DNS servers haven't implemented DNSSEC, and a number of MTAs haven't implemented the DANE protocol either.

And we don't want the situation where mail domains have to have thier TLS certificate signed by a CA, because that gets back into the mess of "which CAs are trustworthy" for mail purposes, paying fees for SSL certificate signatures, and so on. It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.

There are two distinct part of SSL/TLS; encryption and authentication. In this case it's only the authentication portion that has an issue, not the encryption portion. There are several places in which GnuTLS is used for encryption but not authentication such as MTA (email) transfers over TLS (at least most of the time).

As for why GnuTLS exists, AFAIK it's mainly because of licensing issues -- compiling a GPLv2+ program against OpenSSL gets into licensing troubles, so there needed to be a GPL compatible alternative.

Another (non-issue) example is MTA (email) transfers; typically on Linux systems MTAs such as Exim use GnuTLS for TLS transfers, but purposely don't do certificate verification (but can be specifically configured to do so).

This is still a serious security issue for anything that does use GnuTLS for certificate verification of course, but off the top of my head I don't have a specific example of where this is done on the Linux platform. [There probably is an example to be found somewhere though.]

No, definitely wasn't.

Thankfully I'm okay and I don't think I'm worse for wear. For a time I was worried that I might have gotten brain damage from it (I know a couple of people that got brain damage from high fevers), but after this happened I went back to college and was able to complete a masters degree in electrical engineering with a high GPA, so I think I'm fine. ;-)

I believe I was taking 2 200 mg pills every 6 hours for a full week straight. (Even if I had to get up in the middle of the night if necessary to take another 2 pills.) Unfortunately that's what it required to make the unbearable headache pain subside. I tried only taking 1 pill, that wouldn't cut it. I've never experienced a headache like that before or since.

Heat stroke also messes up your electrolytes too, so I had to eat bananas nuts and sports drinks for several days, during which everything tasted like metal until I got the electrolytes back. And during that time my face was still drooping from palsy, so drinking without spilling it out of my mouth onto my shirt was a challenge. I can look back on it now and laugh a bit, but at the time it was frightening. Also couldn't whistle, drinking from a straw was extremely difficult too because one side of my mouth couldn't close.

If you're only taking an Ibuprofin here and there I'm sure you won't run into what I did. ;-)

I ended up having temporary facial palsy (i.e. half my face drooped and didn't work) after taking Ibuprofin for a week for severe headache pain related to heat stroke. I also felt dizzy and sick while taking the Ibuprofin, but the headache pain without meds was unbearable. After the headache pain from effects of heat stroke passed I was able to stop taking Ibuprofin, and a week later the facal palsy went away. I can't know for sure that the Ibuprofin caused the palsy, but some number of people that take Ibuprofin report having palsy from it.

The nastiest thing about the facial palsy was that on the side of my face that had the palsy the eyelid didn't "auto-blink" anymore, so the eye would get dry. It was especially noticable on long drives. To wet the eye I would have to consciously close both eyes at once -- for whatever reason that still worked. It's a bit mentally draining to have to constantly remember to close both eyes to wet them.

Hopefully you'll never run into this problem.

...

I'm mainly a Debian user, I'm also running Arch (in a VM, for Desktop use, with LUKS/cryptfs) and I'm very pleased with what I find with it so far. However one thing I do notice is that for Daemons, Arch upgrades seem to create ".pacnew" configuration files that sit alongside the original configuration files and outputting a warning, somewhat similar to how RPMs upgrade with ".rpmnew" files. I don't particularly like that -- I much prefer the prompts for administrator input that the APT/dpkg system brings up when .deb packages are upgraded that have user-modified configuration files. It's way too easy to miss the text warning that flies by on the screen saying there's a ".pacnew" file somewhere during a "pacman -Syu" upgrade.

The ZDNet reivew looks like it's of Ubuntu (i.e. with the Unity/Gnome interface) and doesn't seem to include KUbuntu (with the KDE4 interface).
Oh well.

I've yet to deal with an organization that has a GPG/PGP key for encrypting email to the organization. I don't think there's anything wrong with asking if they have one for encrypted email use, and so I think it's fine if you go ahead and do so, but I also don't expect that they have one.

What is more common is for the email MTA to support SMTP over TLS encrypted transfers. This can be verified using 'swaks' by testing each of the company's email servers listed in DNS one by one.

Finding the mail servers that cover a domain, for instance "nonsense.com":

$dig nonsense.com mx +short
10 nullmx.nonsense.com.

$swaks --ehlo testing.example.com --server nullmx.nonsense.com --tls -q TLS
=== Trying nullmx.nonsense.com:25...
=== Connected to nullmx.nonsense.com.
    220 mx ESMTP
        EHLO testing.example.com
    250-mx
    250-PIPELINING
    250-SIZE
    250 8BITMIME
*** Host did not advertise STARTTLS
    QUIT
    221 mx
=== Connection closed with remote host.

If the company email MTAs all DO support SMTPS, then perhaps that will be good enough. Even if the company did support GPG, there are certain things such as the Subject for the email which don't get encrypted, so SMTPS is important for those reasons anyway.

What's being acquired as evidence is very wide, and the NSA is famous for both large data storage and building a database of interpersonal connections. Regardless if the particular reason this information is being gathered, I'm working under the assumption that they're going to be using the information in whatever way they can, rather than for the original reason they're taking the data.

I find it really concerning that a secret court can order such wide data transfer to the NSA, and also order that the order be kept secret.

I think you've got the right idea.

Performance reviews are a good feedback mechanism for both the worker and the manager. It sounds to me like this particular programmer is feeling disconnected and as such doesn't seem to be taking account of the reporcussions for the way in which he's doing his work. Likewise this is bad for morale for everybody else, because they're having to clean up the mess. Nobody wins in this scenario -- the lone programmer is unhappy and the people he works with that want to work collaboratively are unhappy.

So the recommendation I have is to at least try to have a conversation with the programmer about these things and try to help him reconnect with his fellow employees. This is not a "blame session", it's an attempt to get the team reconnected so that they can work as a team. It sounds like the programmer isn't able to say "I don't understand this" and as such can't learn from his fellow employees because of perceived judgment or a sense of insecurity. This is common, and can lead to all kinds of bullying behavior -- but it's the underlying disconnection that's the biggest part of the problem, IMHO.

Hopefully this works. If not, hopefully the effort wil bring to light what needs to be done.