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.

  • 1
    @d3vid this answer (security.stackexchange.com/questions/171356/…) suggests otherwise
    – Dark Hippo
    Commented Oct 17, 2017 at 13:03
  • indeed -- I have removed my comment
    – lofidevops
    Commented Oct 17, 2017 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.
    Commented Oct 18, 2017 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
    Commented Oct 18, 2017 at 15:37

4 Answers 4


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.

  • 2
    Nothing major, but HTST should be HSTS: HTTP Strict Transport Security.
    – BenjiWiebe
    Commented Oct 17, 2017 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
    Commented Oct 17, 2017 at 20:51
  • Also sslstrip+ works around HSTS. null-byte.wonderhowto.com/how-to/…
    – Tim G
    Commented Oct 17, 2017 at 23:52
  • another minor correction: packets, not packages
    – user371366
    Commented Oct 18, 2017 at 0:11

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.

  • How would the attacker see which site is being accessed if this is within the HTTP headers? IP address maybe?
    – Greendrake
    Commented Oct 18, 2017 at 8: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
    Commented Oct 18, 2017 at 9:19

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.


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/

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .