Enron, for all their opulence or "most innovative" awards, was not the largest energy company in the country at the time of their collapse. Nokia on the other hand had #1 smartphone market share in 2010 and lost 75% of it in a year. The blog article (if you read it in full) claims that this is the largest one-year collapse by a Fortune 500 market leader in history. Enron does not contradict this claim.

Even with self-signed certs, you can't always get the certificates to match the URL. The problem is not the cost of the certificates. The biggest problem is a shortage of IPv4 addresses. Buying extra IP addresses is difficult to impossible in many cases. If you have only one IP address then you're stuck with one certificate, no matter what. You want two virtual servers? Tough luck. (Putting multiple servers on different ports doesn't work for lots of reasons, most notably firewalling.)

I can think of plenty of legitimate situations where one is forced to use a mismatched certificate. It's not even that insecure as long as you personally verify the key fingerprint the first time you connect.

The myth that small businesses need paid third-party certificates for their own email servers is false, destructive, and harmful to security. It's nothing more than Verisign propaganda to generate profit for themselves at the public's expense. I speak out against it every time I see it, and I hope that you can learn the truth, or if not, at least refrain from spreading misinformation.

I am a professional cryptography researcher, but very much a "real world" researcher rather than one of those theoreticians. I know what I'm talking about.

A third-party certificate is intended for the situation where two parties who don't know each other in advance want to authenticate each other's identity for encrypted communications. For example, if you are purchasing something from a public web site, chances are you have never personally met the website operators to authenticate their identity. In this situation, you need a trusted third party, which is what a certificate provides.

For a corporate email server, especially a small business server, you're simply not in the above situation. You own the server and the machine running the server software. You own the client and the machine running the client software. You are authenticating yourself to yourself. There is no unknown entity participating in this transaction. You do not need a third-party certificate for this! Even worse, by relying on a third party, you introduce a new single point of failure: if the third party screws up, an event which is totally beyond your ability to control, then your security is compromised.

In practice, it's even worse. Most web browsers have thousands of root certificates. If any one of those thousands of parties screws up, your security is compromised. (And this does happen in real life: look up Diginotar or Comodo.) So, by using a third party certificate, you've added thousands of unnecessary single points of failure, not just one, and all of them totally beyond your ability to control.

For a large organization, the number of interactions between unknown parties might be large enough to justify the overhead of using certificates. For a small business, certificates are worse than useless; they're actively insecure. They allow the government of Iran to attack you in ways that would not be possible otherwise (which is what happened with Diginotar). The best authentication method for small business email, bar none, is to delete your email client's entire root certificate store and manually load your own email server's self-signed public key into your own email client with your own eyes and hands. There is no authentication technology on the planet that is more secure than your own eyes and hands.

Android is Linux-based, but it's not GNU/Linux. Android and desktop Linux share very few system components. The shell, C library, filesystem layout, security model, etc. are all different in Android. Meego is (was) GNU/Linux, and most Linux geeks would feel much more at home in such an environment. In addition, for the average consumer, although Android is a very good system, Meego by all accounts reached entirely new heights of usability and refinement. Even now, with Nokia actively sabotaging Meego, the Meego platform still exceeds Windows Phone in sales by a very large margin. There is plenty of reason to be mad at Nokia for committing corporate suicide. Their actions go beyond mere incompetence to borderline financial fraud.

Android's success helps mitigate the pain, but honestly, I'd rather just have Meego. Too bad it's not sold here.

Nokia has a worthy software stack in Meego. The Nokia N9 is an absolute hit product. People are actually traveling to other countries to buy N9s! The N9 outsells all Lumia phones combined by 3 to 1, despite Nokia's active attempts to kill the Meego line (they wouldn't have released it at all if not for contractual obligations). There's only one thing Nokia has to do to produce a credible handset: start selling the N9 in more countries than just Nigeria and Bangladesh. They could do this tomorrow if they wanted. They own the factories, the software, and the hardware.

Nokia is using Windows because their CEO (a former Microsoft employee) is secretly taking orders from Microsoft and acting in Microsoft's best interests, not Nokia's.

Meego was capable of competing. It still is. Meego to this day outsells Windows Phone 3-to-1 despite Nokia putting ZERO effort (indeed negative effort) into promoting the Meego platform. Nokia had three high-end Meego-capable phones (N900, N9, N950) all with large, iPhone-like profit margins, and killed two of them before they even hit the market. All the reviews indicate that Meego surpassed even the iPhone in polish and usability.

Elop unilaterally buried Nokia's best weapon just because it happens to run Linux and Microsoft hates Linux. Elop may ostensibly be the Nokia CEO, but it's an open secret that he's still a pawn of his former employer Microsoft. Elop isn't even trying to save Nokia. He's actively destroying Nokia in order to give Microsoft an advantage.

Why Nokia's shareholders don't sue Elop for massive breach of fiduciary duty is beyond me.

Yes, they do lie, but on the other hand it's also common knowledge that satellite has unusable latency. The speed of light is a fundamental physical limit, and it takes that long for light to reach a GEO satellite and back. See this rant from 1996.

Uh, what? Verizon Galaxy Nexus? Is that recent enough for you? I'm not saying Verizon is a saint here, but it is possible if you choose wisely. GP is talking about rooting and roms which is definitely possible on the Verizion Galaxy Nexus.

You own the mail server, and you own the mail clients. The clients run on a device, in this case a mobile phone. You can physically bring the mobile phone into your office and manually load the correct public key. In effect, you perform the initial authentication with, literally, your own eyes and hands. There's nothing bad about accepting a self-signed cert for which you have manually verified the corresponding key.

Using your own root CA still involves authenticating the root CA. You still have the same problem of authentication for the CA, and you still have to solve it one way or another, most likely by manually loading the root CA key as above. For internal, intranet-only cryptographic keys, loading keys onto devices manually is absolutely the correct solution.

In a sufficiently small company (say 1-3 people), the overhead of a separate IT department is too great, and it's better to just educate the users in key management, or have a designated knowledgeable person handle this stuff. For large companies it may be better to run a root CA, but honestly, I'm not entirely convinced. Consider the example of SSH, which is almost the polar opposite of SSL. SSH by default uses plain public keys with no certificates, and has dominant market share within its category. When was the last time you ever heard of a successful man-in-the-middle attack against SSH? I certainly never have. Obviously SSH and SSL differ in many areas, but the point is that it is possible to handle authentication securely without certificates.

Security guru Bruce Schneier has consistently stated many times that complexity is the enemy of security. CAs add a layer of complexity. This complexity in and of itself undermines security. I think you need a really compelling case for CAs (such as public web sites) before it's worth considering bringing this complexity on board.

It's really frustrating to see people like you continually perpetuate these nonsense myths about SSL certificates.

A certificate from Verisign makes a lot of sense on a public web site. It makes a lot of sense to use a third-party certificate in any transaction or communication where the two parties involved do not know each other in advance. That's the purpose of a certificate: to certify that the other party (whom you have never met before) is whom he claims he is.

It makes absolutely zero sense whatsoever under any conceviable circumstances to use a third-party cert to authenticate between two parties who have already authenticated each other prior to their first communication. For example, if you are connecting your own email client to your own email server, it is ridiculously, mind-bogglingly insecure to rely on a third-party certificate to authenticate this transaction. Using a third-party certificate in this situation just adds an additional single point of failure, one that wouldn't exist otherwise. Actually, it adds many thousands of independent single points of failure all of which are outside of your control, since any one security breakdown at any of the thousands of certificate compaies such as Comodo or Diginotar will compromise your email.

The right way to authenticate your own server to your own client is with first-party public keys, not with third-party certificates. Unfortunately, the SSL standard does not support plain public keys, but self-signed certificates are a close alternative. This method is correct, easy, cheap, and provides the most security.

There is no way to put this nicely. The authors of the SSL standard were wrong in insisting on certificates in any and all situations. It's disappointing and dangerous to see that the general public has, without thinking, bought into the insecure and nasty myth that certificates are always better. Honestly, they're not always better. Sometimes they're worse, much worse. Please think about real world security threats and security needs instead of just mindlessly parroting false advertising for Verisign.

X over SSH is in fact easier to secure. It's obviously not easy to the point of never having to apply patches again, but it improves on RDP in a significant, nontrivial way: the GUI is decoupled from the network-facing service. The resulting small network-facing service is easier to audit and secure against attacks. It's important to appreciate the benefits provided by the Unix philosophy of one separate small program for each task.

The analysis contains some errors, although the errors are probably fixable and thus the overall result is probably correct. For example the "crossover gadget" (version 2) in the paper does not do what it claims. In SMB3 it's possible for a big mario entering from the bottom to break both blocks and crouch-jump into the left hand gap.

Regarding your larger point, I don't think video games are an especially compelling example of a critical survival skill that's well-suited to human brains. The classic examples are speech recognition and especially face recognition, which are VERY hard to do on computers. If I had to pick a hard problem that humans can solve better than computers, I'd pick music transcription. For polyphonic music (such as a whole orchestra), this is absolutely impossible for a computer, but any even semi-skilled rock guitarist can do this in their sleep, at least as far as picking out the melody, harmony, and rhythm.

The GP is correct. USPS is a lot more reliable than Canada Post.

I live in Canada right now, but I've lived in the US for most of my life. Here in Canada, I routinely receive misdelivered mail in my mailbox. For example, I'll get mail addressed to someone with a different street number but same street name, or same street number and different street name, or some combination of both. Empirically I estimate that about 1% of the mail I receive is intended for someone else. As there is nothing particularly special about my address or mail volume, one can extrapolate (at least locally where I live) to conclude that Canada Post misdelivers about 1% of all mail. By contrast, I have never seen this kind of error in US mail.

When law enforcement officers confiscate a computer, they usually (in the US at least) try to transport the computer without powering it down. Standard procedure is to plug a portable generator into the wall outlet powering the computer, unscrew the outlet, and take the whole apparatus (including wall outlet, generator, and computer) to the forensics lab, without interrupting power to the computer. If all the jacks in an outlet are in use, they will unscrew the wall outlet and splice the generator's power cables into the outlet.

The article and summary do mention situations where computers are powered down for transportation. These are exceptions. They are not the norm.

I'm one of the authors of that algorithm. You might be interested in my latest work: an improved cryptosystem based on elliptic curve isognies which seems to be more secure against quantum computers than previous isogeny-based schemes. (In particular, my algorithm for breaking the old isogeny-based schemes doesn't work against this new scheme.) Since posting the paper, we have improved the performance of the new scheme to the point where it is faster than RSA for the same (conjectured) level of security, even against classical computers (never mind quantum computers).

I am obviously biased, but I think my new scheme is the best candidate for quantum-resistant key exchange. It's faster than RSA, it uses shorter keys than RSA, and it's security is based on relatively standard results in elliptic curve theory compared to other systems that involve difficult-to-analyze problems on lattices. It is very much a classical cryptosystem with some nice features, which happens to be quantum-resistant. It's not some kind of cumbersome scheme which you would use only if you cared about quantum computers.

In general, I've given up on replying to Slashdot crypto articles, unless I have a personally relevant reason to do so (your post certainly qualifies). The general level of ignorance in the discussion is so stratospheric that it is painful to read. Even worse, the vast majority of commenters think that they know what they're talking about (they don't), and the vast majority of moderators mod up ignorant (but plausible sounding) drivel while ignoring the comments made by actual cryptographers.

The correct answer to the submitter's question is what you just said: there are plenty of quantum-resistant key-exchange protocols available, among them NTRU, McEliece, learning with errors, and my scheme. The submitter should also have asked about quantum-resistant digital signature schemes. Here the answer is much less reassuring: there is only one, namely, NTRU. This is a huge problem for crypto if we ever build a quantum computer, since authentication is at least as important as encryption. It's a real shame that this entire discussion is based on the wrong question.