Category Archives: Web

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="" 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


Contextual Recommendations


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=""></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.

Musings on Password Lengths

I’ve been thinking about password lengths, complexity, and how much strength is really required.

Random Passwords

I use LastPass for all of my passwords an never really calculated how long I need to make my passwords secure assuming they’re fully random. Since AES with a 128-bit key is considered sufficiently secure, I want my passwords to have at least 128-bits of strength. Doing some quick math based on a standard US ASCII Keyboard, the bits in strength in each character classes are as follows:

  • lowercase – 26 ≈ 4.7
  • uppesrcase – 26 ≈ 4.7
  • numbers – 10 ≈ 3.3
  • symbols – 30 ≈ 4.9

I assume that every website will accept alphanumeric passwords, so that gives 62 possibilities. Each character has just short of 6 bits of strength. 128 / 6 ≈ 21.3, so a random 22 character alphanumeric password has more than 128 bits of strength.

If the website accepts all special characters, that 92 possibilities. Each character then has just over 6.5 bits of strength. 128 / 6.5 ≈ 19.7, so a random 20 character password has more than 128 bits of strength.

"Human" Passwords

Human passwords are much more difficult to estimate the strength of. I like to use a variant of the xkcd: Password Strength method of using a combination of words, numbers and symbols. This changes/adds the number of possibilities based on the number of words. The Oxford English Dictionary indicates that there are about 600,000 words in the English language. Assuming that half of these are between 3 and 6 characters, each word between 3 and 6 characters has about 18.2 bits of strength.

If an attacker knew the composition of a password that followed the pattern word, symbol, word, number, word, symbol, word; this password would have 18.2 + 4.9 + 18.2 + 3.3 + 18.2 + 4.9 + 18.2 = 87.7. While a password like this doesn’t quite reach 128 bits of strength; it is reasonably strong, should be easy to remember, and fairly easy to type. Also, an attacker probably wouldn’t know the password composition method, making the actual strength a bit higher. If science and technical terms are included, that will increase the strength per word. Just make sure you pick your words randomly.


The 24+ character random passwords for websites are unnecessary, especially when the password reset functions generally have limited security.

I should add a little more length for my master passwords that are susceptible to an offline attack (e.g. LastPass). Fortunately most passwords like this use PBKDF2 to increase the computing power necessary to perform a brute force attack.

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:


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