SSL notice

To protect Internet communications from being eavesdropped by malicious persons, an encryption protocol called SSL is used. Haven & Hearth's web site supports and encourages the use of SSL to protect your password from being stolen. However, unlike most sites, you need to manually accept our certificate to avoid complaints from your web browser.


At a glance, what you need to do is the following:

  1. Download the certificate. Your browser might attempt to process the certificate directly instead of downloading it. In that case, just right-click on the link and select "Save Link As..." from the resulting menu to download it.
  2. Look up the fingerprint of the certificate. The exact instructions for doing this depends on the operating system you are using, but on Microsoft Windows, there is a built-in certificate viewer that you can use simply by opening the certificate like any other file. Open the "Details" tab, and look up the "Thumbprint" line in the table. The fingerprint will be displayed in the lower text box as 40 digits.
  3. Verify its authenticity. This is the hard part. To be able to securely verify that the certificate is authentic, you need to compare its fingerprint with an external source that you trust. Unfortunately, there is currently no good infrastructure on the web to do this properly. Optimally, you should ask a friend, who in turn has asked a friend, who, in any number of steps have received it personally from some of us. In all honesty, however, the probability that the certificate has been faked by a malicious attacker is rather low.
  4. Once you are convinced that the certificate has not been faked, install it into your web browser. The exact instructions for doing so depends on the browser in question. We cannot provide instructions for all possible browsers, obviously, but read on for the most common ones.
Microsoft Internet Explorer
Internet Explorer uses Windows' own certificate system. If you have opened the certificate in Windows' certificate viewer as described above, there should be a button labeled "Install Certificate..." on the "General" tab. Clicking that button will launch a wizard which should take care of everything for you.
Mozilla Firefox
Firefox uses its own certificate system on all operating systems. Open the "Options" dialog from the "Tools" menu, go to the "Advanced" screen, select the "Encryption" tab, and click the "View Certificates" button. In the dialog which opens, select the "Servers" tab, and click the "Import..." button. Select the certificate file from where you placed it when you downloaded it, and you should be done.
Google Chrome
Google Chrome also uses Windows' certificate system, so the instructions are the same as for Microsoft Internet Explorer, above.


So right about now, if you are not already knowledgeable about encryption and computer security, you are probably either cursing us outright, or at least wondering what the fuss is all about—after all, most sites seem to be able to do fine without these elaborate instructions, don't they?

Well, there are at least two reasons why we impose on your peace of mind. First, a certificate like those normal sites use are issued by certificate authorities such as Verisign or Thawte, who charge quite an amount for their services. Seeing how we are not overly fond of protection rackes, we respectfully decline.

Second, and arguably more important, is a conscious statement that the certification infrastructure is broken and in dire need of revision. To fully understand why, a bit of knowledge about SSL and encryption in general is required, a high-level overview of which will follow in my own words. For more information, please read the above linked Wikipedia article on SSL, or take a course in computer encryption. Chances are that you are using SSL for secure on-line banking or other sensitive services, and would benefit much from such knowledge either way. If you want to start reading about the problem realization, skip down to the heading "The Problem of Trust".

Basic Introduction to Cryptography

To begin with, what does SSL really do? Well, most people are at least aware that non-encrypted communication can be overheard by a cracker, which is obviously a bad thing when sending passwords or on-line banking PIN codes or other sensitive information. To solve that particular problem, SSL performs encryption, strong enough to make it next to impossible for a cracker to listen to the traffic. However, a lesser-known, but much more potent, attack is called the "Man in the Middle Attack" (or MITM attack), so called because a sufficiently skilled cracker can enter in the middle of a conversation between your computer and the server to which it is talking, and not only listen to the traffic, but also modify it arbitrarily. The implications are dire – even if the traffic is encrypted, you might be talking to a cracker rather than the web server you think you are talking to. The cracker would just re-encrypt the traffic and send it on to the target web server, so you would think that you are talking to it. In other words: In order to ensure secure communication, SSL must not only make sure that no-one but whom you are speaking to can listen to the traffic, but also make sure of whom it actually is that you are speaking to. (Note here that this also means that a cracker may even have intercepted this traffic and inserted faux instructions in this very web page!)

To solve the problem of the MITM attack, SSL performs not only encryption, but also authentication of the server. In other words, it checks so that the computer with which your web browser is talking is the one you think that it is. To do so, it makes use of cryptographic certificates. In the case of web traffic, the server's certificate contains the server's domain name ( in our case), and when your web browser connects to the server, it verifies that the domain name in the certificate that it is presented with by the server matches the domain name that it has attempted to connect to. A certificate is signed by one or more other certificates. A signature in the cryptographic sense is data that can only be produced by that certificate's owner, but can be verified by everyone who has a copy of the certificate. (The process of producing a signature with those properties is one of a mathematical beauty not often seen elsewhere in practical applications, and I would implore any mathematically inclined readers to check out Wikipedia's article on RSA for all the gory details.)

The real problem, and the heart of the matter, is to determine which certificate signatures can be trusted for verifying the identity of a web site. How does one know if the certificate is correct, after all? If a cracker is about, he may well have modified the certificate and its signatures as well. The trick is to have pre-verified at least one of the certificates in a way that you can trust. As mentioned briefly above, the certificates normally used by web sites have been signed by a well-known certificate authority company, such as Verisign or Thawte. Those companies are called "well-known" because their certificates are shipped with the default installations of all common operating systems. In other words: When you buy a new PC, their certificates have already been preinstalled on it. That is why they can be considered trusted to be genuine. (Of course, it should be noted here that even this trust implies that you trust the company from which you bought the PC not to have tampered with the certificates.) Concisely, when you connect to an SSL web site whose certificate has been signed by Verisign, your browser already has a copy of Verisign's certificate that it can use to verify the validity of the web site's certificate.

The Problem of Trust

The problem, then, is that this implies that you need to trust Verisign and Thawte to properly validate all the certificate requests that they get—people in an extremely large, bureaucratically weighed-down enterprise that process thousands of certificates daily using automated processes. What are the chances that they wouldn't let one single mistake slip through, and issue a certificate to a cracker for a site that he does not own? The problem does not end there, however: The certificates pre-installed on new PCs are not limited to Verisign and Thawte. They commonly ship with the certificates of around 50 different certificates organizations. Even if you feel secure in trusting Verisign and Thawte (which you should not, but more on that later), what are the chances that all of these can be trusted to consist entirely of incorruptible people and flawless processes? And, even if they did, what are the chances that all of them are completely secure and cannot themselves be cracked to produce faux certificates? For this reason alone, I, for one, would consider the entire process flawed and untrustworthy, and I would implore you to do the same. Therefore, Haven & Hearth uses its own, self-signed SSL certificate, bypassing the certificate authorities. To further clarify my point, the following three points of policy are noteworthy:

The Problem Is Not Fictional

But hold on, there is more to this. You may have read the preceding paragraph and still thought it all right to trust all these diverse organizations. However, you really should not: it is well documented that Verisign actively produces faux certificates for various purposes, especially for law enforcement agencies, so that they can perform MITM attacks. You can see Verisign's own home page if you doubt it. What Verisign's faux certificates mean in practice, is that their holder can impersonate any web site, to listen to the traffic between them and their visitors, modify their content arbitrarily and catch any and all sensitive information. And by that, I really mean any web site, not only those with certificates signed by Verisign in the first place. See, when the browser performs its certificate authenticity check, it checks the web site's certificate against any of its installed certificate authorities, and it does not even warn you if the web site's certificate has changed since the last time you visited it, as long as it is signed by just one of the certificate authorities it knows of. Of course, it is not only Verisign which is bestowed with this power – any of the certificate authorities can do the same. Verisign and its "subpoena compliance" faux certificates aside, how secure do you really feel trusting such companies as GoDaddy—who have been the target of industry-wide criticism for controversial practices—to never do anything of the like? How about ABA.ECOM, the top Google search hits for which are sites with people asking who they are? How about the Chinese governmentally owned C&K HKT?

To summarize, what I am trying to convince you of, is that normal sites, whose secure traffic "Just Works" without having to go through the elaborate instructions detailed at the top of the page, really only provide a false sense of security. The price of actually being able to trust someone should not be taken as lightly as common Internet practices make it seem. Surely, you would not trust a person whom you had met in real life with your credit card number or banking details merely because he stated to be sent by your bank? Those same practices that everyone uses in real life should be used when trusting people on the Internet as well – and arguably even more so on the Internet, where one cannot even tell the face of whom one converses with. In closing, for a more reasonable on-line scheme of trust, please read the Wikipedia articles on PGP and its Web of trust.