Live data from Hacker News

Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

krackattacks.com

111–120 of 424 posts

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#111
post #105

Earlier quoted context omitted.

> the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it Sure, but eventually you get called out on it in a public forum, like this one, and people stop giving you goodies going forward. I would consider it acceptable practice to, when considering dealing with OpenBSD (or people who are close to them), (a) withhold vulnerabilities unti…

Hi, I am the person you are accusing of mischief. I didn't break any agreement. I agreed with Mathy on what to do, and that's what I did. The fact that Mathy decided to get CERT involved and subsequently had to extend the embargo has nothing to do with me. (edit: typo)

To be clear, I accuse you of nothing less than playing a rational response to the researcher's apparent "always coöperate" strategy. "Defect" in a prisoner's dilemma context does not mean "breach" in a legal one. (For example, an OPEC member defecting has zero legal consequences. It does, however, affect their standing in the next round of negotiations.)

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#112

As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.

Pray for a vendor patch. The fix landed today in the hostap repository:

https://w1.fi/cgit/hostap/commit/?id=a00e946c1c9a1f9cc65c729...

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#114

„submitted for review on 19 May 2017“ ... „OpenBSD was notified of the vulnerability on 15 July 2017“ Can anyone explain the timeline of releasing such significant security findings? Why is it disclosed to the public 1/2 year after submitting to review? I'd guess the (publicly funded) research behind it is a lot older than that.

The intent is to have as many fixes available as possible at the time knowledge of the flaw becomes widespread.

Of course.

From my understanding of research at public institutions there is a long period of time and steps between finding something interesting and submitting a paper for review.

Why not disclose the vulnerability first to concerned parties and then write up a fancy research paper? Why the other way round?

Only two explanations I could come up with: Either there must be a very short time frame between identification of the vulnerability and writing of the paper or there was further research needed. Or....I don't know

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#115
post #67

Earlier quoted context omitted.

You got everything wrong. If big vendors are unable to patch their proprietary products in an acceptable time, that shouldn't put others at risk. Users shouldn't choose their products... Think about it in a different way: What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out ab…

This is why embargoes have deadlines. To make the necessary trade-off between "patch as soon as you can, potentially jeopardising the safety of users -- even users of non-proprietary projects" and "wait for everyone to be ready before you patch -- which also jeopardises users". The embargo system deals with this by forcing everyone to agree on a date, and if someone patches after that date then too bad. You may disag…

3 months is more of a joke than a reasonable time, but one can argue about that if he wants...

> even users of non-proprietary projects

Actually many FOSS projects get only notified on the disclosure date.

Hiding the vulnerability for such a long time makes more harm good. The vulnerability can potentially be exploited by security agencies that necessarily know about them and could also be leaked to a bad actor by an employee of one the vendors.

Hopefully WPA2 isn't that important, but potentially security sensitive users trusted something that was known by some to be vulnerable for 3 months! Bad actors could have used it against them.

The embargo resulted in potentially bad actors knowing about the issue, but not vulnerable users.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#116
post #67

Earlier quoted context omitted.

You got everything wrong. If big vendors are unable to patch their proprietary products in an acceptable time, that shouldn't put others at risk. Users shouldn't choose their products... Think about it in a different way: What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out ab…

This is why embargoes have deadlines. To make the necessary trade-off between "patch as soon as you can, potentially jeopardising the safety of users -- even users of non-proprietary projects" and "wait for everyone to be ready before you patch -- which also jeopardises users". The embargo system deals with this by forcing everyone to agree on a date, and if someone patches after that date then too bad. You may disag…

I have seen and participated in this disclosure debate for 10 years now. I have come to the conclusion that, in the long run, the least harm approach is full disclosure. There isn't any wiggle room. There are no shades of grey. The whole coordinated response movement is misguided. There are some limited circumstances where it can make sense to delay disclosure, such as creating an imminent threat to human life, but generally full and nearly real time disclosure results in safer software sooner for end users without putting them at some unknown, but high risk level.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#117

Stop panicking (unless you need your daily dose of the End of the World drama). From the source: In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones. Source: https://www.k…

Some people don't want read all the articles and tend to panic. It's why if there's any security issue we need a list about action to reduce risk, when, how, etc. otherwise people still we dispute about it's feasible or not and then finally the journalist will explain how to fix the risk. I like to read the whole article but then sometimes it's very hard to check if it's truly feasible or it's just a panic mode, for example when wannacry come out the information was a mess.

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#118
the post https://www.theregister.co.uk/2017/10/16/wpa2_inscure_kracka... mentions:

> As Hudson notes, the attacker would have to be on the same base station as the victim, which restricts any attack's impact somewhat.

If I understand it correctly then there has to be a connection already present for the attack to work?

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#119
> For ordinary home users, your priority should be updating clients such as laptops and smartphones.

So even if you patch all the devices in your house/company/whetever you can't be safe... Then yours aunt's un-patched android connects into your wifi and put all your network in risk. Or maybe that not-so-old security camera or SmartTV that will never be patched.

Time to move all those guys to an isolated vlan...

Re: Key Reinstallation Attacks – Breaking WPA2 by Forcing Nonce Reuse

#120

As an Android user is there any mitigation for this other than ditching my handset and switching to an iPhone or waiting (hopelessly) for a patch from my vendor. This really does highlight the absolute disaster zone that the Android handset market has become as far as updates are concerned. I'm sure the Pixels will get a fix relatively quickly but almost every other Android user is going to be left in security limbo.

Currently the only mitigation is to constrain your browsing to properly configured https (SSL) web sites.
Post reply on HN