Tag Archives: ssl

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.

DreamHost Private Key Format

When renewing my SSL/TLS certificate for my DreamHost shared hosting account, I generated a new 4096-bit RSA Private Key using OpenSSL 1.0.1e. I was surprised and confused when DreamHost reported "Invalid private key". I initially thought it was a problem with the 4096-bit key but found documentation indicating 4096 is a supported option.

I checked the that my key was PEM formatted as expected, and finally realized it was an incompatibility between the "-----BEGIN RSA PRIVATE KEY-----" and the "-----BEGIN PRIVATE KEY-----" variants of the PEM format when I couldn’t create a self-signed cert using OpenSSL 0.9.8za and my brand new key. Once I realized this, it was a simple conversion using the command 

openssl rsa -in private.key -inform PEM -out outfile.key -outform PEM

with OpenSSL 1.0.1. The in/out forms aren’t strictly necessary, but make the command a little clearer to read.

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

Eliminating Mixed Content Warnings with Amazon Associates

Mixed-ContentOnce I enabled SSL for tidgubi.com for free, I realized that most Amazon.com content is plain HTTP, so it was causing Google Chrome to give me mixed content (encrypted page with some unencrypted elements) warning messages:

Two as I dug into the HTML, I found that the Amazon Banner Ads, Widgets, and Payments Button were the cause of the mixed content warnings.

Banner Ads and Widgets

All of the Amazon Associates banner ads and widgets can be loaded over HTTPS; however, the banners any widget that displays product images load these images over HTTP. I couldn’t figure out a way to force the widget/javascript based ads to use HTTPS for images, but I was able to find a little trick to get the iframe based ads to use HTTPS. To do this, simply add &internal=1 to the end of the URL in the iframe’s src attribute and removed http: from the beginning of the URL. Removing http: tells the browser to use the same type of connection that was used to load the page, so these links automatically switch between HTTP and HTTPS. For example my "Kindle Banner" is <iframe src="//rcm-na.amazon-adsystem.com/e/cm?t=tidgubi-20&o=1&p=48&l=ur1&category=kindlerotating&f=ifr&internal=1" width="728" height="90" scrolling="no" border="0" marginwidth="0" style="border:none;" frameborder="0">

Warning: "internal=1" is used in Amazon’s example banners, so while it doesn’t strip associate IDs from links, it might cause these clicks not to count.

Donate/Pay Button

There are two easy fixes for the Donate/Pay button image.

The first option is to download the image and host it on from your webserver. For me the donate image is now at www.tidgubi.com/wp-content/themes/tidgubi/img/golden_small_donate_withmsg_whitebg.gif.

The second option is to link to Amazon’s SSL image server. To do this, just replace http://g-ecx.images-amazon.com with https://images-na.ssl-images-amazon.com. Since Amazon uses a different domain name for HTTP and HTTPS, there aren’t any tricks with HTML to switch how the image is loaded. If you always use HTTPS, it will make the page marginally slower since it needs to establish an HTTPS connection to ssl-images-amazon.com each time. If a page dynamically generates this HTML, you can dynamically pick the imager server based on the protocol used to load the main webpage.