Monthly Archives: January 2016

Closure of Nominet Registrar Account ‘AUSTIN’

2 Replies

On Friday 22nd January 2016, I formally gave 30 day notice to Nominet for the closure of my registrar account.  This post details the reasons for this.

Nominet contacted me stating that they were going to link my registrar account with that of my employer due to their “connected persons” section of their AUP.  I should note that I had never seen this section before, so it must have been added since I became a registrar.

I contacted them detailing that my personal account was for the express purposes of keeping my private and business life separate… including that I go as far as to have provider independant IP address space, my own Autonomous System, BGP routers and servers – all separate from my employer.  I stated the fact that I had been (save for a short break) a Nominet member for longer than I had been an employee of my current employer too.

In response I received:

I have spoken with our legal team with regards to your information, however, they have advised that we need to link the services in regards to the acceptable use policies (Anti-avoidance and Connected Persons link below).

Obviously my employer would be rather upset if anything I could do in my personal capacity could affect them in any way (it’s a fair expectation of an employee), so I was left with no alternative but to serve notice on my registrar account with the minimum possible term (30 days)

Nominet’s AUP (whenever it was added/updated) contains the following description of connected persons:

A person is ‘connected’ to another person if:

  1. they are the same person, have the same Nominet account, or have connected memberships under the voting rights policy;
  2. they make any declaration that they are connected or when challenged by us they fail to make a declaration in the reasonably required legal form that they are not connected;
  3. they have social, family, ownership or business links (directly or indirectly) which mean that they either:
    1. do not appear to operate truly independently of one another, or
    2. it could reasonably be assumed that they will not operate truly independently of one another; or
  4. the object or effect of their activities is such that we reasonably think that not linking them would compromise one or more of the AUP Principles.

For the purposes of (2) we may decide that two parties are not connected even if one declares that they are, if the other disputes this and our investigations support the denial (so, for example, you cannot just declare that you are linked to another person and then use all their limit up to disrupt their business).

For the purposes of (3) there is a strong presumption that:

  • group companies (or other businesses) are connected to other businesses in the group;
  • a company and its employees/officers/partners are connected to one another;
  • members of the same family group are connect to each other (including in-laws, co-habitees, civil partners, adopted children and others who may not have a relationship by blood but who are part of the family group); and
  • a business owned, run or ultimately controlled by one member of a family is connected to a business owned, run or ultimately controlled by another member of the same family.

The final decision rests with us. When deciding whether to link people under (2) to (4) above, we will take into account the AUP principles.

I’m unhappy with so many things in the above snippet that I don’t even know where to start…

In short, Nominet have lost my annual membership fee (i’m sure they won’t be concerned about this given that they make more profit than their non-profit status allows anyway), but also one of their last registrars who had implemented their entire feature set.

I have recommended to any people with domains on my account to migrate to another registrar ASAP.  For those without a preferred registrar, I have suggested PortFast as they appear to have a similar feature set to that I had offerred.

This follows a disturbing trend within Nominet which I wont go into in this post.  Feel free to use your favourite search engine to lookup recent events at Nominet if you want to read further.

In an age where ICANN are dishing out new TLDs constantly, you would expect Nominet to be trying to strengthen the .uk brand but instead recently it seems to be trying to harm it.

In light of this, I have been considering migrating my main domain name away from the .uk namespace to one of the more level-headed registries.

HTTP Public Key Pinning (HPKP)

Leave a Reply

As we move into an more secure environment, simply have HTTPS isn’t sufficient.  Many cases of forged SSL certificates for man-in-the-middle attacks have appeared recently.

These can be obtained through deception or hacking attemps on SSL CAs.

One method to help combat this is HTTP Public Key Pinning (HPKP) – this is where the webserver can communicate to the web browser an allowed certificate path, with a sufficiently long expiry time to be of use to return visitors.  It’s not perfect or ideal, but it’s better than nothing.

This post does NOT detail the most secure method of HPKP but a compromise in terms of usability vs security.  It will ensure that an unauthorised certificate would need to have been generated by one of your chosen SSL CAs only.  The more secure method of having dual online and offline keys is out of scope for this blog post and a more advanced topic.

The way this works is to publish a header in the HTTPS response detailing the allowed hashes of public keys of webserver keys or keysigner keys that are permitted to be in the certificate chain.  This is in addition to the normal process of validation of the full SSL certificate chain.

BEWARE: misconfiguration of this header can lead people to be unable to view your site for MONTHS so be careful!

First let’s look how to obtain the SHA-256 hash needed for a certificate.  We use OpenSSL to do this based on the .crt file… Let’s assume the certificate is in the cert.crt file…

openssl x509 -pubkey < cert.crt | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary| openssl enc -base64

This will provide a Base64 encoded string which we can use later.

Now we provide the information to the webserver… i’ll detail Apache 2.4 here, but other servers will have similar methods of adding header outputs.  We add the following into the VirtualHost block for the SSL site:

Header always set Public-Key-Pins “pin-sha256=\”HASH\”; pin-sha256=\”HASH\”; max-age=30;”

where the Base64 has generated previously replaces the first ‘HASH’.

HPKP requires a minimum of 2 hashes to be present, including one hash that is NOT present in the certificate chain.  This is to encourage you to ensure you have a backup plan.

In my examples, I use the hash of my SSL public key and the hashes of my chosen primary and secondary SSL certificate authority’s intermediate certificates.

In my case, I use StartSSL’s class 2 intermediate and RapidSSL’s SHA-2 under SHA-2 root intermediate.  To generate their hashes, use the above OpenSSL method on their CA certificates.

This means that I can use my existing key/csr with any SSL CA, or I can generate a new key with my primary or secondary CA.  It also satisfies the requirement for one of the hashes to not exist (my current certificate is not present via my secondary CA)

The max-age above is set to 30 seconds for testing purposes… once you’re completely happy with your choice, this should be raised to a much longer figure.  I use a 30 day period (2592000 seconds)

A good method of testing is to use Qualys SSLlabs tester at https://www.ssllabs.com/ssltest/ – this will show you the pinned list, including any currently in the chain in a different colour.