Update: Cloudflare now issues free certificates for the origin.
At CloudFlare, we are always looking for ways to improve the security of our customers’ websites. One of the features we provide is the ability to serve their website encrypted over SSL/TLS. Today we are announcing a new feature to help make encryption on the web safer and more secure: Full SSL (Strict). With strict mode, CloudFlare does additional validation of the identity of the origin server in order to prevent active snooping and modification of your traffic on the Internet backbone. This feature is available today for all paying customers so current and new customers can take advantage of the added security immediately.
Web encryption
Transport Layer Security (TLS) is a protocol for encrypting data that is sent over the Internet. TLS grew out of Secure Sockets Layer (SSL), the first widely-adopted web encryption protocol, in order to fix most of the earlier protocol’s security flaws. The industry still uses the terms somewhat interchangeably for historical reasons. Any web site that you visit starting with https:// rather than http:// is using TLS/SSL for communication between your browser and their server.
TLS on the web provides these features:
Encryption of data
Proof of identity of the server
To enable TLS, a site needs a certificate and a corresponding key. Certificates are files containing information about the owner of a site, and the public half of an asymmetric key pair (usually RSA). A certificate authority (CA) digitally signs the certificate to verify that the information in the certificate is correct. By trusting the certificate, you are trusting that the certificate authority has done its due diligence.
Operating systems and browsers typically have a list of certificate authorities that they implicitly trust. If a web site presents a certificate that is signed by an untrusted certificate authority, the browser warns the visitor that something could be afoot.
On Path Attack
One type of attack that could trigger a browser warning is a on-path attack. In this attack, an attacker places himself in between a visitor and a web site, impersonating both. With this attack, the browser thinks it is talking to the server on an encrypted channel, and the server thinks it is talking to the browser, but they are both talking to the attacker who is sitting in the middle. All traffic passes through this attacker, who is able to read and modify any of the data.
The certificate authority system is designed to stop the on-path attacks. In TLS, the server uses the private key associated with their certificate to establish a valid connection. The server keeps the key secret, so the attacker can’t use the site’s real certificate; they have to use one of their own. The attacker has to either convince a certificate authority to sign their certificate, or just use it, as is. An attacker trying to use a certificate that is not validated by a known trusted CA will be caught immediately by modern browsers. However, not all internet connected services are as diligent about checking certificates.
Two Segments of the Internet
The data for visitors of sites that use CloudFlare travels over the Internet through two segments. The front-end, from the user to CloudFlare, and the back-end from CloudFlare to the host’s web server. Ideally, both segments of this communication would be secure.
The front-end is a dangerous place for data that is sent unencrypted and unauthenticated. Messages have to go from the browser, through the local wired or wireless network to the modem and the Internet service provider, before reaching the Internet and CloudFlare’s servers. Malicious parties can read or modify the messages anywhere in this chain. For example, using an unencrypted site at a coffee shop could expose your private data for all to see.
The communication on the back-end is harder to spy on, since most server-to-server data flows through the Internet backbone. The coffee shop snooper can’t read or modify the information flowing through transatlantic pipelines, but large telecommunications and nation-state level attackers can still potentially intercept this data. This is what Operation FLYING PIG is said to be doing.
The traceroute command shows the network hops to get from your computer to any given website:
Sending your Internet traffic through so many computers unencrypted certainly seems like a risky move.
CloudFlare’s SSL options
Until today, CloudFlare offered three options for SSL/TLS for site operators: Off, Flexible and Full. They are available in the site’s control panel under “CloudFlare Settings” and in the Page Rules section for a given zone.
We are now introducing a new option: Full SSL (Strict). There are now three different modes for enabling SSL: Flexible SSL, Full SSL, and Full SSL (Strict). Below is a description of what the different options mean.
Flexible SSL - front-end over TLS, back-end unencrypted
Flexible SSL encrypts all data between your site’s visitors and CloudFlare using TLS configured with best practices such as forward secrecy and more. This is where most threats to web traffic happen: in your coffee shop, by your ISP, and others in the local network. The browser’s certificate validation prevents attackers in these locations. This option is very useful for customers who don’t have TLS configured on their host or can’t enable it because of how they are set up with their hosting provider.
Above: Flexible SSL - front-end over TLS, back-end unencrypted
Full SSL - front-end over TLS, back-end over TLS
In Full SSL, the front-end is protected with TLS, and the back-end is encrypted with TLS but the certificate itself is not validated by CloudFlare. This means that a passive attacker listening to the data does not have the ability to read the communication, but an active on-path attacker could potentially intercept the data. This option makes sense for customers who don’t have the ability or the desire to pay for a certificate from a certificate authority but who still want their data to be protected from mass collection of data.
On-path attempts between CloudFlare and the web server are difficult to pull off, but still possible, and we wanted our customers to have the option of protecting their customers against such attackers. Full SSL (Strict) makes sure that CloudFlare validates the certificate chain presented by the web server.
Above: Full SSL - front-end over TLS, back-end over TLS
Full SSL (Strict) - front-end over TLS, back-end over TLS (validated)
In strict mode, CloudFlare validates the certificate chain on the back-end using its own list of trusted certificate authorities. Customers can enable this globally for their site, or they can have different settings for different subdomains, using Page Rules. CloudFlare’s list is more exclusive than the ones used by the popular browsers. By trusting a smaller and more exclusive list of certificate authorities, we protect our customers against MitM attacks using certificates signed by rogue or compromised certificate authorities. We are automatically upgrading customers from Full SSL to Full SSL (Strict) if we determine that their origin server has a valid certificate installed.
Above: Full SSL (Strict) - front-end over TLS, back-end over TLS (validated)
Giving Back
One of the core technologies CloudFlare uses for TLS connections is the open source web server/reverse proxy called nginx. The current public version of nginx does not have the ability to validate a certificate when talking to an origin server. In the spirit of open source and making the web a safer place, we have upstreamed our changes to nginx that enable origin certificate validation. We also added support for SNI (Server Name Identification) to allow nginx to speak to multiple domains behind the same IP over TLS.
Threats on the Internet are changing and evolving constantly. We hope this option lets web site operators and web site visitors sleep easier knowing that their data is protected in transit, even against highly motivated and capable attackers.