Why put the GPG key on HTTPS page linked from a HTTP page? If the HTTP site is compromised through MITM the attacker can easily change the link to a bucket he controls, that is also HTTPS (i.e. https://s3.amazonaws.com/secure.jackdb.com/pgp/security_at_j...).

I don't think it adds anything to security, but actually provides for a fake feeling of safety.

You're absolutely right about being able to MITM the HTTP piece and replace the content. That's true for any mixed content site. In this case though I disagree that having the HTTPS link to S3 is entirely useless. It's used specifically for an SSL link to download our GPG key, that additionally is available on a number of key servers and indexed by search engines like that too[1]. In that usage it's one of many ways of getting that key and, like all GPG keys, should really be verified before use anyway. For just about anything else though I agree that mixed content is a very bad idea.

[1]: https://www.google.com/search?q=jackdb+gpg

Alright, I thought I was missing something :)

I wish I had read the wisdom of this comment a couple months ago. I was having problems scaling on EC2 for my business, and ended up hacking together this setup - host static website on S3, and link to SSL-only domain for secure stuff. It's incredibly frustrating when Amazon does nothing to disseminate information about how to more effectively use their cloud infrastructure.

> It's incredibly frustrating when Amazon does nothing to disseminate information about how to more effectively use their cloud infrastructure.

Hmmm. We have thousands of pages of reference documentation and tutorials. We have forums. We have a team of Solution Architects ready, willing, and able to help.

Though I agree that the documentation is comprehensive, that itself can be a barrier. It all seems very deeply nested and enterprisey. I'm often left wanting a layer of noob-friendly UI or documentation, or "You probably want X"-style guidelines that differentiate between typical use cases and non-typical ones.

Compare, for example, the Digital Ocean UI for creating new VMs. It's a much more pleasant experience than the AWS Console for the new user with a small scale use case.

You're absolutely correct in that the documentation and tutorials are thorough and the support is outstanding (I've been helped before and am convinced of the quality of people doing support for AWS). I made that comment from the viewpoint of a programmer and business owner with the most surface-level sysadmin knowledge, who doesn't have the time to attend AWS conferences or read through hundreds of pages of documentation.

I'm not asking Amazon to "dumb down" their documentation or tutorials, I just wish that there was somewhere that Amazon could succinctly state the best way of doing things. This could take the form of a novice guide, as the other commenter stated, or as links in the documentation to articles in the blogosphere that detail practical ways to get set up with a certain AWS technology.

Also, in respect to this specific issue, the knee-jerk reaction that people on the AWS forums have in respect to scaling is to set up auto-scaling policies. Simple and intuitive ideas like hosting static websites on S3, hosting secure content on EC2, and combining the two, has very poor coverage in both the AWS documentation and on the Internet in general.

SSL certificates for CDNs are just a tough problem because there's no cheap/easy way to have one certificate that corresponds to a bunch of different IP addresses (that works on Windows XP).

It's not an issue with multiple IP addresses, but rather with being able to host multiple SSL-enabled domains on a single IP (which is what CDNs need to do). That is where SNI[1] comes in, along with all of its compatibility issues with older network stacks.

[1] http://en.wikipedia.org/wiki/Server_Name_Indication

So IPv6 would not be an issue then, I gues, every client could have an IP on each edge node...

Yes, that is a possibility. SNI will also become a more realistic option as older devices get retired. I've implemented several sites with SNI, and as long as you're aware of what devices/browsers/OSes will be connecting to your site (and their SNI support), things work great.

So why is it so expensive?

Why is it so expensive to add SSL with a custom domain to Amazon CloudFront? Because Amazon actually needs to acquire hundreds of individual certificates on your behalf and distribute them to its edge servers.

No they don't, you provide them with a single cert and they use that on every edge node.

SSL requires additional CPU resources, and is often coupled with hardware acceleration. All of this equates to higher hosting costs.

What is what so expensive?

SSL comes with the $20/month Cloudflare plan, and you may not even need it on your webhost then. They're also planning on introducing it to the free plan this year.

Why use ssl for a fully static site?

The same reason you'd use it for a non-static site; to ensure that visitors to your site are getting your actual site content and not something else(i.e. avoid a MITM).

If you had a purely informational site and it listed phone number, address, or heck even a bitcoin address, wouldn't you want to make sure that your visitors got the actual site and not something malicious?

There was a story last week about a guy who's ISP was inserting content into web pages. I can't find the link as I think it got lost as a result of the HN server crash. SSL prevents crap like that.

Are you referring to “I fought my ISP's bad behavior and won”[1]?

If so, in that case the ISP altered DNS results to point to its own HTTP server and redirect to the real one with a modified URL. SSL would have helped a bit, but the first problem is that DNSSEC isn't more widespread.

[1]: https://news.ycombinator.com/item?id=6992897