PageSourceSearch

https://www.krackattacks.com/

html krackattacks.com collected 2026-10-02 02:18:01 UTC 52,540 bytes, 601 lines download raw bytes

1<!DOCTYPE html>
2<html xmlns="http://www.w3.org/1999/xhtml" class="no-js">
3<head>
4	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
5	<title>KRACK Attacks: Breaking WPA2</title>
6	<meta name="keywords" content="WPA2, KRACK, key reinstallation, security protocols, network security, attacks, nonce reuse, handshake, packet number, initialization vector, Mathy Vanhoef" />
7	<meta name="description" content="This website presents the Key Reinstallation Attack (KRACK). It breaks the WPA2 protocol by forcing nonce reuse in encryption algorithms used by Wi-Fi." />
8	<link href="css/default.css" rel="stylesheet" type="text/css" media="all" />
9	
10	<link rel="shortcut icon" href="images/favicon.ico" type="image/x-icon">
11	<link rel="icon" href="images/favicon.ico" type="image/x-icon">
12	
13	<meta name="viewport" content="width=device-width, initial-scale=1.0">
14	
14<script type="text/javascript" src="js/jquery.min.js"></script>
14
15	
15<script type="text/javascript" src="js/modernizr.min.js"></script>
15
16	<!--[if lt IE 9]>
17	
17<script src="js/respond.src.js"></script>
17
18	<![endif]-->
19
20	<!-- Global site tag (gtag.js) - Google Analytics -->
vendor: 65 bytes, lines 20-21
20
21	<script async src="https://www.googletagmanager.com/gtag/js?id=
21G-M6G4EH4KXH
vendor: 13 bytes, lines 21-22
21"></script>
22	
22<script>
23	  
vendor: 137 bytes, lines 23-27
23window.dataLayer = window.dataLayer || [];
24	  function gtag(){dataLayer.push(arguments);}
25	  gtag('js', new Date());
26
27	  gtag('config', '
27G-M6G4EH4KXH
vendor: 5 bytes, lines 27-28
27');
28	
28</script>
28
29</head>
30<body>
31<div id="wrapper">
32	<div id="header-wrapper">
33		<div id="header" class="container">
34			<div id="logo">
35				<img src="images/logo-small.png" width="100%"/>
36			</div>
37			<div id="title">
38				<h1><b>K</b>ey <b>R</b>einstallation <b>A</b>tta<b>ck</b>s</h1>
39				<h2>Breaking WPA2 by forcing nonce reuse</h2>
40				
41				<h3>Discovered by <a href="https://twitter.com/vanhoefm">Mathy Vanhoef</a> of <a href="https://distrinet.cs.kuleuven.be/">imec-DistriNet</a>, KU Leuven, 2017</h3>
42			</div>
43			
44		</div>
45	</div>
46	<div id="menu-wrapper">
47		<div id="main-nav" class="container">
48			<span class="custom-mobile-menu-title" style="display: none;">Navigate page</span>
49			<ul class="menu">
50				<li class="page_item"><a href="#intro">Intro</a></li>
51				<li class="page_item"><a href="#demo">Demo</a></li>
52				<li class="page_item"><a href="#details">Details</a></li>
53				<li class="page_item"><a href="#paper">Paper</a></li>
54				<li class="page_item"><a href="#tools">Tools</a></li>
55				<li class="page_item"><a href="#faq">Q&amp;A</a></li>
56			</ul>
57		</div>
58	</div>
59	<div id="page" class="container">
60	<div id="content">
61		<!-------------------- INTRO -------------------->
62
63		<a name="intro" ></a>
64		<h2 class="firsttitle">Introduction</h2>
65		<p>We discovered serious weaknesses in WPA2, a protocol that secures all modern protected Wi-Fi networks.
66		An attacker within range of a victim can exploit these weaknesses using <u>k</u>ey <u>r</u>einstallation <u>a</u>tta<u>ck</u>s (KRACKs).
67		Concretely, attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted.	
68		This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on.
69		<strong>The attack works against all modern protected Wi-Fi networks</strong>.
70		Depending on the network configuration, it is also possible to inject and manipulate data.
71		For example, an attacker might be able to inject ransomware or other malware into websites.</p>
72		
73		<p>The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations.
74		Therefore, any correct implementation of WPA2 is likely affected.
75		To prevent the attack, users must update affected products as soon as security updates become available.
76		Note that <strong>if your device supports Wi-Fi, it is most likely affected</strong>.
77		During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks.
78		For more information about specific products, consult the <a href="https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4">database of CERT/CC</a>, or contact your vendor.</p>
79		
80		<p>The research behind the attack will be presented at the <a href="https://acmccs.github.io/session-F3/">Computer and Communications Security (CCS)</a> conference, and at the <a href="https://www.blackhat.com/eu-17/briefings/schedule/#key-reinstallation-attacks-breaking-the-wpa2-protocol-8861">Black Hat Europe</a> conference. Our <a href="#paper">detailed research paper</a> can already be downloaded.</p>
81
82		<p><strong>Update October 2018</strong>: <a href="followup.html">we have a follow-up paper</a> where we generalize attacks,
83		analyze more handshakes,
84		bypass Wi-Fi's official defense,
85		audit patches,
86		and enhance attacks using implementation-specific bugs.</p>
87
88		<!-------------------- DEMO -------------------->
89		
90        <a name="demo" ></a>
91		<h2>Demonstration</h2>
92		<p>As a proof-of-concept we executed a key reinstallation attack against an Android smartphone.
93			In this demonstration, the attacker is able to decrypt all data that the victim transmits.
94			For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher.
95			This is because <strong>Android and Linux can be tricked into (re)installing an all-zero encryption key</strong> (<a href="#details-android">see below for more info</a>).
96			When attacking other devices, it is harder to decrypt all packets, although a large number of packets can nevertheless be decrypted.
97			In any case, the following demonstration highlights the type of information that an attacker can obtain when performing key reinstallation attacks against protected Wi-Fi networks:
98		</p>
99		<div class="demo-video">
100		<div class="demo-video-container">
101			<!-- <iframe width="853" height="480" src="https://player.vimeo.com/video/238827849" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe> -->
102			<iframe width="853" height="480" src="https://www.youtube-nocookie.com/embed/Oh4WURZoR98?rel=0&amp;showinfo=0&amp;vq=hd720" frameborder="0" allowfullscreen></iframe>
103		</div>
104		</div>
105		<p>Our attack is not limited to recovering login credentials (i.e. e-mail addresses and passwords).
106			In general, any data or information that the victim transmits can be decrypted. Additionally, depending on the device being used and the network setup, it is also possible to decrypt data sent towards the victim (e.g. the content of a website).
107			Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations.
108			<!-- https://docs.google.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4/edit#gid=1053404143 -->
109			For example, HTTPS was previously bypassed in <a href="https://pdfs.semanticscholar.org/48fc/8f1aa0b6d1e4266b8017820ff8770fb67b6f.pdf">non-browser software</a>,
110			in <a href="https://www.imperialviolet.org/2014/02/22/applebug.html">Apple's iOS and OS X</a>,
111			in <a href="https://arstechnica.com/information-technology/2015/04/android-apps-still-suffer-game-over-https-defects-7-months-later/">Android apps</a>,
112			in <a href="https://arxiv.org/ftp/arxiv/papers/1505/1505.00589.pdf">Android apps again</a>,
113			in <a href="https://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-through.html">banking apps</a>,
114			and even in <a href="https://arstechnica.com/information-technology/2017/01/majority-of-android-vpns-cant-be-trusted-to-make-users-more-secure/">VPN apps</a>.
115			</p>
116
117		<!-------------------- DETAILS -------------------->
118			
119		<a name="details" ></a>
120		<h2>Details</h2>
121		
122			<!-- TODO: So far, this 14-year-old handshake has remained free from attacks, and is even proven secure. However, we show that the 4-way handshake is vulnerable to a key reinstallation attack -->
123
124			<p>Our main attack is against the 4-way handshake of the WPA2 protocol.
125			This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network).
126			At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic.
127			Currently, all modern protected Wi-Fi networks use the 4-way handshake.
128			This implies all these networks are affected by (some variant of) our attack.
129			For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES.
130			<!-- TODO: flow -->
131			<strong>All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):</strong></p>
132		
133			<h3>Key reinstallation attacks: high level description</h3>
134			<p>In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key.
135			This is <strong>achieved by manipulating and replaying cryptographic handshake messages</strong>.
136			When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value.
137			Essentially, to guarantee security, a key should only be installed and used once.
138			Unfortunately, we found this is not guaranteed by the WPA2 protocol.
139			By manipulating cryptographic handshakes, we can abuse this weakness in practice.</p>
140		
141			<h3>Key reinstallation attacks: concrete example against the 4-way handshake</h3>
142			<p>
142As described in the <a href="#paper">introduction of the research paper</a>, the idea behind a key reinstallation attack can be summarized as follows.
143			When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key.
144			It will install this key after receiving message 3 of the 4-way handshake.
145			Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol.
146			However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment.
147			As a result, the client may receive message 3 multiple times.
148			Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol.
149			We show that <strong>an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake</strong>.
150			By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.
151			The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.</p>
152		
153			<!-- TODO: Once we also made a presentation, we can include a diagram / figure describing the attack -->
154		
155			<h3>Practical impact</h3>
156						
157			<p>In our opinion, the most widespread and practically impactful attack is the key reinstallation attack against the 4-way handshake.
158			We base this judgement on two observations.
159			First, during our own research we found that most clients were affected by it.
160			Second, adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies.
161			Decryption of packets is possible because a key reinstallation attack causes the transmit nonces (sometimes also called packet numbers or initialization vectors) to be reset to their initial value.
162			As a result, <strong>the same encryption key is used with nonce values that have already been used in the past</strong>.
163			In turn, this causes all encryption protocols of WPA2 to reuse <a href="https://en.wikipedia.org/wiki/Keystream">keystream</a> when encrypting packets.
164			In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream.
165			This keystream can then be used to decrypt messages with the same nonce.
166			When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. <a href="https://crypto.stackexchange.com/a/2250">English text can still be decrypted</a>).
167			<!-- TODO: We can mention encrypted message 4's are useful for this? -->
168			In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.
169			</p>
170			
171			<p>The ability to decrypt packets can be used to decrypt TCP SYN packets.
172			This allows an adversary to obtain the TCP sequence numbers of a connection, and <a href="https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack">hijack TCP connections</a>.
173			As a result, even though WPA2 is used, the adversary can now perform one of the most common attacks against open Wi-Fi networks: injecting malicious data into unencrypted HTTP connections.
174			For example, an attacker can abuse this to inject ransomware or malware into websites that the victim is visiting.</p>
175			
176			<p>If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic.
177			<b>Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets</b>.
178			Moreover, because GCMP uses the same authentication key in both communication directions, and this key can be recovered if nonces are reused, it is especially affected.
179			Note that support for GCMP is currently being rolled out under the name Wireless Gigabit (WiGig), and is expected to be <a href="http://www.grandviewresearch.com/press-release/global-wireless-gigabit-wigig-market">adopted at a high rate</a> over the next few years.</p>
180			
181			<p>The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked.
182			Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent <em>by</em> the client.
183			When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent <em>towards</em> the client.
184			Finally, most of our attacks also allow the replay of unicast, broadcast, and multicast frames.
185			For further details, see Section 6 of <a href="#paper">our research paper</a>.</p>
186			
187			<p>Note that our attacks <b>do not recover the password of the Wi-Fi network</b>. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake.</p>
188			
189			<a name="details-android" ></a>
190			<h3>Android and Linux</h3>
191
192			<p>Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux.
193			Here, the client will install an all-zero encryption key instead of reinstalling the real key.
194			This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time.
195			When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key.
196			Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability.
197			This makes it <strong>trivial to intercept and manipulate traffic sent by these Linux and Android devices</strong>.
198			<!-- TODO: Should double-check that carries don't mess with the wpa_supplicant version... -->
199			Note that currently <a href="https://developer.android.com/about/dashboards/index.html">50% of Android devices</a> are vulnerable to this exceptionally devastating variant of our attack.</p>
200
201			<a name="cves" ></a>
202			<h3>Assigned CVE identifiers</h3>
203			<p>The following Common Vulnerabilities and Exposures (CVE) identifiers were assigned to track which products are affected by specific instantiations of our key reinstallation attack:</p>
204			<ul>
205				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13077">CVE-2017-13077</a>: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.</li>
206				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13078">CVE-2017-13078</a>: Reinstallation of the group key (GTK) in the 4-way handshake.</li>
207				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13079">CVE-2017-13079</a>: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.</li>
208				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13080">CVE-2017-13080</a>: Reinstallation of the group key (GTK) in the group key handshake.</li>
209				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13081">CVE-2017-13081</a>: Reinstallation of the integrity group key (IGTK) in the group key handshake.</li>
210				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13082">CVE-2017-13082</a>: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.</li>
211				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13084">CVE-2017-13084</a>: Reinstallation of the STK key in the PeerKey handshake.</li>
212				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13086">CVE-2017-13086</a>: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.</li>
213				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13087">CVE-2017-13087</a>: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.</li>
214				<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13088">CVE-2017-13088</a>: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response  frame.</li>
215			</ul>
216			<p>Note that each CVE identifier represents a specific instantiation of a key reinstallation attack. This means each CVE ID describes a specific protocol vulnerability, and therefore <b>many vendors are affected by each individual CVE ID</b>. You can also read <a href="https://www.kb.cert.org/vuls/id/228519">vulnerability note VU#228519</a> of CERT/CC for additional details on which products are known to be affected.</p>
217			<p></p>
218		<!-------------------- PAPER -------------------->
219		
220		<a name="paper" ></a>
221		<h2>Paper</h2>
222		
223		<!-- TODO: Put our slides here as well, once I finished them -->
224		<p>Our research paper behind the attack is titled <a href="https://papers.mathyvanhoef.com/ccs2017.pdf">Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2</a> and will be presented at the <a href="https://www.sigsac.org/ccs/CCS2017/">Computer and Communications Security (CCS)</a> conference on <a href="https://acmccs.github.io/session-F3/">Wednesday 1 November 2017</a>.
225
226		<p>Although this paper is made public now, it was already submitted for review on 19 May 2017.
227		After this, only minor changes were made.
228		As a result, the findings in the paper are already several months old.
229		In the meantime, we have found easier techniques to carry out our key reinstallation attack against the 4-way handshake.
230		With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake.
231		In particular this means that <strong>attacking macOS and OpenBSD is significantly easier than discussed in the paper</strong>.</p>
232		
233		<p>We would like to highlight the following addendums and errata:</p>
234		
235		<h3>Addendum: wpa_supplicant v2.6 and Android 6.0+</h3>
236		
237		<p>Linux's wpa_supplicant v2.6 is also vulnerable to the installation of an all-zero encryption key in the 4-way handshake.
238		This was discovered by John A. Van Boxtel.
239		As a result, all Android versions higher than 6.0 are also affected by the attack, and hence can be tricked into installing an all-zero encryption key.
240		The new attack works by injecting a forged message 1, with the same ANonce as used in the original message 1, before forwarding the retransmitted message 3 to the victim.
241		<!-- TODO: !!! Include more information about the cause and workings of this attack !!! -->
242		</p>
243				
244		<h3>Addendum: other vulnerable handshakes</h3>
245		<p>After our initial research as reported in the paper, we discovered that the TDLS handshake and WNM Sleep Mode Response frame are also vulnerable to key reinstallation attacks.</p>
246		
247		<a name="errata"></a>
248		<h3>Selected errata</h3>
249		<ul>
250			<li>In Figure 9 at stage 3 of the attack, the frame transmitted from the adversary to the authenticator should say "ReassoReq(ANonce, SNonce, MIC)" instead of "ReassoResp(..)".</li>
251			<li>Section 3.1: figure 3 contains a simplified description of the state machine (not figure 2).</li>
252			<li>Section 4.2: "It is essential that the broadcast frame we replay is sent <strong>after</strong> (not before) the retransmission of group message 1". A similar change should be made in Section 4.3: "Again it is essential that the broadcast frame we want to replay is sent <strong>after</strong> (not before) the retransmission of group message 1".</li>
253		</ul>
254
255		<a name="citeme"></a>
256		<h3>Citation example and bibtex entry</h3>
257		<p>
257Please cite our research paper and not this website (or cite both). You can use the following example citation or bibtex entry:</p>
258		<div class="indent">
259			<p>Mathy Vanhoef and Frank Piessens. 2017. Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2. In Proceedings of the 24th ACM Conference on Computer and Communications Security (CCS). ACM.</p>
260			<pre class="code">@inproceedings{vanhoef-ccs2017,
261  author        = {Mathy Vanhoef and Frank Piessens},
262  title         = {Key Reinstallation Attacks: Forcing Nonce Reuse in {WPA2}},
263  booktitle     = {Proceedings of the 24th ACM Conference on Computer and Communications Security (CCS)},
264  year          = {2017},
265  publisher     = {ACM}
266}</pre>
267		</div>
268		
269		<!-------------------- Tools -------------------->
270			
271		<a name="tools"></a>
272		<h2>Tools</h2>
273		<p>We have made scripts to detect whether an implementation of the 4-way handshake, group key handshake, or Fast BSS Transition (FT) handshake is vulnerable to key reinstallation attacks.
274		<a href="https://github.com/vanhoefm/krackattacks-scripts">These scripts are available on github</a>, and contain detailed instructions on how to use them.
275		</p>
276		<p>We also made a proof-of-concept script that exploits the all-zero key (re)installation present in certain Android and Linux devices.
277		This script is the one that we used in the <a href="#demo">demonstration video</a>.
278		It will be released once everyone has had a reasonable chance to update their devices (and we have had a chance to prepare the code repository for release).
279		We remark that the reliability of our proof-of-concept script may depend on how close the victim is to the real network.
280		If the victim is very close to the real network, the script may fail because the victim will always directly communicate with the real network, even if the victim is (forced) onto a different Wi-Fi channel than this network.
281		</p>	
282		
283		<!-------------------- Q&A -------------------->
284
285		<!--
286			- Is there an advantage in hiding the SSID of my network?
287			- Does the attacker need to be part of the network?
288		-->
289
290		<a name="faq" ></a>
291		<h2>Q&amp;A</h2>
292
293			<ul>
294				<li><a href="#highreslogo">Is there a higher resolution version of the logo?</a></li>
295				<li><a href="#wpa3">Do we now need WPA3?</a></li>
296				<li><a href="#changepw">Should I change my Wi-Fi password?</a></li>
297				<li><a href="#onlyaes">I'm using WPA2 with only AES. That's also vulnerable?</a></li>
298				<li><a href="#authors">You use the word "we" in this website. Who is we?</a></li>
299				<li><a href="#amivulnerable">Is my device vulnerable?</a></li>
300				<li><a href="#norouterupdates">What if there are no security updates for my router or access point? Or if it does not support 802.11r?</a></li>
301				<li><a href="#patch-client-and-ap">Is it sufficient to patch only the access point? Or to patch only clients?</a></li>
302				<li><a href="#ap-mitigations">Can we modify an access point to prevent attacks against the client?</a></li>
303				<li><a href="#howdiscovered">How did you discover these vulnerabilities?</a></li>
304				<li><a href="#securityproof">The 4-way handshake was mathematically proven as secure. How is your attack  possible?</a></li>
305				<li><a href="#attackarehard">Some attacks in the paper seem hard</a></li>
306				<li><a href="#channelmitm">If an attacker can do a man-in-the-middle attack, why can't they just decrypt all the data?</a></li>
307				<li><a href="#proximity">Does an attacker to have be near your network in order to attack it?</a></li>
308				<li><a href="#isitexploited">Are people exploiting this in the wild?</a></li>
309				<li><a href="#dontusewep">Should I temporarily use WEP until my devices are patched?</a></li>
310				<li><a href="#wifistandard">Will the Wi-Fi standard be updated to address this?</a></li>
311				<li><a href="#wifialliance">Is the Wi-Fi Alliance also addressing these vulnerabilities?</a></li>
312				<li><a href="#matchdotcom">Why did you use match.com as an example in the demonstration video?</a></li>
313				<li><a href="#preventthesebugs">How can these types of bugs be prevented?</a></li>
314				<li><a href="#whythename">Why the domain name krackattacks.com?</a></li>
315				<li><a href="#bugbounties">Did you get bug bounties for this?</a></li>
316				<li><a href="#relatedwork">How does this attack compare to other attacks against WPA2?</a></li>
317				<li><a href="#otherprotocols">Are other protocols also affected by key reinstallation attacks?</a></li>
318				<li><a href="#disclosure">When did you first notify vendors about the vulnerability?</a></li>
319				<li><a href="#openbsd">Why did OpenBSD silently release a patch before the embargo?</a></li>
320				<li><a href="#morevuln">So you expect to find other Wi-Fi vulnerabilities?</a></li>
321				<li><a href="#moreinfo">Where can I learn more about key reinstallation attacks?</a></li>
322			</ul>
323
324			<a name="highreslogo" ></a>
325			<h3>Is there a higher resolution version of the logo?</h3>
326			<p><a href="images/logo.png">Yes there is</a>. And a big thank you goes to <a href="https://www.behance.net/happyleedesigns">Darlee Urbiztondo</a> for conceptualizing and designing the logo!</p>
327
328			<a name="wpa3" ></a>
329			<h3>Do we now need WPA3?</h3>
330			<p>No, luckily <strong>implementations can be patched in a backwards-compatible manner</strong>.
331			This means a patched client can still communicate with an unpatched access point (AP), and vice versa.
332			In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time.
333			However, the security updates will assure a key is only installed once, preventing our attack.
334			So again, update all your devices once security updates are available.
335			Finally, although an unpatched client can still connect to a patched AP, and vice versa, <em>both</em> the client and AP must be patched to defend against all attacks!</p>
336			
337			<a name="changepw" ></a>
338			<h3>Should I change my Wi-Fi password?</h3>
339			<p>Changing the password of your Wi-Fi network does not prevent (or mitigate) the attack. So you do not have to update the password of your Wi-Fi network. Instead, you should make sure all your devices are updated, and 
339you should also update the firmware of your router. Nevertheless, after updating both your client devices and your router, it's never a bad idea to change the Wi-Fi password.</p>
340			
341			<a name="onlyaes" ></a>
342			<h3>I'm using WPA2 with only AES. That's also vulnerable?</h3>
343			<p>Yes, that network configuration is also vulnerable. The attack works against both WPA1 and WPA2, against personal and enterprise networks, and against any cipher suite being used (WPA-TKIP, AES-CCMP, and GCMP). So everyone should update their devices to prevent the attack!</p>
344			
345			<a name="authors" ></a>
346			<h3>You use the word "we" in this website. Who is we?</h3>
347			<p>I use the word "we" because that's what I'm used to writing in papers. In practice, all the work is done by me, with me being Mathy Vanhoef.
348			My awesome supervisor is added under an <a href="https://en.wikipedia.org/wiki/Academic_authorship#Honorary_authorship">honorary authorship</a> to the research paper for his excellent general guidance.
349			But all the real work was done on my own. 
350			So the <a href="http://phdcomics.com/comics.php?f=562">author list</a> of academic papers does not represent <a href="https://imgur.com/a/mKnnu">division of work</a> :)</p>
351			
352			<a name="amivulnerable" ></a>
353			<h3>Is my device vulnerable?</h3>
354			<p>Probably. Any device that uses Wi-Fi is likely vulnerable. Contact your vendor for more information, or consult <a href="https://github.com/kristate/krackinfo">this community maintained list on GitHub</a>.</p>
355			
356			<a name="norouterupdates" ></a>
357			<h3>What if there are no security updates for my router or access point? Or if it does not support 802.11r?</h3>
358			<p>
359			Routers or access points (APs) are only vulnerable to our attack if they support the Fast BSS Transition (FT) handshake, or if they support client (repeater) functionality.
360			First, the FT handshake is part of 802.11r, and is mainly supported by enterprise networks, and not by home routers or APs.
361			Additionally, most home routers or APs do not support (or will not use) client functionality.
362			In other words, your home router or AP likely does not require security updates.
363			Instead, it are mainly enterprise networks that will have to update their network infrastructure (i.e. their routers and access points).</p>
364			<!-- Note: there might also be other implementations bugs where replay of msg4/4 causes a key reinstallation attack -->
365			<p>That said, some vendors discovered implementation-specific security issues while investigating our attack.
366			For example, it was discovered that <a href="https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt">hostapd reuses the ANonce value</a> in the 4-way handshake during rekeys.
367			Concretely this means that, even if your router or AP does not support 802.11r, and even if it does not support client functionality, it might still have to be updated.
368			Contact your vendor for more details.
369			</p>
370			<p>Finally, we remark that you can try to mitigate attacks against routers and APs by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming).
371			Additionally, update all your other client devices such as laptops and smartphones.
372			If one or more of your client devices is not receiving updates, you can also try to contact your router's vendor and ask if they have an <a href="#ap-mitigations">update that prevents attacks against connected devices</a>.</p>
373
374			<a name="patch-client-and-ap"></a>
375			<h3>Is it sufficient to patch only the access point? Or to patch only clients?</h3>
376			<p>Currently, all vulnerable devices should be patched.
377			In other words, patching the AP will not prevent attacks against vulnerable clients.
378			Similarly, patching all clients will not prevent attacks against vulnerable access points.
379			Note that only access points that support the Fast BSS Transition handshake (802.11r) can be vulnerable.</p>
380			<p>
381			That said, it is possible to <a href="#ap-mitigations">modify the access point such that vulnerable clients (when connected to this AP) cannot be attacked</a>.
382			However, these modifications are different from the normal security patches that are being released for vulnerable access points!
383			So unless your access point vendor explicitly mentions that their patches prevent attacks against clients, you must also patch clients.</p>
384
385			<a name="ap-mitigations"></a>
386			<h3>Can we modify an access point to prevent attacks against the client?</h3>
387			<!-- TODO: Investigate WNM Sleep Mode Response frames in more detail, especially in combination with the group key handshake -->
388			<p>It's possible to modify the access point (router) such that connected clients are not vulnerable to attacks against the 4-way handshake and group key handshake.
389			Note that we consider these two attacks the most serious and widespread security issues we discovered.
390			However, these modifications only prevent attacks when a vulnerable client is connected to such a modified access point.
391			When a vulnerable client connects to a different access point, it can still be attacked.</p>
392			<p>Technically, this is accomplished by modifying the access point such that it does not retransmit message 3 of the 4-way handshake.
393			Additionally, the access point is modified to not retransmit message 1 of the group key handshake.
394			The <a href="https://w1.fi/cgit/hostap/commit/?id=6f234c1e2ee1ede29f2412b7012b3345ed8e52d3">hostapd project has such a modification available</a>.
395			They are currently evaluating to which extend this impacts the reliability of these handshakes.
396			We remark that the client-side attacks against the 4-way handshake and group key handshake can also be prevented by retransmitting the above handshake messages using the same (previous) EAPOL-Key replay counter.
397			The attack against the group key handshake can also be prevented by letting the access point install the group key in a delayed fas
397hion, and by assuring the access point only accepts the latest replay counter (see <a href="#paper">section 4.3 of the paper</a> for details).
398			</p>
399			<p>On some products, variants or generalizations of the above mitigations can be enabled without having to update products.
400			<!-- TODO: Link to a more general overview of products instead of only mentioning one -->
401			For example, on some access points retransmissions of all handshake messages can be disabled, preventing client-side attacks against the 4-way and group key handshake (<a href="https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa#workarounds">see for example Cisco</a>).</p>
402
403			<a name="howdiscovered" ></a>
404			<h3>How did you discover these vulnerabilities?</h3>
405			<p>When working on the final (i.e. camera-ready) version of <a href="https://lirias.kuleuven.be/bitstream/123456789/572634/1/asiaccs2017.pdf">another paper</a>, I was double-checking some claims we made regarding OpenBSD's implementation of the 4-way handshake. In a sense I was slacking off, because I was supposed to be just finishing the paper, instead of staring at code. But there I was, inspecting some code I already read a hundred times, to avoid having to work on the next paragraph. It was at that time that a particular call to <a href="https://github.com/openbsd/src/blob/ca7fda7e2ae9fcf15b882d71bc910143e6b0d09b/sys/net80211/ieee80211_pae_input.c#L519">ic_set_key</a> caught my attention. This function is called when processing message 3 of the 4-way handshake, and it installs the pairwise key to the driver. While staring at that line of code I thought <i>&ldquo;Ha. I wonder what happens if that function is called twice&rdquo;</i>. At the time I (correctly) guessed that calling it twice might reset the nonces associated to the key. And since message 3 can be retransmitted by the Access Point, in practice it might indeed be called twice. <i>&ldquo;Better make a note of that. Other vendors might also call such a function twice. But let's first finish this paper...&rdquo;</i>. A few weeks later, after finishing the paper and completing some other work, I investigated this new idea in more detail. And the rest is history.</p>
406			
407			<a name="securityproof" ></a>
408			<h3>The 4-way handshake was mathematically proven as secure. How is your attack  possible?</h3>
409			<p>The brief answer is that the formal proof does not assure a key is installed only once. Instead, it merely assures the negotiated key remains secret, and that handshake messages cannot be forged.</p>
410			<p>The longer answer is mentioned in <a href="#paper">the introduction of our research paper</a>: our attacks do not violate the security properties proven in formal analysis of the 4-way handshake.
411			In particular, these proofs state that the negotiated encryption key remains private, and that the identity of both the client and Access Point (AP) is confirmed.
412			Our attacks do not leak the encryption key.
413			Additionally, although normal data frames can be forged if TKIP or GCMP is used, an attacker cannot forge handshake messages and hence cannot impersonate the client or AP during handshakes.
414			Therefore, the properties that were proven in formal analysis of the 4-way handshake remain true.
415			However, the problem is that the proofs do not model key installation.
416			Put differently, the formal models did not define when a negotiated key should be installed.
417			In practice, this means the same key can be installed multiple times, thereby resetting nonces and replay counters used by the encryption protocol (e.g. by WPA-TKIP or AES-CCMP).</p>
418
419			<a name="attackarehard" ></a>
420			<h3>Some attacks in the paper seem hard</h3>
421			<p>We have follow-up work making our attacks (against macOS and OpenBSD for example) significantly more general and easier to execute.
422			So although we agree that some of the attack scenarios in the paper are rather impractical, do not let this fool you into believing key reinstallation attacks cannot be abused in practice.</p>
423
424			<a name="channelmitm" ></a>
425			<h3>If an attacker can do a man-in-the-middle attack, why can't they just decrypt all the data?</h3>
426			<p>As mentioned in the demonstration, the attacker first obtains a man-in-the-middle (MitM) position between the victim and the real Wi-Fi network (called a <a href="https://lirias.kuleuven.be/bitstream/123456789/473761/1/acsac2014.pdf">channel-based MitM position</a>).
427			However, this MitM position does not enable the attacker to decrypt packets!
428			This position only allows the attacker to reliably delay, block, or replay <em>encrypted</em> packets.
429			So at this point in the attack, they cannot yet decrypt packets.
430			Instead, the ability to reliably delay and block packets is used to execute a key reinstallation attack.
431			After performing a key reinstallation attack, packets can be decrypted.</p>
432
433			<a name="proximity" ></a>
434			<h3>Does an attacker to have be near your network in order to attack it?</h3>
435			<p>An adversary has to be within range of both the client being attacked (meaning the smartphone or laptop) and the network itself.
436			This means an adversary on the other side of the world cannot attack y
436ou remotely.
437			However, the attacker can still be relatively far way.
438			That's because special antenna can be used to carry out the attack from <a href="https://www.mattparkinson.eu/designer-cantenna/">two miles</a> to up to <a href="https://leaksource.files.wordpress.com/2013/12/nsa-ant-nightstand.jpg?w=604&h=781">eight miles</a> in ideal conditions.
439			Additionally, the attacker is not competing with the signal strength of the real Wi-Fi network, but instead uses so-called Channel Switch Announcements to manipulate and attack the client.
440			As a result, it is possible to successfully carry out attacks even when far away from the victim.
441			</p>
442
443			<a name="isitexploited" ></a>
444			<h3>Are people exploiting this in the wild?</h3>
445			<p>We are not in a position to determine if this vulnerability has been (or is being) actively exploited in the wild. That said, key reinstallations can actually occur spontaneously without an adversary being present! This may for example happen if the last message of a handshake is lost due to background noise, causing a retransmission of the previous message. When processing this retransmitted message, keys may be reinstalled, resulting in nonce reuse just like in a real attack.</p>
446
447			<a name="dontusewep" ></a>
448			<h3>Should I temporarily use WEP until my devices are patched?</h3>
449			<p><strong>NO!</strong> Keep using WPA2.</p>
450
451			<a name="wifistandard" ></a>
452			<h3>Will the Wi-Fi standard be updated to address this?</h3>
453			<p>There seems to be an agreement that the Wi-Fi standard should be updated to explicitly prevent our attacks.
454			These updates likely will be backwards-compatible with older implementations of WPA2.
455			Time will tell whether and how the standard will be updated.</p>
456
457			<a name="wifialliance" ></a>
458			<h3>Is the Wi-Fi Alliance also addressing these vulnerabilities?</h3>
459			<p>For those unfamiliar with Wi-Fi, the <a href="https://en.wikipedia.org/wiki/Wi-Fi_Alliance">Wi-Fi Alliance</a> is an organization which certifies that Wi-Fi devices conform to certain standards of interoperability. Among other things, this assures that Wi-Fi products from different vendors work well together.</p>
460			<p><a href="https://www.wi-fi.org/securityupdate2017">The Wi-Fi Alliance has a plan</a> to help remedy the discovered vulnerabilities in WPA2. Summarized, they will:</p>
461			<ul>
462				<li>Require testing for this vulnerability within their global certification lab network.</li>
463				<li>Provide a vulnerability detection tool for use by any Wi-Fi Alliance member (this tool is based on my own detection tool that determines if a device is vulnerable to some of the discovered key reinstallation attacks).</li>
464				<li>Broadly communicate details on this vulnerability, including remedies, to device vendors. Additionally, vendors are encouraged to work with their solution providers to rapidly integrate any necessary patches.</li>
465				<li>Communicate the importance for users to ensure they have installed the latest recommended security updates from device manufacturers.</li>
466			</ul>
467			
468			<a name="matchdotcom" ></a>
469			<h3>Why did you use match.com as an example in the demonstration video?</h3>
470			<p>Users share a lot of personal information on websites such as match.com. So this example highlights all the sensitive information an attacker can obtain, and hopefully with this example people also better realize the potential (personal) impact. We also hope this example makes people aware of <a href="https://www.theguardian.com/technology/2017/sep/26/tinder-personal-data-dating-app-messages-hacked-sold">all the information these dating websites may be collecting</a>.</p>
471
472			<a name="preventthesebugs" ></a>
473			<h3>How can these types of bugs be prevented?</h3>
474			<p>We need more rigorous inspections of protocol implementations. This requires help and additional research from the academic community! Together with other researchers, we hope to organize workshop(s) to improve and verify the correctness of security protocol implementations.</p>
475
476			<a name="whythename" ></a>
477			<h3>Why the domain name krackattacks.com?</h3>
478			<p>First, I'm aware that KRACK attacks is a <a href="https://en.wikipedia.org/wiki/Pleonasm">pleonasm</a>, since KRACK stands for <u>k</u>ey <u>r</u>einstallation <u>a</u>tta<u>ck</u> and hence already contains the word attack. But the domain name rhymes, so that's why it's used.</p>
479
480			<a name="bugbounties" ></a>
481			<h3>Did you get bug bounties for this?</h3>
482			<p>Hackerone has awarded a bug bounty for our research under their Internet Bug Bounty (IBB) award program.</p>
483
484			<a name="relatedwork" ></a>
485			<h3>How does this attack compare to other attacks against WPA2?</h3>
486			<p>This is the first attack against the WPA2 protocol that doesn't rely on password guessing. Indeed, other attacks against WPA2-enabled network are against surrounding technologies such as <a href="http://archive.hack.lu/2014/Hacklu2014_offline_bruteforce_attack_on_wps.pdf">Wi-Fi Protected Setup (WPS)</a>, or are attacks against older standards such as <a href="http://papers.mathyvanhoef.com/asiaccs2013.pdf">WPA-TKIP</a>. Put differently, none of the existing attacks were against the 4-way handshake or against cipher suites defined in the WPA2 protocol. In contrast, our key reinstallation attack against the 4-way handshake 
486(and against other handshakes) highlights vulnerabilities in the WPA2 protocol itself.</p>
487
488			<a name="otherprotocols" ></a>
489			<h3>Are other protocols also affected by key reinstallation attacks?</h3>
490			<p>We expect that certain <em>implementations of other protocols</em> may be vulnerable to similar attacks. So it's a good idea to audit security protocol implementations with this attack in mind. However, we consider it unlikely that other <em>protocol standards</em> are affected by similar attacks (or at least so we hope). Nevertheless, it's still a good idea to audit other protocols!</p>
491
492			<a name="disclosure" ></a>
493			<h3>When did you first notify vendors about the vulnerability?</h3>
494			<p>We sent out notifications to vendors whose products we tested ourselves around 14 July 2017. After communicating with these vendors, we realized how widespread the weaknesses we discovered are (only then did I <em>truly</em> convince myself it was indeed a protocol weaknesses and not a set of implementation bugs). At that point, we decided to let <a href="https://cert.org/">CERT/CC</a> help with the disclosure of the vulnerabilities. In turn, CERT/CC sent out a broad notification to vendors on 28 August 2017.</p>
495
496			<a name="openbsd" ></a>
497			<h3>Why did OpenBSD silently release a patch before the embargo?</h3>
498			<p>OpenBSD <a href="https://marc.info/?l=openbsd-announce&m=150410604407872&w=2">announced an errata on 30 August 2017</a> that silently prevented our key reinstallation attacks.
499			More specifically, patches were released for both <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/6.0/common/041_net80211_replay.patch.sig">OpenBSD 6.0</a> and <a href="https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_net80211_replay.patch.sig">OpenBSD 6.1</a>.</p>
500			<p>We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: <i>&ldquo;In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging&rdquo;</i>. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.</p>
501
502			<a name="morevuln" ></a>
503			<h3>So you expect to find other Wi-Fi vulnerabilities?</h3>
504			<p><i>&ldquo;I think we're just getting started.&rdquo;</i> &nbsp;&mdash; Master Chief, Halo 1</p>
505
506			<a name="moreinfo" ></a>
507			<h3>Where can I learn more about key reinstallation attacks?</h3>
508			<p>Good technical information and comments:</p>
509			<ul>
510				<li><a href="https://www.youtube.com/watch?v=fOgJswt7nAc">LiveOverflow has an excellent video explaining the attack</a></li>
511				<li><a href="https://www.youtube.com/watch?v=mYtvjijATa4">Computerphile also made a video about the attack</a></li>
512				<li><a href="https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/">Matthew Green has a good blog post about KRACK and the causes of the vulnerability</a></li>
513				<li><a href="https://blog.mojonetworks.com/wpa2-vulnerability">Mojo Networks has a detailed blog posts on the attacks</a></li>
514				<li><a href="https://www.schneier.com/blog/archives/2017/10/new_krack_attac.html">Bruce Schneier also briefly discusses the attack</a></li>
515			</ul>
516			<p>Selected newspapers with high-level information:</p>
517			<ul>
518				<li><a href="http://www.bbc.com/news/technology-41635516">The BCC made a short video explaining the attack, and wrote an article about it</a></li>
519				<li><a href="https://outline.com/MHm5yw">The Wall Street Journal: Significant Flaw Discovered in Wi-Fi Security Protocol</a></li>
520				<li><a href="https://www.theguardian.com/technology/2017/oct/16/wpa2-wifi-security-vulnerable-hacking-us-government-warns">The Guardian: 'All wifi networks' are vulnerable to hacking, security expert discovers</a></li>
521				<li><a href="http://time.com/4983720/krack-attack-wpa2-wifi/">TIME: Everything With Wi-Fi Has a Newly Discovered Security Flaw. Here's How to Protect Yourself</a></li>
522				<li><a href="https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/">Ars Technica: Serious flaw in WPA2 protocol lets attackers intercept passwords and much more</a></li>
523				<li><a href="https://arstechnica.com/information-technology/2017/10/how-the-krack-attack-destroys-nearly-all-wi-fi-security/">Ars Technica: How the KRACK attack destroys nearly all Wi-Fi security</a></li>
524				<li><a href="https://www.theverge.com/2017/10/16/16481136/wpa2-wi-fi-krack-vulnerability">The Verge: Wi-Fi security has been breached, say researchers</a></li>
525				<li><a href="https://www.theverge.com/2017/10/16/16481252/wi-fi-hack-attack-android-wpa-2-details">
525The Verge: 41 percent of Android phones are vulnerable to 'devastating' Wi-Fi attack</a></li>
526				<li><a href="https://uk.reuters.com/article/us-cyber-wifi-flaw/researchers-uncover-flaw-that-makes-wi-fi-vulnerable-to-hacks-idUKKBN1CL1UE">Reuters: Researchers uncover flaw that makes Wi-Fi vulnerable to hacks</a></li>
527				<li><a href="https://www.forbes.com/sites/thomasbrewster/2017/10/16/krack-attack-breaks-wifi-encryption/#5f734a282ba9">Forbes: Update Every Device -- This KRACK Hack Kills Your Wi-Fi Privacy</a></li>
528				<li><a href="https://www.cnet.com/news/krack-wi-fi-attack-patch-how-microsoft-apple-google-responding/">CNET: KRACK attack: Here's how companies are responding</a></li>
529			</ul>
530
531		<!-------------------- END OF MAIN CONTENT -------------------->
532<div type="margin: 0px auto;">            
533</div>
534        </div>
535	</div>
536</div>
537
538<div id="copyright" class="container">
539	<p><a  rel="license" href="http://creativecommons.org/licenses/by/4.0/" style="letter-spacing: normal;">
540        Creative Commons Attribution 4.0 International License</a> | Design inspired by <a href="http://templated.co" rel="nofollow">TEMPLATED</a>.</p>
541</div>
542<script type="text/javascript">
543/**
544 * Mobile Menu
545 */
546 
547(function ($) {
548	function close_menu() {
549		$('a#menu_button').removeClass('responsive-toggle-open');
550		$('#menu_title').css('background', '');
551		// So menu still works after being used, and window is resized
552		$('.js #main-nav .menu').removeAttr('style');
553	}
554	var current = $('span.custom-mobile-menu-title').html();
555	$('#main-nav').append('<a id="menu_button"></a>');
556	$('#main-nav').prepend('<div id="menu_title">' + current + '</div>');
557	$('a#menu_button, #menu_title').click(function (e) {
558		e.stopPropagation();
559		$('#menu_title').css('background', '#008C9A');
560		$('.js #main-nav .menu').slideToggle(function () {
561			if ($(this).is(':visible')) {
562				$('a#menu_button').addClass('responsive-toggle-open');
563			}
564			else {
565				close_menu();
566			}
567		});
568	});
569	// Close the mobile menu when clicked outside of it.
570	$('html').click(function () {
571		// Check if the menu is open, close in that case.
572		if ($('a#menu_button').hasClass('responsive-toggle-open')) {
573			$('.js #main-nav .menu').slideToggle(function () {
574				close_menu();
575			});
576		}
577	});
578    
579    // Catch click events outside menu on iOS: https://gist.github.com/danott/855078
580    Modernizr.addTest('ipad', function () {
581        return !!navigator.userAgent.match(/iPad/i);
582    });
583    Modernizr.addTest('iphone', function () {
584        return !!navigator.userAgent.match(/iPhone/i);
585    });
586    Modernizr.addTest('ipod', function () {
587        return !!navigator.userAgent.match(/iPod/i);
588    });
589    Modernizr.addTest('appleios', function () {
590        return (Modernizr.ipad || Modernizr.ipod || Modernizr.iphone);
591    });
592
593    if (Modernizr.appleios) {
594        $("html").addClass("clickable");
595    }
596})(jQuery);
597
598</script>
vendor: 1 bytes, line 598
598
599<script type="module" src="https://static.cloudflareinsights.com/beacon.min.js/v31edd6df95cf4e85bb4c19e7a9bdbcba1788362987495" integrity="sha512-iIg7k2xntmwu6/uSb5tpc/hySgZc4eoL31yB29W6tJFo2akwjPWcEqnCEdJvGexCL0KEQwVYv5BlowfhVz26hg==" data-cf-beacon='{"version":"2024.11.0","token":"787485c844814da6829a64c897355479","r":1,"spa":2}' crossorigin="anonymous"></script>
599
600</body>
601</html>

Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.