It's also probably worth acknowledging that many organizations do use MS-CHAPv2 for their inner authentication credentials, precisely because they want to depend on it for mutual authentication instead of managing/deploying a PKI.

Since the Defcon talk, I've gotten a ton of emails from people thanking me for making this available as a service, so that they can easily demonstrate why relying on MS-CHAPv2 for WPA2 mutual authentication is a bad idea to their organizations.

The article is correct, but the solution they outline is only "simple" in theory. Most organizations do not have a BYOD enforcement or onboarding process for their enterprise wireless networks, and they used to think MS-CHAPv2 made that OK.

MS-CHAPv2 is used by VPNs and can be used by RADIUS authentication services (to authenticate WIFI clients) but typically it won't be.

For almost all private individuals your WPA2 connection is still just as secure as it has ever been. For most businesses it is likely secure unless you're using a Microsoft RADIUS server for authentication (and even then as the article says the impact is almost nil).

Which isn't to say that the MS-CHAPv2 thing isn't a big deal: because it really is. It just doesn't have much to do with WIFI.

Flamebait title -- the answer at the end of the article is "No." :-P

Betteridge's Law of Headlines in action!

Does this really need to be brought up every single time a submission has a question in the title?

I think it's worth pointing out when the title is a blatant attempt to get more people to read it. If they'd just said "WPA2 Isn't Broken Due to Defcon Hacking" then a lot less people would click through. I'll give him credit for starting off with "Quick answer: no" though.

I'd say it's warranted in this situation.

I could put the answer in the title, but it would get edited back to OP's title.

Actually, it's the first line of the article.

As part of the new Baseline Requirements for public CAs, certificate authorities are not able to issue certificates for internal purposes after 2015.

This means that your client will have to have the certificate installed on it prior to authentication. So a random person connecting to your AP may be subject to an untrusted certificate, or require manual installation before connecting.

So.... in 2015, we might be fucked.

Can't you get around that by just using a real domain name? There's no requirement that the server be accessible externally.

There's no guarantee the CA won't revoke it if they find out you're using it for internal purposes.

That makes no sense - there is no security problem with using a legitimate certificate for a real domain for internal purposes.

I haven't heard about these Baseline Requirements before your post, but http://www.cabforum.org/Baseline_Requirements_V1.pdf mentions 2015 but only in the context of reserved IPs and "Internal Server Names", which is defined as "A Server Name that is not resolvable using the public DNS". That makes more sense, because there is no way to say who owns such a domain.

Am I missing something?

This article assumes self-signed certs anyway, and specifically addresses procedures for disseminating them.

The article mentions how to work with self-signed certs, but that is not the point. Many orgs don't run their own root CA because the cost of supporting all the devices just to auth securely is overwhelming, and just buying one cert from VeriSign is enough to keep it secure. Except when 2015 rolls around. If you maintain wireless networks for large enterprises, it's kind of a big deal.