The demo from the researcher clearly indicates a man-in-the-middle attack. It is shown in the video on his website around 1:54 https://youtu.be/Oh4WURZoR98
Hence, the client does connect to the malicious AP. You seem to claim the client does not need to connect to the fake AP?

You should have also read the detailed description of the attack, and not just watch the demonstration video. Now to your points. Yes, it is an MiTM type of attack (researchers called it channel-based MiTM attack). No, the victim does not connect to the rogue AP (and no attempt is made to trick it to connect to the rogue AP at the beginning). Instead, it is tricked to switch to the rogue AP once the connection with the real AP is established. And no, there's nothing the real AP can do to prevent this.

Apparently AP can mitigate this by "bending" the standard 4-way handshake and instead of re-transmitting message 3 de-authorize the client so the handshake starts all over again ... that would break standard behavior designed to happen on bad and unreliable connections but will effectively make the attack unsuccessful ... better way would be of course to patch the clients not to reinstall keys ...

Apparently AP can mitigate this by "bending" the standard 4-way handshake and instead of re-transmitting message 3...

It does not re-transmit anything during attack. It's an attacker who replays the message 3 that was originally transmitted by the real AP.

Apparently AP can mitigate this by "bending" the standard 4-way handshake and instead of re-transmitting message 3...

It does not re-transmit anything during attack. It's an attacker who replays the message 3 that was originally transmitted by the real AP.

It does actually ... the attacker is replaying retransmissions of message 3 of the 4-way handshake ... so without this re-transmissions to replay the attack would not be possible ... and if you are criticizing the others you should also familiarize yourself with how the attack actually works ...

It does actually ... the attacker is replaying retransmissions of message 3 of the 4-way handshake ... so without this re-transmissions to replay the attack would not be possible ...

Ok, got it. You're absolutely right here.

Still none of the (even patched) APs now do what you suggested to mitigate the attack (and is unlikely to ever do, as that will be a pure violation of the existing standards, whereas, as I understand, what the industry now aims at is to make wording in the standards stricter, but still fully preserve backwards compatibility). So getting back to the original post of Jeroen1000, and the following replies or mine and yours it is vital to understand that patching only AP gives you absolutely nothing in terms of KRACK attack mitigation.

To summarize, the client does connect to the fake AP. That's why the researcher enabled ip forwarding on his linux box.

Actually there are AP's that will do this (mitigate the 4-way handshake problem). I'm not sure it will break anything with compatibility but we administer a ton of AP's and they are running this firmware right now (I work at an ISP). We have not verified this as of yet but it's planned.

To summarize, the client does connect to the fake AP. That's why the researcher enabled ip forwarding on his linux box.

Actually there are AP's that will do this (mitigate the 4-way handshake problem). I'm not sure it will break anything with compatibility but we administer a ton of AP's and they are running this firmware right now (I work at an ISP). We have not verified this as of yet but it's planned.

There may be some APs with an already upgraded firmware to mitigate KRACK attack but I am unaware of any so maybe you could share what APs are you using.
The main problem can be that under low quality links clients would have to be reauthorized too often and if under attack clients would not be able to connect at all, but I am certain that most people would be OK with this ...
Also just to be clear on MikroTik APs mitigation is not yet available and the only option is to patch the clients and that maybe impossible especially with Android devices that probably will never receive a patch, so maybe a suggestion for MikroTik to develop something like this and make it available as an option when working as an AP ...

Also just to be clear on MikroTik APs mitigation is not yet available and the only option is to patch the clients and that maybe impossible especially with Android devices that probably will never receive a patch, so maybe a suggestion for MikroTik to develop something like this and make it available as an option when working as an AP ...

Also if anyone is interested here is a link for hostapd implementation of mitigation at AP side ...
https://w1.fi/cgit/hostap/commit/?id=6f ... 45ed8e52d3

Hello friends

Looks like MTU of OVPN server was changed after update. Symptoms:

@ router (mikrotik) to router (mikrotik) VPN tunnel.

1. Ping host behind vpn works on small packet about 1300
2. Ping x.x.x.x. -l2000 dosen't work (windows)
After change MTU from 1400 to 1500 (only server side) everything works great (ofcourse you have to change network mask).

One small note. There I don't have issues on MTU 1400 or 1500 using OVPN connect on Android to router (mikrotik)

Have nice week.
Maciej

Hi guys, is it possible to do AP-side mitigation with this version?