I wish that were so... unfortunately Windows still has the Desktop userbase majority by a wide margin, and that doesn't seem to be changing despite Microsoft's many steps towards making computer owners' lives more difficult. "Windows Genuine Advantage" that limits your ability to change hardware in a computer running Windows, licensing confusion concerning running Windows in a Virtual Machine, version confusion ("home", "professional", "enterprise", "ultimate", etc), UI confusion with Metro and the Office "banner"... and so on.

I wish Linux were "the answer" to this, but I've been running it on the Desktop since 1998 and I know it's not. A user trying to switch first has to go through a painful process of figuring out what programs they can use to do their daily tasks -- because they're not going to be running Internet Explorer or Outlook anymore, and the new programs have a different menu layout and (for the most part) different shortcut keys. If you've been working with a Linux desktop you've probably forgotten just how painful this transition was -- and it's not trivial. For people that are "stuck in their ways" and get anxious when they feel lost, this in itself is sometimes an insurmountable challenge.

Also the Linux ecosystem is very different, mostly relying on volunteer efforts with a few paid developers on the side. Being that this ecosystem represents less than 5% of the market, it's not an ecosystem that would be able to cope with the other 95%+ of the market suddenly needing support. And because it's mostly volunteers that help, users first need to figure out where to report issues (which isn't always easy), then there are issues concerning user demads vs helper pushback, sometimes leading to rudeness and communication breakdown, occasional elitism or ignoring problems, etc. It's "a different world" than Windows users are used to in that respect too.

And when you say "Or Linux", if the users given that advice knew to they'd ask "which one?" (i.e. which distribution?) Yeah... that problem too. Which window manager / desktop environment? That too. Etc.

MITM can be an issue. More detailed information about the state of things at the link below.

https://wiki.exim.org/lurker/m...

You've skipped over the PFS key exchange portion used in TLS.

https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...

Maybe the MITM exploit you're talking about is possible, I don't know.

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.