Support End-to-End Encryption on the Web
The Wordfence Team would like to encourage website owners and Internet users to support end-to-end encryption on the Web. Today we are announcing that our official position is the following:
- Wordfence is a strong supporter of end-to-end encryption for the online community.
- We suggest that you avoid services that break end-to-end encryption by intercepting and decrypting traffic.
- We encourage website owners to implement HTTPS on their websites in a way that provides end-to-end encryption for their site visitors and customers.
- We encourage corporate network owners and CISOs to avoid products that perform HTTPS interception and break end-to-end encryption.
- We encourage site owners to avoid Cloud products that perform HTTPS interception and decryption, like Cloud WAFs.
What is end-to-end encryption?
When your web browser connects directly to a website using HTTPS, your connection is end-to-end encrypted. If the website is using a Cloud WAF or similar service that decrypts traffic to inspect it, your connection is not end-to-end encrypted because your traffic is decrypted at the cloud WAF, not at the website you are visiting.
Similarly if you are on an office network and the company is using an HTTPS interception product to secure the network, they are also decrypting your traffic before it reaches the destination. This is not end-to-end encryption.
End-to-end encryption never decrypts traffic between the browser and web server.
Why is end-to-end encryption important?
When your website visitors are visiting your site and see the green “Secure” indicator in their location bar with a lock icon, they have a reasonable expectation of privacy and security. Their expectation is that their communications are being conducted via HTTPS which verifies the identity of the server they are talking to and provides a secure communication channel from the browser to the web server.
Products that intercept HTTPS traffic break this security model without the website visitor realizing it. The site visitor continues to see the same security indicators in their web browser and are unaware that their connection is being intercepted and inspected.
In some cases the remote web server’s identity is no longer verified and error messages related to verification are hidden from the site visitor. The connection after the point of interception may also no longer be encrypted and the site visitor is also not made aware of this important fact.
How can I ensure that my website visitors have end-to-end encryption?
The good news is that providing end-to-end encryption is easy. Simply set up a website that uses HTTPS and don’t use any services that intercept traffic. A cloud WAF is an example of an HTTPS interception service.
If you use a CDN, ensure that you are serving static assets from the CDN and that you haven’t given the CDN your SSL key so that it can decrypt your customer traffic.
What are some of the problems with breaking end-to-end encryption?
Cloud WAF providers decrypt HTTPS traffic so that they can inspect it for exploits. The problems this introduces are:
- In some configurations they don’t re-encrypt the HTTPS traffic, leaving it to pass unencrypted over the internet.
- In some configurations they don’t verify the identity of the web server the visitor is communicating with and they hide this fact from the site visitor.
- In all configurations, traffic between a browser and website is decrypted for inspection on a server owned by a third party.
Corporate HTTPS interception products also decrypt HTTPS traffic to inspect it as part of a corporate security policy. This creates the similar problems which have been described in detail by the Software Engineering Institute at Carnegie Mellon University.
What are other experts saying?
US-CERT is the United States Computer Emergency Readiness Team. They are an organization within the US Department of Homeland Security. US-CERT has previously released Alert TA15-120A which explains how important it is to secure end-to-end communications. It also explains that when end-to-end encryption is broken, it enables potential MITM or man-in-the-middle attacks.
Yesterday US-CERT released Alert TA17-075A titled “HTTPS Interception Weakens TLS Security”. The alert includes:
“Many HTTPS inspection products do not properly verify the certificate chain of the server before re-encrypting and forwarding client data, allowing the possibility of a MiTM attack. Furthermore, certificate-chain verification errors are infrequently forwarded to the client, leading a client to believe that operations were performed as intended with the correct server.”
In Alert TA17-075A, US-CERT is referring to HTTPS interception products that are used on corporate networks. We extend this point of view to any HTTPS interception products, including cloud WAFs.
Wordfence is recommending that website owners move away from cloud WAFs.
Cloud WAFs are HTTPS interception products. They decrypt traffic and in some configurations they either don’t re-encrypt it, or they don’t perform certificate validation to verify the identity of the website being visited. This breaks end-to-end encryption.
Wordfence’s official position is that we don’t recommend our customers use cloud WAFs. Instead we recommend that you use an endpoint security product which is installed on the website itself and does not rely on breaking end-to-end encryption.
If you are using a cloud WAF, we recommend you eliminate the cloud WAF and provide full end-to-end encryption for your website visitors. If you need a site accelerator, use a CDN provider to speed up your site. You can find a large list of CDN providers here.
Very few websites are ever targeted using a DDoS attack, but if you feel you may be the target of a DDoS attack, you can choose a hosting provider that provides DDoS mitigation at the endpoint, like WPEngine or Hetzner. Your existing host may provide it.
Conclusion
At Wordfence, we aren’t opposed to cloud WAFs because we make an endpoint security product. We make an endpoint security product because we are opposed to cloud WAFs.
Building Wordfence as a firewall and malware scanner that runs on the WordPress website itself (the endpoint) was a conscious choice by our engineering team. Running on the endpoint lets us make better blocking decisions using data like user identity, which cloud WAFs don’t have. It also means that we don’t break end-to-end encryption for site visitors.
We have recently seen how intercepting and decrypting web traffic can have catastrophic effects when the decrypted data leaks onto the public internet through software errors. We believe that making a strong commitment to end-to-end encryption is the best way to ensure the privacy and security of the online community.
Mark Maunder – Wordfence Founder & CEO.
Comments
10:17 am
So, am I to infer that an SSL configured through Cloudflare is not really 100% encryption?
10:52 am
Hi Brenda,
I'm not sure what you mean by 100% encryption. It is not end-to-end encryption, meaning that the traffic is decrypted halfway through the network and then may be re-encrypted to transit the rest of the public internet, or in some cases it isn't even re-encrypted.
Mark.
11:39 am
Are you suggesting that we don't use CDN's either? In my opinion, that is bonkers! Nobody gives a hoot about some blog posting Hello Kitty pictures, why use end-to-end? However, an website using WooCommerce, etc. that's a different scenario. ;)
11:45 am
No, as I mentioned in the post: "If you use a CDN, ensure that you are serving static assets from the CDN and that you haven’t given the CDN your SSL key so that it can decrypt your customer traffic."
By all means use a CDN. We do. Just don't use it to break end-to-end encryption.
11:28 pm
Hi
I have a SSL certificate on my hosted website with Hostgator and use Cloudflare SSL "SSL Full (strict)" option. They say in their support doc's "we may re-encrypt or send it as plain text. (full vs flex)" so like you say they break the encryption. So how do we use Cloudflare without breaking end-to-end encryption? Or do we not use Cloudflare if we have our SSL? Thanks Jane
10:07 am
You can't use Cloudflare without them decrypting your traffic on their servers.
4:30 pm
Brenda - it depends on how you configure Cloudflare. Cloudflare offers 3 different types of encryption:
1) "Flexible" -- the connection between Cloudfare & the user's browser is encrypted, but the connection between Cloudflare & the web host is not.
2) "Full" - the connection between Cloudflare & the user's browser is encrypted, and the connection between Cloudflare and the web host is also encrypted, but Cloudflare does not confirm validity of the host's certificate chain.
3) "Full (Strict)" - the connection between Cloudflare & the user's browser is encrypted, and the connection between Cloudflare and the web host is also encrypted, and Cloudflare also confirms the validity of the host's certificate.
Here's a blog post from Cloudflare explaining how the "Strict" option protects against MITM attacks: https://blog.cloudflare.com/introducing-strict-ssl-protecting-against-a-man-in-the-middle-attack-on-origin-traffic/
Cloudflare does provide free downloadable certificates that can be installed on the host server, so the post here does provide a good reason why a web manager should set up the strict protocol if possible. For business uses, there are higher end premium plans from Cloudflare that offer an even greater level of protection.
10:19 am
You guys perhaps need to sell a site security audit for those of us who don't really understand what you're saying in a blog post like this. Charge the same as a site cleaning, and include a site cleaning in the price if the site is hacked within, say 5 months of the security audit. Proactive instead of reactive!
10:22 am
Another great article to help the Wordpress community for which I - and I know others - are very grateful.
Cloudflare is down as a CDN but is this a Cloud WAF as well or am I getting confused between the 2 ?
10:54 am
Any cloud WAF needs to decrypt traffic to be able to inspect it for exploits, malware injection and malicious activity. So every cloud WAF breaks end-to-end encryption. They have to in order to inspect traffic to see if it's malicious.
10:33 am
I have been wondering for a while now if CDN's are really necessary. If your site is properly optimised and hosted at a reputable host, the latency from being hosted on the other side of the world from visitors should be negligible, what with the rate at which they are constantly upgrading connectivity around the world.
My question is this: Have CDN / Cloud WAF companies perhaps sold something that just isn't needed? Not that it is a bad idea, but as has been seen now it has come with some mentionable risks.
11:35 am
Someone is Australia is going to access your server (website) in Norway (for example) a lot slower than someone from England. If however you have a CDN with a node in Australia, it will be faster for the Australians as well.
12:43 pm
To be honest, I have never found any site load much faster on first load when using a CDN. There is a very very slight difference, but nothing really worth mentioning. Most people nowadays have a good connection, whether it be 4G or 1000MB fiber broadband.
I never use a CDN, but always make sure sites are properly optimized (particularly images). Personally, I don't see the need for a CDN these days.
10:43 am
Mark,
Interesting! I was just about to say, "Doesn't Wordfence make and market a WAF?" LOL.
So my question for clarity is this: I can understand for myself as someone who has a blog what this means and how to secure my website for secure end-to-end encryption. I'm currently re-designing and moving my new blog to a new hosting company and as part of that migration we will be installing an SSL certificate on the new site. However, what does that mean for many of us that would like to mitigate the possibility of US visiting a site where a 3rd party WAF appliance/software may be used unbeknownst to us?? How do I protect myself?
Currently I have HTTPS Everywhere installed on Chrome but is that enough?
Additionally, speaking to your comments in the conclusion. I've always wondered about how Wordfence is able to perform in this context. I would assume, with very little understanding of how the application works, that Wordfence intercepts traffic signatures and routes them to Wordfence servers in real-time where they are analyzed in some form or fashion, and then fed back to the application on my site where the application makes the necessary decisions. Would I be correct? And if so, isn't this an example of how a cloud WAF would operate?
10:57 am
Hi Dean,
There is a browser plugin you can get to see if a site uses Cloudflare. I don't know that one is available for other WAF providers.
We do not send traffic to our servers for analysis to make decisions about what to block. All that traffic stays on your own site. We have a firewall rule-set that makes the decisions locally on your site. We also have an IP blacklist and other tests we perform and all of that stays on your server. This all happens at the endpoint without breaking end-to-end encryption.
Mark.
12:23 pm
Mark,
Thanks for your response. Can you clarify? Why would I need a plugin to determine if a site uses Cloudflare?? Somewhat confused on your response.
2:16 pm
I was referring to a browser plugin. As opposed to a WordPress plugin. A browser plugin is a tool that you install in your browser.
Mark.
10:49 am
What about load balancers? I've used various load balancers in the past, from home-grown linux servers to Amazon Web Services. I'm aware that AWS doesn't properly check the back-end server certificate chain (allows expired certificates, or can be configured to pass traffic unencrypted), or at least it didn't last time I checked a couple years ago.
Load balancers can be a necessary part of the infrastructure, specifically for creating capacity on-the-fly. What do you recommend for sites that require multiple back-end servers, given the requirement of a single IP:port front-end endpoint?
11:01 am
Interesting question Mike. Load balancers, for those who don't know, spread load amongst several back-end web servers and are used to handle high load or provide high availability. They form part of a cluster of servers that is serving up a website. I consider that cluster "the endpoint". They all exist on the same local network, are administered by the same organization and the service is provided by that same org. So it's not a situation where a third party which is a separate organization and is geographically separate is decrypting traffic.
In the case of load balancers, the organization and network that is decrypting traffic is the org that the browser is expecting to talk to securely. So for example Paypal uses load balancers. They decrypt your traffic at the load balancer and spread it over the back-end network. You're OK with that because your expectation is that you are communicating with Paypal securely.
When a cloud WAF or other service MITMs traffic, you don't see that and your expectation is not that you are sharing your data with the cloud WAF provider AND paypal.
So in my opinion, load balancers are fine because they represent, and are operated by, the entity that you want to communicate with securely. Cloud products that MITM traffic are not OK.
11:37 am
Hi Mark,
You are correct for general assumptions about load balancers. The security behind those are up to the company operating the service. I've seen some really bad designs over the years and let's hope that we don't become victims of novice network engineers.
I have one question for you, how do you operate Wordfence behind a load balancer effectively? Do you have a document for that?
Kind regards,
Tony
11:46 am
Hi Tony,
It's quite simple. Please see this doc: https://docs.wordfence.com/en/Wordfence_options#How_does_Wordfence_get_IPs.
It explains how to ensure Wordfence is getting the correct visitor IP addresses. That's the only configuration item you need to pay attention to when using a load balancer or reverse proxy.
Mark.
11:15 am
There are security appliances that do MITM SSL traffic and ensure that SSL verification occurs before even MITM the traffic. One example is PaloAlto.
Layer7 filtering is important, but without MITM products it's basically useless.
12:02 pm
Hi Jordan,
Agreed, many products need to MITM SSL traffic. I think the debate arises when you consider which network those products are running on, which organization is MITMing the traffic, who has access to that decrypted traffic, which jurisdiction is the traffic being MITM'd in, and what important browser warnings are being hidden from the user e.g. "Half your connection is unencrypted" or "Certificate validation failed".
Mark.
11:31 am
What do the acronyms WAF, CISO, & CDN stand for? I'm gradually learning the lingo as I read your blog postings, but haven't learned these yet and they aren't defined in the first mention of this entry. If I know what they stand for, I can look up the meaning, I just know that one acronym can stand for a lot of things...
Thank you for your informative blog postings - I'm learning a lot and thankful I happened to install Wordfence when I created my first WordPress website. I didn't realize what a blessing it would be to have Wordfence installed.
12:00 pm
Hi Sarah,
Great idea for a blog post!! Security acronyms. I might publish that next week.
WAF == Web Application Firewall
CISO == Chief Information Security Officer (CSO is Chief Security Officer)
CDN == Content Distribution Network.
Bonus round:
MITM == Man in the middle attack. Intercepting traffic on an encrypted connection, usually to monitor it for malicious purposes.
2:46 pm
Thank you Mark! I come from an internal audit background, so knowing what acronyms stood for pretty important & they always had to be defined in our workpapers at first mention. I have moved to other aspects of work and the meanings of some acronyms now are completely different.
That would be great to have a blog posting on the security acronyms. Thank you!
11:32 am
I think the issue and takeaway is more that admins and content providers need to know and understand what is happening and test the products that they use. If your cloud WAF is not re-encrypting the traffic, then that is pretty easy to detect and probably a choice you made (a mistake).
With proper configuration and validation the benefits of having a CDN or a Cloud security product easily out weigh the risks. Mitigating DDOS attacks without something fronting the site is basically playing whack-a-mole. A WAF or CDN can absorb and deflect the traffic.
The statement end-to-end piece can be misleading as well. What is "THE END"?
Carrier Firewall? Cloud Load Balancer?
How about corporate proxies? Many industries require monitoring of employee traffic, without decryption they cannot.
Hardware WAF's? To preform deep packet analysis they must decrypt.
Is it ok to transmit traffic inside the firewall unencrypted? In some cases yes and some cases ill-advised.
Load Balancers? They must decrypt to do their jobs.
It seems like the alert should have been presented more as a Best Practices document than an alert.
Without products on the net like secure CDN's, cloud WAF's, and Load Balancers we would have never been able to scale our applications and maintain performance.
That being said I am a belt and suspender's kind of guy and suggest cloud, hardware, on server and application level security products (like WordFence) to allow each to do what they are best at.
The keys are Defense In Depth and Test and Verify.
11:57 am
Hi Bob,
Lots of discussion from other commenters here with similar questions that I've replied to. The cliff notes:
A CDN does not decrypt traffic. By all means, use one. Just don't give it your private SSL keys so it can MITM your traffic and break end-to-end encryption. We use a CDN.
DDoS mitigation can be performed by the hosting provider. You don't need a cloud WAF for that and it's important to note that cloud WAFs can be bypassed. See: https://www.wordfence.com/blog/2016/10/endpoint-vs-cloud-security-cloud-waf-bypass-problem/.
As I noted to another commenter, I consider the 'endpoint' in SSL communication to be the organization that you are trying to communicate with securely. So, as I noted to another commenter, if you're communicating with Paypal and your traffic has entered their network, I'm OK with it being decrypted by their load balancer to send to the back-end servers. I'm communicating securely with the org that I expect to. The problem arises when a third party is decrypting that traffic out on the Internet somewhere and I have no awareness of that.
Corporate HTTPS interception is what US-CERT was referencing when they put out their alert yesterday. Please see my reply to Ken Gilmour for my views on that.
So to summarize: Avoid intercepting HTTPS between the browser and the organization that user is communicating with. In the case of corporate HTTPS interception, you could view that as one organization communicating with another, in which case the traffic is only being decrypted on each org's network. The issue arises (as US-CERT points out) when the HTTPS interception product is hiding important security information from the browser, like broken certificates.
Mark.
11:32 am
I am not sure you are looking at all angles in relation to this. What about an Enterprise environment which uses Forward Proxy servers? Those Forward Proxies will break the SSL encryption (even with what you have suggested above), They do these for some very important reasons:
1. To detect malware hidden in encrypted SSL tunnels
2. To ensure employees are not leaking confidential client information
3. To enforce blocking of potentially harmful content.
Devices such as Bluecoat, Watchguard, Palo Alto etc perform these functions.
How do you propose an enterprise could have these protections without SSL interception?
11:50 am
Please see this alert from US-CERT dated yesterday: https://www.us-cert.gov/ncas/alerts/TA17-075A. They mention this exact issue and have a few recommendations for you.
I prefer the option of companies not MITM'ing their employee traffic. It creates a central point of compromise on the network with a huge amount of high value data passing through it. However, it's important to note that these MITM products are executing on the corporate network which is behind a firewall, not on the open internet like cloud WAF services. So it's a slightly different case.
Here's the punchline in yesterday's US-CERT alert:
Organizations using an HTTPS inspection product should verify that their product properly validates certificate chains and passes any warnings or errors to the client. A partial list of products that may be affected is available at The Risks of SSL Inspection [1]. Organizations may use badssl.com [3] as a method of determining if their preferred HTTPS inspection product properly validates certificates and prevents connections to sites using weak cryptography. At a minimum, if any of the tests in the Certificate section of badssl.com prevent a client with direct Internet access from connecting, those same clients should also refuse the connection when connected to the Internet by way of an HTTPS inspection product.
In general, organizations considering the use of HTTPS inspection should carefully consider the pros and cons of such products before implementing [1]. Organizations should also take other steps to secure end-to-end communications, as presented in US-CERT Alert TA15-120A [4].
6:13 am
end to end works fine for personal but employers need to know what is gong on within their networks. They have the right to inspect traffic and enforce corporate policies as they see fit jsut like you do on your own internal networks. With the liability of employee or employer actions being such a threat these days end to end is not the panacea it once was thought to be.
10:23 am
Hi Mark,
Fascinating and extremely relevant article!
I have a potential client for whom this may be very important.
Currently they have their site on Google Cloud DNS. I'm not very familiar with it and am wondering if you could provide any insight on Google's service as to endpoint protection... Or any other security issues when using them that you may be aware of.
Thanks again for doing "The Good Fight"!
10:08 am
Using Google's Cloud DNS service is fine. It doesn't cause your SSL traffic to be MITM'd (decrypted in the middle).
Mark.
2:43 pm
Hi,
Thanks for sharing this information. The subject of site security has been the "topic of the day" for me at the moment and I am constantly redirecting the strategy. It's quite confusing to be honest...I was going to use the Securi firewall service but am I correct in thinking that this is a cloud based WAF service?
Also can you please advise me of the CDN that you use and what settings if any you have made to ignore the https?
Many Thanks,
Tony
10:12 am
Yes Sucuri's WAF is a cloud WAF that decrypts traffic and then re-encrypts it.
We use Amazon's Cloudfront as a CDN for static assets. We don't use anything that MITM's traffic to non-static assets and sites.
8:38 am
IMHO, there are two different flows and recent alert from US-CERT speaks about the first case:
- MITM proxy products like PaloAlto use fake certs and open a new vector for attacks
- WAF services use good certs and I see no security risk here
10:14 am
Cloud WAFs MITM your traffic (decrypt it mid-flight and re-encrypt it for inspection). This is a problem in our opinion because it's a third party company decrypting traffic. They also hide things like certificate errors from the user and the browser displays a green 'secure' message in the location bar even if cert verification is not done or if the communication with the origin (web server) is unencrypted from the cloud WAF onwards.
Mark.
1:02 am
Hi,
As the admin of a church website that is a Wordfence Premium subscriber, and exchanges no personal financial information, such as credit card details, bank account information etc, I can say without question that Wordfence has saved our site from corruption hundreds of times, by malcontents and mischievious persons who have nothing better to do with there time. I have followed this discussion as best I can. However, I am no specialist in this area, so my question will appear to be very basic, and no doubt evidence my lack of understanding and naivety on what seems to be a very important subject.
Our church site is based, as you might imagine, on the Wordpress framework, and is essentially an information site, with no financial transactions taking place through it, as inferred above. My question therefore is simply this, 'is it necessary, or important, that a site such as ours should move to a site that has an SSL certificate, and uses the https protocol'? Since reading this blog post I have logged a ticket with our webhost, and asked them about the practicalities of doing so.
I use Firefox as my browser, and occasionally Google Chrome. Following the latest update I see that when logging in to the WP Dashboard for our site, Firefox now displays a small warning saying that the 'connection is not secure'. Apart from the 'padlock' icon in the address bar, that is the only place where I receive such a warning. It is true to say that Wordfence is very effective when it successfully blocks unauthorised attempts to login. Many attempts have been made by people trying to guess what the login details are, but so far they have not been able to do so. I do have the Double Factor Authentication enabled, which is, I would say, essential, even for sites such as ours.
I am sorry to interject in the discussion of the more technical aspects of the issue, but your thoughts on the question in paragraph two would be much appreciated.
Many thanks,
Alan
10:21 am
Hi Alan,
Yes, you need to move to HTTPS and SSL as soon as possible! It will improve your search engine ranking and it's critically important for the security of your site visitors. Right now everything they visit on your site is passed as plaintext across the network.
Mark.
11:57 am
Thanks Mark, I'll work on this with our webhost.
Regards,
Alan
6:37 am
I'm still confused about a few things. I use Cloudflare on my sites. Your post suggests to not use their services. However, they say that their "Full (Strict)" type of encryption is safe in regards to MITM attacks. This is what one comment on this post states. Is that "Full (Strict)" option good enough? Moreover, if they are re-encrypting the traffic again at their end, doesn't that make the traffic secure again?
10:24 am
Vivian,
I think the point is that they are MITM'ing traffic themselves. If you're OK with that then use them and be absolutely sure you're using "Full (strict)" as your configuration. What we're recommending here is that in general, site owners try to avoid breaking end-to-end encryption. In other words, try to avoid MITM'ing traffic and instead create a secure connection directly between your site visitor's browser and your web server. It improves security overall and reduces risk.
Mark.
4:33 pm
Hi, I'm not an expert on internet security, so I could use just a little clarification regarding your blog post on end-to-end encryption. Here's my situation: I'm currently using premium Wordfence and also premium Cloudflare on my website, and my website gets its SSL from Cloudflare. Given those facts, should I drop the SSL that I'm getting from Cloudflare and instead arrange to get my SSL from my hosting company (Hostgator) instead? Or am I fine as is? Thanks!
8:56 am
My preference is to remove Cloudflare from the picture and give your users an end-to-end encrypted connection to your website. If you don't want to do that, then make absolutely sure you are using what Cloudflare call "full (strict)" SSL. That means that they re-encrypt the connection to your server and they do certificate validation. In two out of three of their configs, they don't do cert validation and hide it from the site visitor.
Mark.
3:56 pm
Hi Mark,
Thank you so much for your awesome service! I learn so much from your articles. Based on the advice from one of your earlier articles, today I finally activated an ssl certificate for our church's website. I decided to go with the free Wordpress SSL that was being offered thru Bluehost. Do you know if this would qualify as an end-to-end service or will I need to ask Bluehost?
Thank you!
Dorothy