Use SSL to CDN about hex HOT 6 CLOSED

From an extremely basic observation, it seems that even though s3.hex.pm is pointed at *.s3.amazonaws.com, S3 returns a (completely valid) certificate that secures the connection. However, due to the fact that (obviously) s3.hex.pm isn't *.s3.amazonaws.com, the connection is secure, but the browser gets confused due to the requested url (s3.hex.pm) vs. the certificate url (*.s3.amazonaws.com) match.

Sadly, S3 doesn't allow custom SSL certificates to be uploaded to a bucket (as of yet). Therefore, you're not able to point CNAMEs at S3 because of the certificate mismatch. The simplest solution for HTTPS support in the CDN is simply to point clients to https://s3.amazonaws.com/bucket_name/x/y/z.

from hex.

Pretty much (due to the fact that s3.hex.pm.s3.amazonaws.com doesn't match *.s3.amazonaws.com because of the dots), changing the default CDN url to https://s3.amazonaws.com/s3.hex.pm/ would work fine.

from hex.

The next step after setting

@default_cdn "https://s3.amazonaws.com/s3.hex.pm/"

Is that we need to check that if we are in fact using the default CDN, that we need to verify the SSL certificate sent from S3 (as discussed in #55).

According to the Erlang httpc docs:

If the scheme https is used the ssl application needs to be started. When https links needs to go through a proxy the CONNECT method extension to HTTP-1.1 is used to establish a tunnel and then the connection is upgraded to TLS, however "TLS upgrade" according to RFC 2817 is not supported.

Therefore, we just need to start ssl, and set an ssloption() in the httpc call matching:

{verify_fun, {Verifyfun :: fun(), InitialUserState :: term()}}

As stated by @ericmj:

It will fail because no CA certificate file is provided. I need to research how to get this file on all OSes we support or if we need to bundle our own file.

Therefore, to close this issue, we need to work out how to get CA certificate file onto each of the host systems, and then conclude how we can use a function like Verifyfun :: fun() to check it's integrity against a CA certificate.

from hex.

I have a working prototype of this. I just need to clean it up and add the code for shipping the CA bundle file.

from hex.

That sounds great @ericmj! In terms of moving everything to HTTPS, should we warn older (non-https) clients that they're vulnerable to MITM (man in the middle) attacks, as well as compromised downloads? Or should we just redirect all HTTP traffic to HTTPS (if the client will follow)?

from hex.

Also, now that I think about it, an easier way to ship the CA bundle file would simply to be parsing the latest list of Mozilla's trusted root CA certificates.

A good example of doing this is mkcert, an open source scraper of Mozilla's list.

Once a day, mkcert.org obtains the latest list of Mozilla's trusted root CA certificates,parses the file, removes anything explicitly marked as untrusted, and then keeps the data in memory, allowing you to make API calls to build your own customized PEM files, containing only the certificates you'd like to trust.

This means that if we generate a bundle with only Verisign certificates (as shown below), we can allow users to download this bundle from mkcert, which in turn is secured with HTTPS.

from hex.