If you terminate SSL at the CDN, if you don't own the network and CDN, won't that leave your data open while in-transit between the CDN and the app servers?
I'm using cloudfront and aws, reluctant to let cloudfront be the root CDN because of this. Anyone got any insight?
Can't speak for Cloudfront, but I do know that Cloudflare has mitigated this problem. When you set up SSL, you have the option to force SSL from end to end. Of course, this approach means that SSL is terminated twice, once at the CDN and again when the user receives it, and this also relies on the assumption that you can trust Cloudflare with your data as it passes through their internal network.
Comments
If you terminate SSL at the CDN, if you don't own the network and CDN, won't that leave your data open while in-transit between the CDN and the app servers?
I'm using cloudfront and aws, reluctant to let cloudfront be the root CDN because of this. Anyone got any insight?
Can't speak for Cloudfront, but I do know that Cloudflare has mitigated this problem. When you set up SSL, you have the option to force SSL from end to end. Of course, this approach means that SSL is terminated twice, once at the CDN and again when the user receives it, and this also relies on the assumption that you can trust Cloudflare with your data as it passes through their internal network.
Is there a reason your CDN couldn't talk to your backend via SSL too?
If your visitors are using HTTPS to talk to you CDN, then you almost certainly should be using HTTPS from CDN to origin.
No reason, but does that help? I suppose it might, if the CDN used a keepalive connection and had less hops to go over.
CloudFront can do this easily: http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer...