Krack attack website claims this is a flaw in protocol:
The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected.
In hindsight, the bug is very obvious. The problem was that wpa state machines lacked a notion of “do I expect a new key to be installed right now or not”.
I’ve used openvpn and Ciscovpn in the past and really didn’t like the latency component to establishing a connection. What’s your experience with IPsec?
No worries. We will likely still patch on time of public announcement anyway.
We just cannot patch problems we don’t know about yet.
What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August.
We already complained back then that this was way too long and leaving people exposed.
Then he got CERT (and, thus, US gov agencies) involved and had to extend the embargo even further until today. At that point we already had the ball rolling and decided to stick to the original agreement with him, and he gave us an agreeing nod towards that as well.
In this situation, a request for keeping the problem and fix secret is a request to leave our users at risk and exposed to insiders who will potentially use the bug to exploit our users. And we have no idea who the other insiders are. We have to assume that information of this kind leaks and dissipates pretty fast in the security “community”.
We chose to serve the needs of our users who are the vulnerable people in this drama. I stand by that choice.
What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about a vulnerability, the shorter an embargo time the better.
From July 15 to today is about 90 days which is far from unreasonable for co-ordinated disclosure. Project Zero use a 90 days + 2 week for patch release in their policy.
Which still doesn’t sound nice, though. Over three months of hoping that nobody who was informed and has any malicious intent and that nobody rediscovers it and nobody that might have discovered it earlier.
Now while WPA2 will in most cases require you to be physically close to exploit a lot of remote vulnerabilities mean that anyone hearing about it has over three months to scan the whole internet. And that’s a process that might take just some hours with tools like zmap.
For stuff like finance, healthcare, etc. 3 months of “free access” seem everything but reasonable, regardless of what any project does.
Coordination is a good thing. Maybe however making this processes faster is a good idea. Currently people are assuming that all insiders (known or unknown) have just the best intents. This feels very unreasonable. As an entity intending to exploit vulnerabilities this is probably one of the first circles I’d want to get into.
I am not an OpenBSD user, but I think stsp/the OpenBSD project didn’t do anything wrong, by sticking to an original deadline, as well as considering the deadline as too long. At least for said vulnerability. It should be a per-case decision though, since routers aren’t browsers that you nowadays can just kick out updates for.
On the other hand this kind of behaviour tend to reduce trust with security researcher. They should not complain once they get notified last for the next critical security disclosure. Unless someone has proof this was exploited in the wild, patching a security bug involving many stakeholder might put your users first, but put all the other system’s users at risk.
How can anyone be certain that all of these many stakeholders are trustworthy
You don’t, but the call is not yours to make. If they see them as not trustworthy, it’s the security researchers to chose notify those stakeholder closer to the end of the embargo.
Find your own bug and choose to go full disclosure if you want to, but OpenBSD have no part in finding this security issue, they were trusted by someone else to hold on a patch (for 90 days FFS). By acting the way they did they only showed that they could not be trusted with this privileged information.
That sounds pretty weird, and it’s probably just not fetching your vote on the merged comments and a new vote will not add to your existing default upvote. Could you link one comment you’ve upvoted and one you haven’t, please?
I feel a bit stupid now. I shouldn’t be surprised by this. It was stupid of me to feel that I know anything about Wi-Fi.
Anyways. I expected that open Wi-Fi hot-spot (without a password) has communication encrypted between AP and clients. If I understand it correctly that’s not the case. Then I also expected that having simple password with WPA2 is working in similar way as I expected in the previous case. It seems that if someone knows the key (as they do in cafeteria for example) they can decrypt the traffic. As stated in this stackexchange answer.
So it seems that the only reasonable thing to do while using most of Wi-Fi networks out there is to use VPN.
It seems that if someone knows the key (as they do in cafeteria for example) they can decrypt the traffic.
If you update your wpasupplicant (or equivalent package for your OS) then this shouldn’t be true any more. You don’t have to wait for base stations to be patched in most cases.
So it seems that the only reasonable thing to do while using most of Wi-Fi networks out there is to use VPN.
No, using properly-patched TLS or SSH and avoiding making any plaintext connections is enough. Making connections without TLS/SSH was a bad idea even before this vulnerability was known, and it’s still a bad idea after the vulnerability is patched. It would still be a bad idea with a VPN.
If someone knows the password to the network they can set up an AP with the same SSID and password and trick you client into connecting to them. There are provisions for using public/private keys in WiFi auth, but they’re not implemented widely enough to be useful in practice.
If you’re on OpenBSD, don’t worry about this. Patched some weeks ago already:
https://marc.info/?l=openbsd-cvs&m=150410571407760&w=2
Also, this is NOT a protocol bug. The article is wrong about that.
This is an implementation bug.
Krack attack website claims this is a flaw in protocol:
The standard text is just vague.
In hindsight, the bug is very obvious. The problem was that wpa state machines lacked a notion of “do I expect a new key to be installed right now or not”.
TL;DR:
I use an always-on VPN on my android. Still waiting for attacks on IPsec…
Aha, seems to be a pretty good workaround indeed.
Are you using the built-in client? Do you have any recommendations regarding the VPN configuration?
Android’s built-in l2tp/IPsec VPN with OpenBSD and npppd(8) running as a server.
I’ve used openvpn and Ciscovpn in the past and really didn’t like the latency component to establishing a connection. What’s your experience with IPsec?
I found this note about OpenBSD issuing a silent patch ahead of the embargo date somewhat amusing:
No worries. We will likely still patch on time of public announcement anyway. We just cannot patch problems we don’t know about yet.
What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed.
Then he got CERT (and, thus, US gov agencies) involved and had to extend the embargo even further until today. At that point we already had the ball rolling and decided to stick to the original agreement with him, and he gave us an agreeing nod towards that as well.
In this situation, a request for keeping the problem and fix secret is a request to leave our users at risk and exposed to insiders who will potentially use the bug to exploit our users. And we have no idea who the other insiders are. We have to assume that information of this kind leaks and dissipates pretty fast in the security “community”.
We chose to serve the needs of our users who are the vulnerable people in this drama. I stand by that choice.
And, by the way, here is another part of the original patch, which we didn’t release until today: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_pae_input.c.diff?r1=1.30&r2=1.31
What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about a vulnerability, the shorter an embargo time the better.
There’s a couple of different interests at play.
For instance:
Researchers want to make a timed media splash.
Security agencies want to evaluate the problem and make sure they get patched before anyone else.
Vendors want time to prepare patches, yes, but that alone does not justify such a long delay.
Reviewing the patch, testing it, and preparing it for commit and publishing erratas took only a couple of hours of my free time.
From July 15 to today is about 90 days which is far from unreasonable for co-ordinated disclosure. Project Zero use a 90 days + 2 week for patch release in their policy.
Which still doesn’t sound nice, though. Over three months of hoping that nobody who was informed and has any malicious intent and that nobody rediscovers it and nobody that might have discovered it earlier.
Now while WPA2 will in most cases require you to be physically close to exploit a lot of remote vulnerabilities mean that anyone hearing about it has over three months to scan the whole internet. And that’s a process that might take just some hours with tools like zmap.
For stuff like finance, healthcare, etc. 3 months of “free access” seem everything but reasonable, regardless of what any project does.
Coordination is a good thing. Maybe however making this processes faster is a good idea. Currently people are assuming that all insiders (known or unknown) have just the best intents. This feels very unreasonable. As an entity intending to exploit vulnerabilities this is probably one of the first circles I’d want to get into.
I am not an OpenBSD user, but I think stsp/the OpenBSD project didn’t do anything wrong, by sticking to an original deadline, as well as considering the deadline as too long. At least for said vulnerability. It should be a per-case decision though, since routers aren’t browsers that you nowadays can just kick out updates for.
Thanks to you and yours for putting users first.
FWIW, I think you made the right choice. Appreciate the integrity and concern for users overriding the institutional politics.
On the other hand this kind of behaviour tend to reduce trust with security researcher. They should not complain once they get notified last for the next critical security disclosure. Unless someone has proof this was exploited in the wild, patching a security bug involving many stakeholder might put your users first, but put all the other system’s users at risk.
How can anyone be certain that all of these many stakeholders are trustworthy and won’t abuse the secret information they have?
You don’t, but the call is not yours to make. If they see them as not trustworthy, it’s the security researchers to chose notify those stakeholder closer to the end of the embargo.
Find your own bug and choose to go full disclosure if you want to, but OpenBSD have no part in finding this security issue, they were trusted by someone else to hold on a patch (for 90 days FFS). By acting the way they did they only showed that they could not be trusted with this privileged information.
It’s easy for you to say that, not having been in a situation where you had to actually make that choice yourself.
It seems you would trust the NSA/CIA to not abuse a bug like this? I wouldn’t.
Edit: Also, let me reiterate that: WE WERE GIVEN PERMISSION BY MATHY TO DO THIS.
Yeah, it seems weird of Mathy to give permission to release early, then punish (not notify as soon as others) anyway. What the hell?!
https://www.krackattacks.com/#details
Merge with https://lobste.rs/s/xun2wv/severe_flaw_wpa2_protocol_leaves_wi_fi ?
I merged the other story into this one. The other was earlier by a few hours, but I’d like to favor the primary source when it’s available.
I am able to upvote my own comments which came here from the merged thread. This is probably a bug in the lobsters code base, is it not?
EDIT: The UI makes it appear as if upvoting worked, but the score gets reset after a page reload.
That sounds pretty weird, and it’s probably just not fetching your vote on the merged comments and a new vote will not add to your existing default upvote. Could you link one comment you’ve upvoted and one you haven’t, please?
This is now tracked by an issue. Thanks for the nice repro, @mulander.
I tested on this one: https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_0klzsb
But as stated in my edit above, it appears to be a minor UI-only issue.
I am able to reproduce this. I upvoted https://lobste.rs/s/xun2wv/severe_flaw_wpa2_protocol_leaves_wi_fi#c_0klzsb which I remember also upvoting in the unmerged thread. The counter went up and the arrow went read. Reloaded and it’s back down by one and allowing me to vote again.
Or the other way around…
Eh, it’s the news post and this is the white paper’s site. I say leave them separate. This needs visibility.
I feel a bit stupid now. I shouldn’t be surprised by this. It was stupid of me to feel that I know anything about Wi-Fi.
Anyways. I expected that open Wi-Fi hot-spot (without a password) has communication encrypted between AP and clients. If I understand it correctly that’s not the case. Then I also expected that having simple password with WPA2 is working in similar way as I expected in the previous case. It seems that if someone knows the key (as they do in cafeteria for example) they can decrypt the traffic. As stated in this stackexchange answer.
So it seems that the only reasonable thing to do while using most of Wi-Fi networks out there is to use VPN.
Am I correct?
If you update your wpasupplicant (or equivalent package for your OS) then this shouldn’t be true any more. You don’t have to wait for base stations to be patched in most cases.
No, using properly-patched TLS or SSH and avoiding making any plaintext connections is enough. Making connections without TLS/SSH was a bad idea even before this vulnerability was known, and it’s still a bad idea after the vulnerability is patched. It would still be a bad idea with a VPN.
If someone knows the password to the network they can set up an AP with the same SSID and password and trick you client into connecting to them. There are provisions for using public/private keys in WiFi auth, but they’re not implemented widely enough to be useful in practice.
I think I might setup my Server to act as OpenVPN endpoint for my phone… and I do hope we get some alternative to WPA2 at some point.