There is no place like 127.0.0.1 Dorothy (after she graduated from MIT)

The old saying “there is no place like home” is often translated to “there is no place like 127.0.0.1” by us geeks. 127.0.0.1 is what is known as the “loopback address”, every single computer device uses that IP address to reference its self. In effect 127.0.0.1 means home to the computer. Yesterday (yes April Fools Day, it was not a joke), cloudflare released a new DNS Resolver service by the name of 1.1.1.1 and it is exciting! For those who do not know what DNS is, or how it works here is a quick and dirty breakdown.

What is DNS and how does it work?

The internet is big and full of numbers; we call these IP Addresses which are a string of four sets of numbers (for now, but that will change in the future), at the time of writing the IP address behind melodiouscode.net is 104.25.29.109.

It is a lot easier to remember words than it is to remember numbers; that is why you type google.com rather than 216.58.208.174. This means that the internet needs a way to translate the words into the numbers; along comes DNS. The Domain Name System (DNS) is basically a giant phone book for the internet. Every name is in there (ignore the dark web for now) and its corresponding IP address is listed.

When you access a domain name (like google.com) your computer performs a “DNS Lookup” to resolve the name to an IP address. The “DNS Server” at the other end responds and tells your computer where to go.

If you want to read more about how DNS works check out the Wikipedia Page for the Domain Name System.

What is 1.1.1.1 and why is it amazing?

1.1.1.1 is the new “DNS Server” from cloudflare; it does everything a DNS server is meant to do (be a secure and trustworthy phone-book).

Unfortunately, some DNS servers are not very trustworthy; some have been known to hijack sessions (directing you to the wrong website), others are known to record everything you do (track the websites you visit). Your Internet Service Provider (ISP) will provide you with a DNS address by default, my ISP (virgin media) hijack every invalid DNS record (when you make a typo or try to visit a site that does not exist) and serve you their own search results page. These typo-squatting DNS pages are often filled with tracking cookies, adverts, and sometimes malicious data.

The new “DNS Server” from Cloudflare is the complete opposite, they promise to never track you, and to delete their logs every day so that your browsing habits are kept private. That statement is easy to make, many providers have claimed that privacy is important to them, and many have lied. Cloudflare has promised that they will be audited once a year by KPMG who will release a report with their findings.

How do I use 1.1.1.1?

I am not going to attempt to write a detailed set of instructions here, as one already exists. Just navigate to https://1.1.1.1 and you will find Cloudflare’s own explanation and instructions for using the 1.1.1.1 service. Enjoy!

Why have they done it?

Oh, you’re still here, cool. The DNS system is broken, it is not secure and can be tampered with. One of the larger tampering to hit the news recently occurred in Turkey. The government of Turkey blocked twitter at the root level of the countries internet system; the ISPs were forced to block the resolution of twitter.com to it’s IP address in their “DNS Servers”. The Turkish Government did this after some embarrassing videos about Government corruption were shared on Twitter; imagine what would happen in the UK if the government blocked twitter every time someone said that ‘Theresa May stinks’! Some of the “geeks in the know” in Turkey resorted to spray painting 8.8.8.8 (Google’s own DNS Server) onto walls in an attempt to help people bypass the block!

Cloudflare has designed it’s new service from the ground up to be secure, private, and auditable. They have baked in two new technologies ‘DNS over TLS’ and ‘DNS over HTTPS’; one of these will, in the end, form the backbone of future DNS, and 1.1.1.1 supports them both already (not that is future proofing). Cloudflare is also in a unique position to provide this system; considering they already provide access to a massive percentage of the web via their authoritative DNS provider they already know where everything is; making that phone book lookup lightning fast. Their server infrastructure is also worldwide (they opened a new data centre every day during March 2018), so there is always a server near you.

Why not just use Google’s server?

True you can use Google’s DNS Server (8.8.8.8, and 8.8.4.4); many people do not trust a company which makes its money on data to serve their DNS results. So a truly private (and openly audited) system like 1.1.1.1 (and 1.0.0.1) is a preferred alternative.

Also in a time when we are feeling about the about of data Facebook stores about us (and yes Google do the same) do we even want to think what the likes of Virgin Media, BT Internet, Sky Broadband, and the like might be storing? The USA even made it legal for their ISPs to sell the DNS data about their customers!

You can read more about Cloudflare’s new service on their blog.

The header image for this post was taken by Maarten van den Heuvel and provided for free on unsplash.com. Thank you Maarten, it is a sad sign of the times when it is so hard to find a photo of a phone booth with a phone book still attached!

Read more

This post is part of a series on HTTPS and browser security; it is partly to spread knowledge, but mostly to allow me to learn more about the subject by putting it ‘down on paper’! Enjoy, and please comment, correct, and discuss.

In the previous post in this series I wrote about the basics of HTTPS; what certificates are and how the chain of trust works. The use of an HTTP certificate isn’t a magic pill that makes everything secure, there are several other security techniques which you should investigate. Not every website will require all of these protections, but in general, they are worth considering.

• Strict Transport Security
• Content Security Policy
• X-Frame Options
• Anti XSS Protection
• X-Content Type Options
• Referrer Policy

The articles in this series will focus largely on the above browser security headers; each article will take an individual header and look into it in more detail.

After discussing HTTPS Certificates the sensible next step is to review Strict Transport Security and it’s options. So what is HTTP Strict Transport Security, or HSTS for short?

The Basics of HSTS

Communication with an HTTPS-enabled website is secure; the handshakes between the server and client ensure that data between them is encrypted in transit and can not be interfered with by another party. However, this only applies once the secure connection has been made; if a user directly accesses the non-secure (HTTP) address then the connection is at risk.

This insecure connection can happen if a user types in the address directly (or opens it from a bookmark, etc). For example, if a user were to type somedomain.com direct into the browser it would attempt to access http://somedomain.com. If somedomain.com supports HTTPS and they have done a good job of it then the user will be redirected to the secure side of the domain (HTTPS); in here the problem lies!

The short moment that the user is traversing from their browser to HTTP, and on to HTTPS is a risk. Imagine that somedomain.com is actually yourbank.com. Suddenly the potential gain from hijacking that connection has jumped; step into the connection before it is secured and you could steal the user’s password and gain entry to their bank account. All the while passing back the real website over the HTTP connection they hijacked. This is called a Man in the Middle Attack or MITM Attack for short. To achieve a MITM Attack you do need to have exploited some part of the connection, but this has been shown to be rather easy on free wifi in coffee shops and the like (see this article about the wifi-pineapple).

How can we protect against this? HSTS is the first weapon in our anti MITM arsenal. By sending an HSTS Header a web-server can state that from that moment onwards it should only be connected to via HTTPS (for a configurable duration); gone is the chance for a MITM attack as the browser will now try and create a secure connection from the start (and alert when it fails to do so).

There is one small problem left; HSTS requires that the end user makes a single connection first (which might be over an insecure connection). This still presents a risk to future communication; all it takes is for the attacker to inject a malicious payload into the page to high-jack the users browser (and control future connections); I make it sound a bit simple there but it is possible!

HSTS Pre-Load

The HSTS Pre-Load system has already ridden to our rescue. If you are using a modern browser (which has connected to the internet in recent months) it will be impossible for you to connect to melodiouscode.net in an insecure manner; even if you type in the URL with HTTP. This is thanks to the HSTS Pre-Load header.

The HSTS Pre-load list (https://hstspreload.org/) is managed by the Chromium project (related to Google Chrome). Website owners can submit themselves to the list for pre-loading into browsers. Once pre-loaded a browser (or User Agent to give it the proper term) will only ever connect to a site using HTTPS, this closes the door to the MITM attacks I mentioned earlier.

There are several hoops to jump through to become HSTS Pre-loaded, and it isn’t for the faint-hearted. If you become pre-loaded and then stop serving a valid HTTPS certificate for any reason, then your website may become inaccessible to everyone until their User Agent (UA) is updated to remove your site (which could take a very long time).

How do you enable HSTS?

HSTS is simple to enable, and you don’t have to pre-load. You can just indicate you wish a UA to use HTTPS for visits it makes over a period of time.

Strict-Transport-Security: max-age=60

The above snippet is the HSTS header; it can be set in most web-server environments. It indicates that the server wishes to be communicated with securely for the next 60 seconds! Not overly useful; but you get the idea. You can set it for any period of time you wish: 10 minutes, a day, a week, the next six months, it is up to you.

Strict-Transport-Security: max-age=60; includeSubDomains

The includeSubDomains flag instructs the browser to talk securely with any subdomain of your site (such as blog.mysits.com or shopping-cart.mysite.com).

Strict-Transport-Security: max-age=600; includeSubDomains; preload

The preload flag indicates that the site wishes to be included in the HSTS Pre-load list. REMEMBER this can be dangerous if you don’t always serve a valid HTTPS certificate; use with caution. In effect preloading is a one-time thing; once you are on the list that is it, being removed is not quick or easy and requires you to contact the chromium group manually.

How do I pre-load?

To be pre-loaded you must ensure your website puts forward the HSTS header in a particular way and serves a few other instructions:

1. You must have a valid HTTPS certificate for the domain, and all sub-domains you wish to use (all of them, not just ones you wish to protect with HSTS).
2. All HTTP traffic must be automaticity redirected to HTTPS.
3. All subdomains, especially the www subdomain, must be served over HTTPS.
4. The HSTS header must be served with a max age of at least one year, include subdomains, and the preload flag.

When you have covered all of the above visit the pre-load project and submit your site for inclusion at https://hstspreload.org/. Remember, it is a one-way street.

Want to know more?

Subscribe to my RSS feed and keep an eye out for future articles in the series, or if you can’t wait to check out one of these:

• Is HTTPS Everything? @ melodiouscode.net
• HSTS on Wikipedia @ wikipedia.org
• The OWASP Cheat Sheet @ owasp.org

The Series

1. Is HTTPS Everything?
2. HTTPS is just the tip of the sword

The header image for this post comes from Alex Martinex via unsplash.com, cheers Alex!

Read more

All developers cringe when they start working on another person’s code base; it is never in the state we would like it to be. Mostly that is because we developers are a picky bunch; everything has to be just perfect and nothing anyone else does ever is! Today I have been working on someone else’s project, and the first thing that jumped out at me when I was doing some clean up was that none of the WCF Service calls (well most of them) had been closed. Whilst the program was being run by a single user in debug this wasn’t really a problem, but add more users into the mix and it all goes pear-shaped.

Remember to close your WCF Services

An open WCF Service consumes resources; memory, CPU, and anything it connects to (database readers etc). Especially if the developer of the service expected to dispose of their creations when the client was closed.

Picture this; you call a WCF Service method (let’s call it GetMyStuff(int sessionId)). The GetMyStuff call hits a database to determine what stuff is yours, then to be nice and fast it spawns a bunch of threads to go and get all that stuff from other databases. You now have several connections to multiple databases open; all waiting to be closed when the service client is closed. But no one closes the client!

Normally a database will provide a few hundred possible connections to an application; when they are all open the application has to wait for more. If none of them is closed then the application will wait for a long time!

How do you close a WCF Service Client?

if(clientObject != null && clientObject.State == System.ServiceModel.CommunicationState.Opened){
    clientObject.Close();
}

Just remember to run the above code somewhere after you are done with the client, if you are using the client in a ‘using statement’ just try this:

using(var client = new ServiceClient()){
    ....
    ..
    .
    client.close();
}

Simples!

Thanks to Alina Grubnyak for providing the header image for this post on https://unsplash.com.

Read more

This post is part of a series on HTTPS and browser security; it is partly to spread knowledge, but mostly to allow me to learn more about the subject by putting it ‘down on paper’! Enjoy, and please comment, correct, and discuss.

If you are involved in designing, developing, testing, publishing, or managing a website then you have likely already heard about HTTPS. HTTPS has been discussed from start to finish several times in recent years; by some notable people (Troy Hunt, Scott Helme, etc) and some less notable people (Don’t Take Security Advice from SEO Experts or Psychics). In the past the subject of website security was generally restricted to the purchasing of an SSL Certificate, that has changed! This series of blog posts is aimed at demystifying website security and expanding both my and your knowledge of both HTTPS and it’s supporting protocols.

Part 1: What is HTTPS?

Background

Protocol (computing) noun: ‘a set of rules governing the exchange or transmission of data between devices.’

The internet runs over a protocol called the Hypertext transfer protocol (or HTTP for short). The Hypertext transfer protocol was originally created by the internet giant Sir Tim Berners-Lee at CERN in 1989; it allows the transfer of hypertext (HTML to you and me) over a distributed network of machines (the internet).

HTTP served us well for many years (and continues to do so), but it needed something more. The secure version of the protocol was born with the simple addition of the letter S; HTTPS. Even the most ill-informed of surfers know that the green padlock (or is it a handbag) means that their connection is secure (sort of, more on that later in the series); the HTTPS protocol is what gives us that padlock.

How does HTTPS work?

At it’s most basic HTTPS works by verifying the remote web server is who it claims to be. This is achieved by the use of a digital certificate that states they are who they say they are; think of it like a passport for a website. Taking that passport metaphor a step further; when someone shows you their British passport you know they are who they claim to be. Why, because Her Britannic Majesty’s Government has stated so, and you trust them right?

This ‘chain of trust’ for a passport applies directly to the ‘certificate chain’ used by HTTPS. When you purchased your computer/mobile/etc you indicated that you trusted the people who wrote it’s software; a company like Microsoft, Google, or Apple. Installed on your device are a set of certificates known as root certificates, companies like Microsoft install these certificates because they have explicit trust in their owners (companies like Comodo, Go Daddy, and DigiCert). Not all root certificates are managed by the operating system; your chosen web browser also bundles some certificates and can choose to trust or distrust them itself (more on that later in the series).

Those root certificates are owned by companies known as root certification authorities or root CAs for short. They choose to sell certificates onto the people who create websites; or in some cases, they delegate that trust onto other firms who act as resellers (this has been known to go a bit wrong sometimes, search for Trustico revoke if you want to know more!). So when you see an ‘HTTPS Certificate’ on this website you can trust I am who I claim to be because another firm that is trusted by the software maker you trust has said so! A chain of people, a chain of trust; simple.

Is that it?

The certificate by itself does not make the connection secure; a transfer protocol that is known as TLS (previously SSL, which is an older now less secure encryption protocol) provides the security. When you access a secure website (over https) your browser sends some information to the web server stating which secure protocols it can support. The server then picks one and a key exchange takes place (known as a handshake); this creates a secure tunnel between your browser and the remote server. From then onwards the communication is secure. How this works is a bit in-depth for this simple article, so check back later in the series for a more detailed explanation of how it works (and the dangers when it doesn’t).

Want to know more?

Subscribe to my RSS feed and keep an eye out for future articles in the series; or if you cant wait, check out the HTTP and HTTPS pages on Wikipedia.

The header image for this post came from Giulio Magnifico via unsplash.com.

Read more