Many sites do mix HTTP and HTTPS content. Sites that do this are no-longer considered secure (Larry goes away, the lock has a warning symbol over it) for good reason, the insecure content cannot be trusted. It may have been tampered with. If the content was a javascript file for instance, it could be very bad news.

But if we know that data from a secure source can’t be tampered with, could it vouch for content that isn’t secure? Let’s take an example of a fictitious webpage :


<script type="text/javascript" src="http://media.cesaroliveira.net/badass-javascript.js"></script>
<img src="http://media.cesaroliveira.net/panda.jpg" alt="look out!" />
Credit card number : <input type="text" ...


Even though the site is served securely, some important information is sent insecurely. I am proposing that the secure content is able to pass along a hash (sha1, not md5) of the content that it expects. If the content in the insecure channel meets the has the same hash value, then we can be reasonably assured that the data has not been tampered with during transport. Let’s see the code again :


<script type="text/javascript" src="http://media.cesaroliveira.net/badass-javascript.js" data-hash="sha1:12b36be3076d357b2d390b2df3f9b65cd55b93e1" ></script>
<img src="http://media.cesaroliveira.net/panda.jpg" alt="look out!" data-hash="sha1:bcf31e777fa69753f8ecf9701fc9b6f1518b51b3" />
Credit card number : <input type="text" ...


Starts with data- because I doubt something like this would be implemented outside of my head. But it seems to solve the problem of tampering with the data. If the hashes don’t match, the website is still broken. If they do match then we should be able to breathe easily.

Of course, in time people will figure out vulnerabilities. Hash collisions is a problem. But this is something that web had to deal with before. Maybe a nice edition would be allowing multiple hash values, like :

<img src=”http://media.cesaroliveira.net/panda.jpg” alt=”look out!” data-hash=”sha1:bcf31e777fa69753f8ecf9701fc9b6f1518b51b3;md5:953c78ac57ca68bfe532eb50120c8aa1″ />

Yeah. I know I said no md5

While going about my day, I wondering if self-signed certs can be used in a way that wouldn’t get you ostracized from a security conscious community. Johnathon has warned the blogosphere at large why self-signed certs are bad and why Firefox makes you jump through hoops to allow a self-signed cert to get through. But I thought of a good use case for why you may want to use it :

1. Self-signed certs provide little value for your users (fe. blog comments are public anyways)
2. You may not have the means (eg. credit card, unique ip if your with Dreamhost) to buy one
3. You only really need them for some basic stuff that users shouldn’t interact with at all. Like logging in to wordpress.

In which case, you can generate a self-signed cert and configure a web server to serve you it on some uncommon port such as port 43034. The benefit is that its transparent to users. It will not interfere with their browsing. And you get the benefit of encryption and authorization, and knowing for certain that the certificate is yours (you have access to the certificate’s fingerprints).

I tried this on Dreamhost and I failed. Or, rather, Apache doesn’t you set up a <VirtualHost> in a .htaccess file. Dreamhost didn’t have anything in their web panel that would fix this. You can enable SSL for a site, but they force you into port 443 and don’t let you have both HTTP and HTTPS.

Another excellent educational learning opportunity ruined by over-zealous security zealots.