On 10/16/17 23:53, harry newton wrote:
He who is J.O. Aho said on Mon, 16 Oct 2017 21:08:48 +0200:

They do use a tool commonly used in man-in-the-middle attacks, to strip
away the tls and send the content to the client machine unencrypted. As
they did explain in the video, many don't check in their mobile devices
that they have tls communication or not and those they will be able to
carry out the attack to see the the login credentials in this example.

This has nothing to do with KRACK itself.

Thanks for explaining *how* they manage to unencrypt *some* encrypted web
sites but not others, as I wasn't sure how they did that.

You can think of it like

[client]-----[MITM HTTP-service]---[MITM client]---[HTTPS Site]

or if you want to keep encryption

[client]-----[MITM HTTPS-service]---[MITM client]---[HTTPS Site]

In the first case the client connect to the Man-in-the-middle (MITM)
over http, MITM then resends the data over HTTPS to the site the client
tried to connect to.

In the second example the MITM do allow the client to connect with
HTTPS, the certificate which the MITM has will not be the same as on the
site, so if the client don't verify the certificate, then the attack works.

If you want to read more in detail and better explained how MITM works,
please take a look at:
https://www.owasp.org/index.php/Man-...-middle_attack


I was wrong in assuming it was the KRACK attack, which seems to be that
they simply hijack the third of the four handshakes, usually from the
client side, and force it to be resent where in some cases, it's resent as
all zeroes where in other cases it's just resent as a known nonce.

Is that a decent summary or can you summarize the attack mode better?

I wouldn't say it's hijacked, as you can resend the third request
without knowing the first request. The request is sent to the client and
on the client side, if you have followed the specification and cleared
out the key already, then a zero-key used.
I think they did explain this well on the video.

--

//Aho