33

Apologies if this is already answered in the whitepaper, I'm not going to get chance to read it for a few days due to a hectic schedule, but I am already fielding questions from non-techies reading non-technical media news stories making them believe that we should unplug everything and go back to trading gold.

What I understand (and please correct me if I'm wrong) is that this essentially allows attackers to set up a MITM attack by forcing a new handshake between devices (yes, that's dumbed down), and that this is a flaw in the basic implementation of the encryption protocol, so it will require a firmware update to fix (yay for helping elderly family and neighbours update the firmware on their routers).

I don't see how this would also invalidate the encryption used as part of TLS, but I'm far from an expert on this.

Dark Hippo
  • 465
  • 4
  • 10
  • 1
    @d3vid this answer (https://security.stackexchange.com/questions/171356/consequences-of-the-wpa2-krack-attack?rq=1) suggests otherwise – Dark Hippo Oct 17 '17 at 13:03
  • indeed -- I have removed my comment – lofidevops Oct 17 '17 at 13:09
  • +1 for "non-technical media news stories making them believe that we should unplug everything and go back to trading gold", lol, media has *got* to get a grip! (not that gold is bad or anything, they just blow everything out of proportion) – NH. Oct 18 '17 at 15:24
  • @NH. Actually, if you believe the media, trading gold is a bad idea, we should probably just go back to deciding who owns things by hitting each other over the head with sticks ;) – Dark Hippo Oct 18 '17 at 15:37

4 Answers4

43

KRACK is on the Network layer of the OSI model, while TLS is on the Session layer. So no, they do not influence each other, provided that the client can not be tricked into using a non-TLS connection (SSLstrip).

The basic threat from KRACK is that it allows an attacker to decrypt all packages on the network layer that the victim sends / receives. This includes all cleartext communication (e.g. that which many email programs still employ, local network device connections, etc.).

This means that if you display the network key and an attack is seeing all your traffic they can simply make a full connection to your network and wreak havoc on it any way they see fit.

If there are other vulnerabilities in the implementation (e.g., what happens in Android 6), then the attacker can even manipulate packages in transit to the victim. (both encrypted and cleartext can be manipulated). However the attacker can not read its contents if the packets themselves are encrypted by a session layer protocol (e.g. TLS). This opens up the possibility to change key values or redirect the victim to an attackers site for infection.

So while it is a serious breach and must be solved as soon as possible, it should not compromise properly secured traffic. So use a VPN, HSTS, HPKP and ssh, to protect yourself and/or your users.

NH.
  • 1,004
  • 1
  • 9
  • 20
LvB
  • 8,217
  • 1
  • 26
  • 43
  • 2
    Nothing major, but HTST should be HSTS: HTTP Strict Transport Security. – BenjiWiebe Oct 17 '17 at 17:14
  • 2
    Friendly reminder that HSTS (without preload) and HPKP are Trust On First Use - meaning you aren't secured until **after** your first HTTPS connection with the server. They close a lot of holes, but not all of them, and they can create nightmares if implemented incorrectly. I highly recommend both headers but do a lot of research and testing before fully implementing them. You can accidentally DoS yourself if you screw them up. – Taul Oct 17 '17 at 20:51
  • Also `sslstrip+` works around HSTS. https://null-byte.wonderhowto.com/how-to/defeating-hsts-and-bypassing-https-with-dns-server-changes-and-mitmf-0162322/#Running_MITMf – Tim G Oct 17 '17 at 23:52
  • another minor correction: packets, not packages – user371366 Oct 18 '17 at 00:11
12

No, it doesn't affect TLS. In fact, using TLS encrypted sites (HTTPS) is helpful if you're worried about KRACK - an attacker would only be able to see which site is being accessed, but not which pages within the site, or any data which you send to the site.

There are some other recently announced attacks which may affect TLS, and which it's possible that some media coverage has merged the two.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • How would the attacker see which _site_ is being accessed if this is within the HTTP headers? _IP address_ maybe? – Greendrake Oct 18 '17 at 08:58
  • 2
    Most DNS queries would be visible, and if you look at a capture of a connection to a HTTPS site using SNI, you'll see the domain too (although not the path). – Matthew Oct 18 '17 at 09:19
7

The direct vulnerability of KRACK doesn't affect TLS/SSL encryption, however once the MITM is established SSLstrip can be used to strip HTTPS down to HTTP. This is shown in the official video demonstration where login credentials for match.com are sniffed from an Android device.

Joe
  • 2,734
  • 2
  • 12
  • 22
5

KRACK does not affect SSL/TLS.

WPA2 works on the data link layer while SSL/TLS works on the session layer. The example on https://www.krackattacks.com/ uses SSL strip to bypass SSL. However this only works on websites which are not configured to use HSTS, which a fair number of websites don't use: https://www.ssllabs.com/ssl-pulse/

Farhan.K
  • 151
  • 6