Tag Archives: tls

Revisited: Eliminating Mixed Content warnings with Amazon Associates

Links & Banners

I verified that adding internal=1 parameter and removing http: from an iframe banner URL will cause it to load securely. I also verified that the clicks are counted (show up in the link Earnings and Link-Type reports.
Important: This does not work for all banner ads. While reviewing the banner ads, this trick will work on any ad that displays without mixed content warnings on the amazon page.

<iframe src="http://rcm-na.amazon-adsystem.com/e/cm?t=tidgubi-20&o=1&p=12&l=ur1&category=mp3&f=ifr&linkID=4ZPJJS7R4IXD5OGO&internal=1" width="300" height="250" scrolling="no" border="0" marginwidth="0" style="border:none;" frameborder="0"></iframe>

I have not been able to figure out a way to make the javascript based Banners load all parts securely.

Secure Widgets

Search


Contextual Recommendations


Omakase

This widget can be secured with some work.

Amazon doesn’t sanitize the amazon_ad_tag parameter, so the &internal=1 trick works for this widget.
Remove "http:" from the script src attribute and update the widget script with:

<script type="text/javascript"><!--
amazon_ad_tag = "tidgubi-20&internal=1"; amazon_ad_width = "728"; amazon_ad_height = "90";//--></script>
<script type="text/javascript" src="http://ir-na.amazon-adsystem.com/s/ads.js"></script>

Partially Secure Widgets

These widgets will load securely; however, they load insecure content if the user hovers over a product and causes a popup to load.

Insecure Widgets

Some quick testing showed the non-mobile friendly widgets use flash. While the flash code is loaded securely, it loads insecure content when executed. Using any of these results in mixed content warnings.

Updated Dreamhost Ciphers

Dreamhost offers free SSL/TLS through SNI for their shared hosting accounts. When this service was first released, it was limited to an RC4 ciphersuite and TLSv1.0. For most applications, RC4 is no longer a preferred cipher within the cryptographic community (Matthew Green’s blog post).

I haven’t seen an announcement, but I’d guess it was in the early November upgrade from Debian to Ubuntu that updated the security.

Dreamhost now supports TLSv1.0, TLSv1.1, and TLSv1.2 with the following cipher suites:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
  • TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
  • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
  • TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

Other than Triple-DES being a little on the weak side, this is now a very solid and modern list of ciphers.

Configuring Chrome’s SSL/TLS

As of version 34.0.1847.116, Google Chrome defaults to the following ciphersuites:

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
  • TLS_ECDHE_RSA_WITH_RC4_128_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_RC4_128_MD5

Overall I think the list is pretty good. I’d rather not use the ciphersuites in red, because of the MD5 message authentication and the DSS site authentication. I also think it is very unlikely these will prevent you from accessing any common sites. The more security conscious users will probably want to disable the orange cipher suites as well, because RC4 and TDES are both weaker than AES. As you make changes, the SSL Labs Client Test is an easy way to see which ciphersuites are enabled. It also gives you the hex code for each ciphersuite, which is used to disable them.

Unfortunately Google Chrome doesn’t have a nice interface for configuring ciphersuites like Firefox and Opera, so you need to use command line switches to selectively disable ciphersuites. I have instructions for using command line switches on Windows and MacOS.

To disable the red ciphersuites, add the following switch:

--cipher-suite-blacklist=0x0004,0x0032

To disable the red and orange ciphersuites, add the following switch:

--cipher-suite-blacklist=0x0004,0x0032,0x0005,0x000a,0xc011,0xc007

If you’re concerned about the NSA, the following disables all ciphersuites without perfect forward secrecy:

--cipher-suite-blacklist="0x0004,0x0005,0x000a,0x0035,0x002f,0x009c,0x0032

I also recommend disabling SSLv3.0 with the following switch:

--ssl-version-min=tls1

Free SSL on Dreamhost

Dreamhost supports SNI to enable SSH/TLS on their shared hosting offerings. While I wanted to enable SSL/TLS on my site, I thought I would have to buy a certificate from one of the major Root Certificate Authorities. I was happily surprised when I found StartSSL.com which offers free SSL Certificates. StartSSL.com is a trusted root CA on MacOS, Windows, and Mozilla; so compatibility is not a major concern. StartSSL.com is located in Israel, so I feel more comfortable with this free offering than say a Russian company.

Generating a CSR

The first step is to generate a Certificate Signing Request (CSR). You need a computer with OpenSSL to follow these steps. All files below should be located in the same folder and all commands should be run from within this folder.

  1. DigiCert has a very nice CSR Creation Tool. Fill in the required fields, click ‘Generate’, and copy the generated command. StartSSL only supports RSA keys.
  2. (optional) Gather additional entropy.
    1. Go to a number of entropy providing sites or password generating sites. Copy the output into text files in the folder you will be generating your CSR in. The exact format of the text isn’t important, as OpenSSL will just add the data to the entropy pool. For the examples later, I’ll assume you’ve named your file(s) entropy1.txt, entropy2.txt, etc./li>
    2. Some sites to gather entropy from are:
    3. Add -rand entropy1.txt:entropy2.txt:entropy3.txt to the command from Step 1.
  3. (optional) Use a stronger hash algorithm
    1. If you’re using RSA add -sha256 to the command from Step 1. You can use -sha512; however, sha512 is not commonly used with certificates and might not be supported by all servers and clients. sha256 might not be supported by older clients. Currently OpenSSL only supports SHA-1 with DSA and ECDSA certificates.
  4. Run the command from Step 1 with any optional adjustments, for example:
    • openssl req -new -newkey rsa:2048 -nodes -out www_tidgubi_com.csr -keyout www_tidgubi_com.key -sha256 -rand entropy1.txt:entropy2.txt -subj "/C=US/ST=California/L=San Luis Obispo/O=Kenji Yoshino/CN=www.tidgubi.com"
  5. The .key and .csr files will be used later.

Get your CSR Signed

Begin by registering with StartSSL.com. Make sure you do this from a private computer, because StartSSL.com will generate an identification certificate and install it in your browser. This certificate will be used to identify you on subsequent visits to StartSSL.com.

  1. Click ‘Validations Wizard’
  2. Select ‘Domain Name Validation’
  3. Enter your domain without any prefixes (e.g. www)
  4. You will need to specify an email address associated with your domain to verify domain ownership. Another verification code will be sent to this email address.
  5. Enter the verification code in StartSSL.
  6. Click ‘Certificates Wizard’
  7. Select ‘Web Server SSL/TLS Certificate’
  8. Skip having StartSSL generate a CSR for you.
  9. Copy and paste the entire CSR including the “—–BEGIN CERTIFICATE REQUEST—–” and “—–END CERTIFICATE REQUEST—–“
  10. Select your domain and click ‘Next’
  11. Add the “www” subdomain (Startssl requires you to add one) and click ‘Continue’
  12. Copy the entire certificate text including the “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“. Save the text to a .crt file.
  13. Download the intermediate CA file and optionally the root CA file.
  14. If you downloaded the root CA, combine the two files by running cat sub.class1.server.ca.pem ca.pem > chain.pem. The root CA provides browsers with the full certificate chain. Most browsers do not need the root CA to be included to trust the intermediate CA, so it is up to you if you want to include the root CA.

Configure SSL on Dreamhost

  1. Login ot your panel at panel.dreamhost.com
  2. Click ‘Manage Domains’
  3. Click ‘Add’ or ‘Certificates’ in the Secure Hosting column. If adding, leave unique IP as none and click ‘Add Now’, and then ‘Edit’.
  4. Select ‘Manual Configuration’
    • Delete or replace the CSR text (it is just informational)
    • Copy the text from your certificate including “—–BEGIN CERTIFICATE REQUEST—–” and “—–END CERTIFICATE REQUEST—–“
    • Copy our your private key including “—–BEGIN RSA PRIVATE KEY—–” and “—–END RSA PRIVATE KEY—–“
    • Copy the certificate chain, either the intermediate CA certificate or the intermediate and root CA certificate concatenated together.
    • Click ‘Save Changes Now!’
  5. It too about 4 minutes for changes on tidgubi.com to take effect.

Now your Dreamhost site allows SSL. Dreamhost only uses the TLS_RSA_WITH_RC4_128_SHA cipher suite with TLSv1.0 or SSLv3.0, so while it doesn’t provide great security, it’s better than nothing. I’m now tunneling my administrative traffic through TLS and SSH. From Securing Administration of Shared Hosting, I just changed 80:www.tidgubi.com:80 to 443:www.tidgubi.com:443 to specify the HTTPS port (443) instead of the standard HTTP port (80).