Embracing HTTPS

Re:Embracing HTTPS by Animats on Friday November 14, 2014 @02:48AM (#8606218)

Cloudflare offers a number of SSL options, but they all involve decrypting the traffic at Cloudflare and possibly re-encrypting it for the link to the final server. Their options: (https://www.cloudflare.com/ssl)

* "Flexible SSL" - encrypted from client to Cloudflare using Cloudflare's cert, unencrypted from Cloudflare to host.

* "Full SSL" - encrypted from client to Cloudflare using Cloudflare's cert, encrypted from Cloudflare to host using a different host self-signed cert.

* "Full SSL (strict)" - encrypted from client to Cloudflare using Cloudflare's cert, encrypted from Cloudflare to host using a different host CA-signed cert.

(http://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tech...)

* "Keyless SSL" - encrypted from client to Cloudflare using the customer host's cert. Cloudflare doesn't have the customer's cert private key. They contact the customer's host for a session key for each session, and use this to encrypt from the client to Cloudflare. They decrypt at Cloudflare, and re-encrypt for the trip to the customer's host.

With the first three, you can see in the browser that this is happening. The host will be identified as "cloudflare.com" in the certificate. With "Keyless SSL", which is basically MITM with active cooperation from the end host, it looks at the browser end like you're encrypted end to end, but you're not.

One assumes that all of these are being "lawfully intercepted".

[ Parent | on HN ]

Re:Embracing HTTPS by IgorPartola on Friday November 14, 2014 @10:01AM (#8607396)

I wish that the Full SSL sans-strict option allowed me to upload my self-signed public key to CloudFlare. The problem is that CloudFlare can be MitM'ed without this step.

[ Parent | on HN ]

Re:Embracing HTTPS by Rapzid on Friday November 14, 2014 @03:16AM (#8606272)

The "possibly" is the problem. CloudFlare should not be promoting or supporting TLS that is not encrypted all the way to their customers infrastructure IMHO.

[ Parent | on HN ]

Re:Embracing HTTPS by ryan-c on Friday November 14, 2014 @03:27AM (#8606291)

Cloudflare can't act as a "cloud waf" unless they are able to decrypt the ssl sessions.

[ Parent | on HN ]

Re:Embracing HTTPS by Rapzid on Friday November 14, 2014 @03:52AM (#8606342)

The issue isn't that they are decrypting the traffic for inspection. That's a concession you just have to make with a trusted third party providing these types of services. The issue is that with their "Flexible SSL" they are then forwarding that unencrypted traffic on through the wilds(the internet) to the customer. Not only does this fly in the face of widely regarded best practices for transferring sensitive information between trusted, controlled networks the browser is none the wiser. You could argue that somebody with a certificate could do this anyhow. Yes, this is true. However CloudFlare who should, and most likely DOES, know better and are now doing this wholesale as a product offering! This should be frowned upon and CloudFlare should receive double frowns.

[ Parent | on HN ]

Re:Embracing HTTPS by Animats on Friday November 14, 2014 @01:27PM (#8608640)

That's a concession you just have to make with a trusted third party providing these types of services.

That's the problem. If you only use SSL/TLS for security-critical pages where there's a login or a credit card, you don't need some massive cloud-based service to cache your stuff. Many sites still use "transferring to secure site for shopping cart checkout". That's fine. If you use SSL/TLS for everything, now you have a load problem on the secure infrastructure.

That's why "SSL Everywhere" is security theater. To have "security" on pages that don't need to be secure requires weakening security on the pages that do.

[ Parent | on HN ]

Re:Embracing HTTPS by nitrogen on Friday November 14, 2014 @03:24PM (#8609287)

That's why "SSL Everywhere" is security theater. To have "security" on pages that don't need to be secure requires weakening security on the pages that do.

Nah, you can still have separate secure domains with EV certs for taking credit cards. That way your customer's browsing habits and product preferences are protected from snooping by their ISP, the page assets are still cached and DDOS protected, and the credit card data is still sent to a separate domain without an intermediary.

The only thing still to worry about is your caching provider sending maliciously modified content that bypasses your secure domain.

[ Parent | on HN ]

Re:Embracing HTTPS by rakoo on Friday November 14, 2014 @08:40AM (#8607022)

On the other hand, it's the customer's decision to put Cloudflare in the stack. They have decided to put Cloudflare on the path, just as they would have decided to use nginx. There really is no one to blame (because the end here is not the customer's server, it's the cloudflare server) and if you really want to, you should blame the customer.

EDIT: just read your answer below, my comment is off-topic. Sorry.

[ Parent | on HN ]