Categories
Security

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:

  1. Wordfence is a strong supporter of end-to-end encryption for the online community.
  2. We suggest that you avoid services that break end-to-end encryption by intercepting and decrypting traffic.
  3. 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.
  4. We encourage corporate network owners and CISOs to avoid products that perform HTTPS interception and break end-to-end encryption.
  5. 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:

  1. In some configurations they don’t re-encrypt the HTTPS traffic, leaving it to pass unencrypted over the internet.
  2. 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.
  3. 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.

The post Support End-to-End Encryption on the Web appeared first on Wordfence.

Categories
Security

Endpoint vs Cloud Security: The Cloud WAF User Identity Problem

Imagine you’re a security guard at the entrance to a high security facility. You need to evaluate each person who wants to gain entry to ensure they are allowed access. You use information about each person to make your decisions. You might use information like what they say, whether they’re carrying a bag, if they’re carrying a gun and so on.

The most important item of information you’ll use in your decision-making is who they are and what access level they have. In other words, their identity. If you don’t have this identity information, you are going to have a very difficult time making a decision about whether someone should be granted access or not.

In this post, we show you how cloud WAFs like Cloudflare and Sucuri, also known as cloud firewalls, actually don’t know who you are. They don’t even know if you’re signed in or not. The result is that they tend to do a much worse job when it comes to deciding who should be allowed to access a website and who should be blocked.

This post is a continuation of a series of Endpoint vs Cloud blog posts, which we started on Tuesday. We have already described the Cloud WAF Bypass Problem, and how an endpoint firewall like Wordfence prevents bypass.

Endpoint Security: Wordfence Knows Who a Visitor Is and their Access Level

As we discussed earlier this week, ‘endpoint security’ is what all major security vendors are moving towards. The ‘endpoint’ is the target an attacker is trying to gain access to. It might be a workstation, mobile device or your web application like WordPress.

An endpoint security solution runs directly on the endpoint and protects it in a variety of ways. Wordfence is an endpoint security solution because it executes directly on WordPress, which is the endpoint for an attacker targeting your website.

Wordfence integrates deeply with WordPress. One of the items of data we have is who a visitor to your site actually is and what access level they have.  In security industry terms, we refer to this as authentication and authorization. We know if they’ve proven they are who they claim to be and we know what they have authorization to access.

Wordfence Protecting the Endpoint

Identity information is a critical part of the decision-making that our firewall performs. It helps us create firewall rules that block the bad guys and make sure that administrators and other privileged users don’t accidentally get blocked.

User identity and access level is so important to our firewalls decision-making that we use the user’s access level in more than 80% of our firewall rules. It helps us prevent the dreaded “false positive” when a real user is blocked. It also helps us create rules that block against more complex attacks.

By having user identity and access level, we can be extremely aggressive in the kind of rules that we create. Along with user identity we use other information to make our decisions, like the path being accessed, the URL query string, the type of request being made, the body of the request and other headers that might be included in the request.

Cloud Firewalls Don’t Have Identity Information

A cloud firewall like Cloudflare or Sucuri’s WAF uses servers based out on the Internet, away from the endpoint they’re protecting. Visitors and attackers who come to your website first arrive at the cloud WAF. The cloud WAF runs the request through a series of rules and decides if it’s allowed or not.

Cloud WAF providers have a firewall that runs physically and logically separated from the endpoint. They don’t interact with the endpoint API to make their firewall rule decisions. They don’t have authentication and authorization data that can use to help with that decision making.

cloud1

A cloud WAF might be able to see if a user has a login cookie, but that cookie can be easily faked because they can’t verify its authenticity, because they don’t have access to the endpoint API, data and execution environment.

As we have explained, it’s critically important that a firewall knows who a visitor is and what permission level they have to make effective decisions. A cloud WAF does not even know if a user is signed in or not. 

Cloud WAFs use pattern matching. They examine the arriving web request and use patterns to try to determine if it’s an attack or not. This results in much less effective decision-making. They block a few attacks but miss many others.

Cloud WAFs may also suffer a higher rate of false positives because they can’t identify real users making perfectly legitimate requests that trigger their rules. The only way to fix the false positives is to loosen up the rule-set, which results in more attacks getting through. It’s a Catch-22 situation.

Endpoint Security for WordPress: Local Knowledge, Defense in Depth

identity2Wordfence is an endpoint security solution that executes within the WordPress environment. That means we have full access the the WordPress API and we can use any data in this API to make our decisions about who is granted access. That’s one of the reasons the industry is moving towards endpoint solutions: they have local knowledge to help their decision-making.

To help the Wordfence Firewall make its decisions, the WordPress API provides us the following data:

  • If the user is signed in or not.
  • The user’s identity.
  • The user’s authorization level e.g. ‘subscriber’, ‘editor’ or ‘admin’.

If we see a verified admin user trying to access something that looks like a common attack, we might allow it to pass if all other data indicates it’s safe. If we see the same request coming from a ‘subscriber’ level user or someone who is not signed in at all, we will block it.

Protecting Against Complex Attacks

Wordfence protects you against more complex attacks, like a “privilege escalation attack”, or privesc attack as we refer to it internally. If you look at the list of firewall rules we’ve deployed on your site, you’ll see at least three privesc attack rules that are currently active and protecting you.

A privesc attack is where an attacker uses an account with low level access, like a ‘subscriber’ level WordPress account. Then they use the lower level privileges that account has to exploit their way to administrator level access.

To protect against privesc attacks, you need to know if a user is signed in and what access level or level or ‘authorization’ they have. If you don’t have authorization information, you don’t know if a subscriber level user is trying to perform an admin function or if it’s a real admin taking the same action. 

Wordfence in effect has local knowledge about the system it is protecting. To make better firewall decisions we have made sure we simply have better data.

Conclusion

Smart decision making requires the best data.  By protecting against attacks at the endpoint, you can make smarter decisions about who should gain access and who should be denied. With better data, you can also benefit from a far more aggressive rule-set without risking false positives, because you know who is using your web application. That is why Wordfence protects against attacks at the endpoint.

The post Endpoint vs Cloud Security: The Cloud WAF User Identity Problem appeared first on Wordfence.