11 ms·

SSLsplit – Transparent and scalable SSL/TLS interception

103 points by shayanbahal 12y ago

grzaks 12y ago
How is that different from sslsniff/sslstrip or webmitm from dsniff?
- bitexploder 12y ago
  Fundamentally it isn't all that different. One neat thing is the multiple NAT mechanisms supported. There are at least a half a dozen tools I can think of that do this. But it is a very nice, clean, small, high performance, written in C, MiTM proxy.
halayli 12y ago
Overall, very well written proxy. Just few nitpicks from browsing the code: https://github.com/droe/sslsplit/blob/master/pxyconn.c#L991-L1012 https://github.com/droe/sslsplit/blob/master/pxyconn.c#L991-... there is no guarantee that a space comes after the colon. These comparisons are better off with 1 character less. https://github.com/droe/sslsplit/blob/master/pxythrmgr.c#L124 https://github.com/droe/sslsplit/blob/master/pxythrmgr.c#L12... pthread_mutex_init can fail.
- xroche 12y ago
  On linux, pthread_mutex_init always returns 0. But yes, according to POSIX, the function might fail (the common response is generally to assert() in this case)
  - halayli 12y ago
    On linux, pthread_mutex_init can fail and return ENOMEM.
    - xroche 12y ago
      No, it can not, at least on non-obsolete GLIBC. http://fossies.org/linux/glibc/nptl/pthread_mutex_init.c#l_40 http://fossies.org/linux/glibc/nptl/pthread_mutex_init.c#l_4...
      - halayli 12y ago
        You should refer to the man pages not particular implementations.
ck2 12y ago
Well, that's horrifying to see exist as a sysadmin (though I am sure plenty of blackhats have such tools).
- conductor 12y ago
  The attacker must install a CA certificate on the users' computers so he can strip/split their SSL/TLS sessions. Frankly, that's the sysadmins who are using this type of tools the most for monitoring the browsing habits of the employees.
  - higherpurpose 12y ago
    No wonder NSA puts a greater deal of focus on hacking sysadmins. Once those individuals are hacked, the data floodgates open.
- eps 12y ago
  Every second antivirus appliance, "threat management" devices and other traffic scanning boxes had SSL splicing for years. I worked on such splicer for a large telecom equipment manufacturer back in 2005 and it wasn't exactly a blackhat tech even then.
- Nursie 12y ago
  Really? I wrote one of these a while ago, using a fake DNS rather than NAT. It's pretty trivial. Ths trick is getting the clients to accept your CA cert.
mazsa 12y ago
You can still detect that you are intercepted by checking fingerprints and/or green bar https://www.grc.com/ssl/ev.htm https://www.grc.com/ssl/ev.htm ... don't you?
- kobigurk 12y ago
  You will detect it even sooner - the root certificate that signs the certificates for the MITM is not recognized by your browser (unless you manually installed it). You will get a nice, big, red warning on every modern browser. The tool doesn't claim otherwise. An example useful usage is testing your app that communicates using SSL and seeing what's under the hood. In that case, you would install the root certificate manually so the app (or OS) wouldn't reject it.
  - verytrivial 12y ago
    It strike me that this tools works (or is perhaps designed to be?) a proof-of-concept for how things are done by those Agencies that keep showing up in the news. They will simply have (by hook-or-crook) several of the root cert private keys for the already-installed roots. There's a few dozen of them and any one will do. Just fry-up forged MITM certificates as needed. I doubt the target would even notice the tiny delay during handshake. As you say, no one checks fingerprints. I think fingerprints would only help if you had visited the site before without a MITM, and your SSL layer flagged changes under ALL circumstances, remembering the fried-up MITM cert will look 100% legit. I wonder if there is a privacy-protecting way to share certs/ids to detect these changes? (or is there one already?)
atmosx 12y ago
Isn't way easier to hijack the DNS requests of the victim, redirect the connection to a similar unknown domain which replicates the HTML code and fields offered by the originally requested website[1]? I think Metasploit can do something similar. I mean once you're in a position where using SSlstrip of SSLsplit or whatever, means that you gained access to the victim's LAN. That's why programs like DNSSEC or DNSCrypt should be installed by default on laptops who use often Free WiFi/Internet Caffes, etc. Funny thing is that, after all these years there's no way to implement an ARP poisoning mitigation policy that will protect all your clients no matter what OS they run (iOs/OSX, Linux/Android, BSD, Windows, Embedded, etc.). [1] What comes in mind is a ruby Sinatra application which reads the targeted website's output and creates css/haml output on-the-fly.
- bitexploder 12y ago
  If you have a captive audience, DNS, etc. can still be much more difficult. Think, malicious wifi hotspots where you can totally dominate everything about the victim's Internet access. But, generally, you are right, these tools require a certain level of access. I have never used one on an internal network assessment. I have done a small amount of arp poisoning on occasion, which you could then use a tool like ssl strip with, but my needs were different :)
- WatchDog 12y ago
  If you hijack DNS and the user tries to visit a HTTPS site you still need to do some sort of SSL interception.
bitexploder 12y ago
A few things for everyone to think about. This tool seems to be aimed more on the non-interactive side. There are several other good tools out there which do this, but most of them are not oriented towards performing software assessments. Webmitm does good for HTTP/HTTPS, as does Burp Suite (transparent non-proxy aware stuff). There are a lot of tools in this space. There are very few that will let you interactively debug non-HTTP(s) TCP and SSL. I released a tool with a colleague back in 2010 designed for assessing non-proxy aware (mostly non-HTTP(S)) applications. It was aimed at getting those hard to reach TCP and SSL wrapped TCP apps that other proxies don't let you work with interactively. Mallory does the exact same on the fly cert generation etc. As does Burp Suite a professional grade HTTP proxy, that can operate in transparent mode. I much prefer Burp to webmitm for day to day work. SSL Split also supports more NAT mechanisms than Mallory and most other tools (which just tend to be iptables/Linux aware). That is one of the real nice pieces of this code. We did add in a few neat things into Mallory. SSH MiTM that, when it works, lets you open up your own PTYs on the back of the user's SSH session. A GUI that lets you do binary level regex to play with traffic on the fly. HTTP plugins along with a Chrome extension for hijacking sessions and some other fun things, which were mostly just for demonstration of what a MiTM proxy can do and be. Making a MiTM proxy protocol aware can be very powerful. Mallory is still a little buggy and tricky to use, but it has served me well in performing blackbox app assessments for many years. http://bitexploder.com/BlackHat-USA-2010-Umadas-Allen-Network-Stream_Debugging-with-Mallory-wp.pdf http://bitexploder.com/BlackHat-USA-2010-Umadas-Allen-Networ... (Check this out if you want an overview of how to configure a system to support a tool like SSLSplit or Mallory) https://bitbucket.org/IntrepidusGroup/mallory https://bitbucket.org/IntrepidusGroup/mallory (reasonably up to date code, its not the easiest thing to set up, though).
taf2 12y ago
It would be really nice to see a write up on ways to prevent an attacker from effectively using this to intercept and decrypt traffic in this way... Like for example what are a few measures you could take to better protect a standard nginx or apache deployment?
- bitexploder 12y ago
  Use HSTS. Never use HTTP even to redirect to HTTPS. That is one of the surest ways to prevent users from getting hijacked without knowing it. If you are developing any kind of client application where you control the certificate authorities, throw them all away. Use certificate pinning in the client and reject any connections that present a certificate other than your known, pinned, certs. In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. This is a common, if paranoid, measure. Alert the user that their IP address has changed. A security warning is sufficient. Most likely they would be getting this attack in a coffee shop or some sort of untrusted Internet connection, so you have to tell them MiTM may be happening and they should be on alert. Defending from the server is hard.
  - sarciszewski 12y ago
    Note that binding sessions to a particular IP is not recommended if your site is designed to be Tor-friendly, as their IP rotates every few minutes.
  - bradyd 12y ago
    > In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. If your on a mobile device this may happen often. If you are connected to WiFi and travel out of range you will transition to cellular data, with a new IP. I frequently walk to my sister's house which is ~30 seconds away, looking at a website or app on my phone. During this walk I will transition from my WiFi, to cell, then to her WiFi. It also doesn't protect against your example threat of having your session stolen in a coffee shop, as all users on the same NAT subnet will all have the same public IP, so the server can't distinguish between them.
munin 12y ago
I'm not sure how this is "scalable", the "scalable" thing about tools like sslsniff was that earlier versions of SSL used a mechanism for key exchange where the MITM could cache the key negotiated between the client and server, and passively log the encrypted data paired with the intercepted key. decryption can then be done offline, in parallel. that scales, and the MITM component is resource-limited at the rate it can exchange packets. this requires an active attack, so the MITM is doing double duty for an intercepted session, since it has to pin two session keys together for each endpoint in an intercepted session and decrypt/encrypt. scaling that is harder, since for larger networks you need a relatively constant amount of processing power relative to the number of connections per second and stuff like AES-NI only goes so far. and then you investigate cryptographic coprocessing hardware or GPU acceleration and discover that data transfer speeds on commodity systems become a problem, and now to "scale" your attack you are building custom hardware that both needs to have the intense data plane capacity of high end switches and routers with the intense processing capability of HPC systems. it's not fun. and it's a hard and interesting challenge to write this kind of software and I commend the authors for doing so but I don't think that active attacks "scale" by definition. you're going to wind up with either a ridiculous amount of custom hardware or only intercepting some percentage of traffic.
shayanbahal 12y ago
This tool more than being a ssl interception tool, is useful to find privacy leaks such as Mac OS X Yosemite sharing of Spotlight searches with Apple. https://fix-macosx.com/ https://fix-macosx.com/
Animats 12y ago
The conventional wisdom is that it's not possible to detect MITM attacks other than by using some trusted path to validate the credentials from the other end. But that's not quite true. When an attacker decrypts with one key and re-encrypts with another, the encrypted bit stream changes. Both ends now have different encrypted bits. If they can somehow compare them, a MITM attack can be detected. One early secure telephone unit displayed a 2-digit number derived from the beginning crypto bits. Users were supposed to confirm, by voice, that both units showed the same number. An attacker would have to break into the voice stream and substitute voice words in a matching voice to prevent that detection. This illustrates what's possible. It's possible to force a MITM attacker to do considerable work (perhaps an arbitrarily large amount of work) to prevent both ends from comparing notes on what crypto bits they have. More than that, the endpoints can force the attacker to have to construct an arbitrarily complex lie in the form of impersonation of content. David Chaum (of DigiCash fame) claims to have developed a way to detect MITM attacks along these lines. See U.S. Patent Application #20060218636. The USPTO rejected the patent application, because of prior art from Microsoft (U.S. Patent # 7,475,421) for "Automatic Re-Authentication", which is about recovering disconnected Microsoft Terminal Server sessions securely and is limited to re-connection. So Chaum's approach seems to be unencumbered by patents. However, his explanation is almost incomprehensible. There's a thesis that explains it, though. http://www.cisa.umbc.edu/papers/theses/newton-thesis-2010.pdf http://www.cisa.umbc.edu/papers/theses/newton-thesis-2010.pd... Even that is heavy going. Here's a simple explanation of the concept. if both ends can compare some of their crypto bits, they can detect a naive MITM attack that's decrypting and re-encrypting at the transport level. A smarter MITM attack would detect and rewrite that exchange of info, even if it occurred at a higher protocol level, like HTTP. However, the effort required by the MITM attacker can be made very large, and the MITM attacker can be forced to introduce delay. An example approach would be to send an HTML or XML document which contains an item showing the N crypto bits that both ends should be seeing. Wrap the entire document with an item which has a cryptographic hash of the entire document, and send the hash BEFORE sending the document content. If the attacker just sends the HTML/XML through unchanged, the attack will be detected. If they change the item containing the N crypto bits, the hash will be wrong and the attack will be detected. If they generate a fake document with suitable crypto bits and hash, they have to do so before they've seen the entire content of the actual document. If they buffer up the entire document so they can modify the document, they introduce delay equal to the transmission time for the entire document. It should be possible to detect that delay. For concreteness, suppose the server does the SSL/TLS handshake, then sends the HTTP headers, which contain the cryptographic hash of the material to follow. This is done as fast as possible. The server then sends most of the rest of the document. But at the end of the document, it pauses until 3 seconds have elapsed from receipt of the HTTP request before sending the last hundred bytes or so. Most of the document will still render, although "onload" Javascript won't trigger yet. At the receiving end, the browser only allows the server 2 seconds from HTTP request to headers received. If the server can't keep up, the page will be treated as untrusted. This provides considerable MITM protection. An attacker must be able to fake page content to defeat this.

103 points by shayanbahal 12y ago

grzaks 12y ago

How is that different from sslsniff/sslstrip or webmitm from dsniff?

bitexploder 12y ago
Fundamentally it isn't all that different. One neat thing is the multiple NAT mechanisms supported. There are at least a half a dozen tools I can think of that do this. But it is a very nice, clean, small, high performance, written in C, MiTM proxy.

halayli 12y ago

Overall, very well written proxy. Just few nitpicks from browsing the code: https://github.com/droe/sslsplit/blob/master/pxyconn.c#L991-L1012 https://github.com/droe/sslsplit/blob/master/pxyconn.c#L991-... there is no guarantee that a space comes after the colon. These comparisons are better off with 1 character less. https://github.com/droe/sslsplit/blob/master/pxythrmgr.c#L124 https://github.com/droe/sslsplit/blob/master/pxythrmgr.c#L12... pthread_mutex_init can fail.

xroche 12y ago
On linux, pthread_mutex_init always returns 0. But yes, according to POSIX, the function might fail (the common response is generally to assert() in this case)
- halayli 12y ago
  On linux, pthread_mutex_init can fail and return ENOMEM.
  - xroche 12y ago
    No, it can not, at least on non-obsolete GLIBC. http://fossies.org/linux/glibc/nptl/pthread_mutex_init.c#l_40 http://fossies.org/linux/glibc/nptl/pthread_mutex_init.c#l_4...
    - halayli 12y ago
      You should refer to the man pages not particular implementations.

ck2 12y ago

Well, that's horrifying to see exist as a sysadmin (though I am sure plenty of blackhats have such tools).

conductor 12y ago
The attacker must install a CA certificate on the users' computers so he can strip/split their SSL/TLS sessions. Frankly, that's the sysadmins who are using this type of tools the most for monitoring the browsing habits of the employees.
- higherpurpose 12y ago
  No wonder NSA puts a greater deal of focus on hacking sysadmins. Once those individuals are hacked, the data floodgates open.
eps 12y ago
Every second antivirus appliance, "threat management" devices and other traffic scanning boxes had SSL splicing for years. I worked on such splicer for a large telecom equipment manufacturer back in 2005 and it wasn't exactly a blackhat tech even then.
Nursie 12y ago
Really? I wrote one of these a while ago, using a fake DNS rather than NAT. It's pretty trivial. Ths trick is getting the clients to accept your CA cert.

mazsa 12y ago

You can still detect that you are intercepted by checking fingerprints and/or green bar https://www.grc.com/ssl/ev.htm https://www.grc.com/ssl/ev.htm ... don't you?

kobigurk 12y ago
You will detect it even sooner - the root certificate that signs the certificates for the MITM is not recognized by your browser (unless you manually installed it). You will get a nice, big, red warning on every modern browser. The tool doesn't claim otherwise. An example useful usage is testing your app that communicates using SSL and seeing what's under the hood. In that case, you would install the root certificate manually so the app (or OS) wouldn't reject it.
- verytrivial 12y ago
  It strike me that this tools works (or is perhaps designed to be?) a proof-of-concept for how things are done by those Agencies that keep showing up in the news. They will simply have (by hook-or-crook) several of the root cert private keys for the already-installed roots. There's a few dozen of them and any one will do. Just fry-up forged MITM certificates as needed. I doubt the target would even notice the tiny delay during handshake. As you say, no one checks fingerprints. I think fingerprints would only help if you had visited the site before without a MITM, and your SSL layer flagged changes under ALL circumstances, remembering the fried-up MITM cert will look 100% legit. I wonder if there is a privacy-protecting way to share certs/ids to detect these changes? (or is there one already?)

atmosx 12y ago

Isn't way easier to hijack the DNS requests of the victim, redirect the connection to a similar unknown domain which replicates the HTML code and fields offered by the originally requested website[1]? I think Metasploit can do something similar. I mean once you're in a position where using SSlstrip of SSLsplit or whatever, means that you gained access to the victim's LAN. That's why programs like DNSSEC or DNSCrypt should be installed by default on laptops who use often Free WiFi/Internet Caffes, etc. Funny thing is that, after all these years there's no way to implement an ARP poisoning mitigation policy that will protect all your clients no matter what OS they run (iOs/OSX, Linux/Android, BSD, Windows, Embedded, etc.). [1] What comes in mind is a ruby Sinatra application which reads the targeted website's output and creates css/haml output on-the-fly.

bitexploder 12y ago
If you have a captive audience, DNS, etc. can still be much more difficult. Think, malicious wifi hotspots where you can totally dominate everything about the victim's Internet access. But, generally, you are right, these tools require a certain level of access. I have never used one on an internal network assessment. I have done a small amount of arp poisoning on occasion, which you could then use a tool like ssl strip with, but my needs were different :)
WatchDog 12y ago
If you hijack DNS and the user tries to visit a HTTPS site you still need to do some sort of SSL interception.

bitexploder 12y ago

A few things for everyone to think about. This tool seems to be aimed more on the non-interactive side. There are several other good tools out there which do this, but most of them are not oriented towards performing software assessments. Webmitm does good for HTTP/HTTPS, as does Burp Suite (transparent non-proxy aware stuff). There are a lot of tools in this space. There are very few that will let you interactively debug non-HTTP(s) TCP and SSL. I released a tool with a colleague back in 2010 designed for assessing non-proxy aware (mostly non-HTTP(S)) applications. It was aimed at getting those hard to reach TCP and SSL wrapped TCP apps that other proxies don't let you work with interactively. Mallory does the exact same on the fly cert generation etc. As does Burp Suite a professional grade HTTP proxy, that can operate in transparent mode. I much prefer Burp to webmitm for day to day work. SSL Split also supports more NAT mechanisms than Mallory and most other tools (which just tend to be iptables/Linux aware). That is one of the real nice pieces of this code. We did add in a few neat things into Mallory. SSH MiTM that, when it works, lets you open up your own PTYs on the back of the user's SSH session. A GUI that lets you do binary level regex to play with traffic on the fly. HTTP plugins along with a Chrome extension for hijacking sessions and some other fun things, which were mostly just for demonstration of what a MiTM proxy can do and be. Making a MiTM proxy protocol aware can be very powerful. Mallory is still a little buggy and tricky to use, but it has served me well in performing blackbox app assessments for many years. http://bitexploder.com/BlackHat-USA-2010-Umadas-Allen-Network-Stream_Debugging-with-Mallory-wp.pdf http://bitexploder.com/BlackHat-USA-2010-Umadas-Allen-Networ... (Check this out if you want an overview of how to configure a system to support a tool like SSLSplit or Mallory) https://bitbucket.org/IntrepidusGroup/mallory https://bitbucket.org/IntrepidusGroup/mallory (reasonably up to date code, its not the easiest thing to set up, though).

taf2 12y ago

It would be really nice to see a write up on ways to prevent an attacker from effectively using this to intercept and decrypt traffic in this way... Like for example what are a few measures you could take to better protect a standard nginx or apache deployment?

bitexploder 12y ago
Use HSTS. Never use HTTP even to redirect to HTTPS. That is one of the surest ways to prevent users from getting hijacked without knowing it. If you are developing any kind of client application where you control the certificate authorities, throw them all away. Use certificate pinning in the client and reject any connections that present a certificate other than your known, pinned, certs. In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. This is a common, if paranoid, measure. Alert the user that their IP address has changed. A security warning is sufficient. Most likely they would be getting this attack in a coffee shop or some sort of untrusted Internet connection, so you have to tell them MiTM may be happening and they should be on alert. Defending from the server is hard.
- sarciszewski 12y ago
  Note that binding sessions to a particular IP is not recommended if your site is designed to be Tor-friendly, as their IP rotates every few minutes.
- bradyd 12y ago
  > In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. If your on a mobile device this may happen often. If you are connected to WiFi and travel out of range you will transition to cellular data, with a new IP. I frequently walk to my sister's house which is ~30 seconds away, looking at a website or app on my phone. During this walk I will transition from my WiFi, to cell, then to her WiFi. It also doesn't protect against your example threat of having your session stolen in a coffee shop, as all users on the same NAT subnet will all have the same public IP, so the server can't distinguish between them.

munin 12y ago

I'm not sure how this is "scalable", the "scalable" thing about tools like sslsniff was that earlier versions of SSL used a mechanism for key exchange where the MITM could cache the key negotiated between the client and server, and passively log the encrypted data paired with the intercepted key. decryption can then be done offline, in parallel. that scales, and the MITM component is resource-limited at the rate it can exchange packets. this requires an active attack, so the MITM is doing double duty for an intercepted session, since it has to pin two session keys together for each endpoint in an intercepted session and decrypt/encrypt. scaling that is harder, since for larger networks you need a relatively constant amount of processing power relative to the number of connections per second and stuff like AES-NI only goes so far. and then you investigate cryptographic coprocessing hardware or GPU acceleration and discover that data transfer speeds on commodity systems become a problem, and now to "scale" your attack you are building custom hardware that both needs to have the intense data plane capacity of high end switches and routers with the intense processing capability of HPC systems. it's not fun. and it's a hard and interesting challenge to write this kind of software and I commend the authors for doing so but I don't think that active attacks "scale" by definition. you're going to wind up with either a ridiculous amount of custom hardware or only intercepting some percentage of traffic.

shayanbahal 12y ago

This tool more than being a ssl interception tool, is useful to find privacy leaks such as Mac OS X Yosemite sharing of Spotlight searches with Apple. https://fix-macosx.com/ https://fix-macosx.com/

Animats 12y ago

The conventional wisdom is that it's not possible to detect MITM attacks other than by using some trusted path to validate the credentials from the other end. But that's not quite true. When an attacker decrypts with one key and re-encrypts with another, the encrypted bit stream changes. Both ends now have different encrypted bits. If they can somehow compare them, a MITM attack can be detected. One early secure telephone unit displayed a 2-digit number derived from the beginning crypto bits. Users were supposed to confirm, by voice, that both units showed the same number. An attacker would have to break into the voice stream and substitute voice words in a matching voice to prevent that detection. This illustrates what's possible. It's possible to force a MITM attacker to do considerable work (perhaps an arbitrarily large amount of work) to prevent both ends from comparing notes on what crypto bits they have. More than that, the endpoints can force the attacker to have to construct an arbitrarily complex lie in the form of impersonation of content. David Chaum (of DigiCash fame) claims to have developed a way to detect MITM attacks along these lines. See U.S. Patent Application #20060218636. The USPTO rejected the patent application, because of prior art from Microsoft (U.S. Patent # 7,475,421) for "Automatic Re-Authentication", which is about recovering disconnected Microsoft Terminal Server sessions securely and is limited to re-connection. So Chaum's approach seems to be unencumbered by patents. However, his explanation is almost incomprehensible. There's a thesis that explains it, though. http://www.cisa.umbc.edu/papers/theses/newton-thesis-2010.pdf http://www.cisa.umbc.edu/papers/theses/newton-thesis-2010.pd... Even that is heavy going. Here's a simple explanation of the concept. if both ends can compare some of their crypto bits, they can detect a naive MITM attack that's decrypting and re-encrypting at the transport level. A smarter MITM attack would detect and rewrite that exchange of info, even if it occurred at a higher protocol level, like HTTP. However, the effort required by the MITM attacker can be made very large, and the MITM attacker can be forced to introduce delay. An example approach would be to send an HTML or XML document which contains an item showing the N crypto bits that both ends should be seeing. Wrap the entire document with an item which has a cryptographic hash of the entire document, and send the hash BEFORE sending the document content. If the attacker just sends the HTML/XML through unchanged, the attack will be detected. If they change the item containing the N crypto bits, the hash will be wrong and the attack will be detected. If they generate a fake document with suitable crypto bits and hash, they have to do so before they've seen the entire content of the actual document. If they buffer up the entire document so they can modify the document, they introduce delay equal to the transmission time for the entire document. It should be possible to detect that delay. For concreteness, suppose the server does the SSL/TLS handshake, then sends the HTTP headers, which contain the cryptographic hash of the material to follow. This is done as fast as possible. The server then sends most of the rest of the document. But at the end of the document, it pauses until 3 seconds have elapsed from receipt of the HTTP request before sending the last hundred bytes or so. Most of the document will still render, although "onload" Javascript won't trigger yet. At the receiving end, the browser only allows the server 2 seconds from HTTP request to headers received. If the server can't keep up, the page will be treated as untrusted. This provides considerable MITM protection. An attacker must be able to fake page content to defeat this.