Badges and Tests

Badges and Tests

Everyone loves a badge or a sticker don’t they. There are so many websites which display a Trusted/Verified logo like these: Some badges that claim a website is secure Those in the know are more than aware that these are easy to fake; and as such mean very little.

That being said everyone loves a badge! So here are a few that actually do matter and relate to melodiouscode.net. You can verify them all using the links provided!

SSL Labs

Verify Here SSL Labs verifies the level of transit security used by a website; the types of encryption available, the use of HSTS, etc. A screenshot of the results when scanning this website with the SSL Labs Tool

Securityheaders.io

Verify Here securityheaders.io is a service run by Scott Helme which checks other important security features such as CSP, XSS protection, etc. A screenshot of the results when scanning this site with the SecurityHeaders.io website

Mozilla Observatory

Verify Here The Mozilla Observatory works in much the same was as securityheaders.io but goes into a bit more depth in some places. A screenshot of the results from scanning this site with the Mozilla Observatory

HSTS Preload

Verify Here You can read about HSTS and the PreLoad directive in my ‘HTTPS is just the tip of the sword’ article. HSTS Preload screenshot showing this website is pre-loaded

Cloudflare

This website is served via the Cloudflare system; caching the site at an edge node near you. Along with caching Cloudflare also provides HTTPS, improved load times, and enhanced security. Cloudflare logo badge

The old ones are always the best

Valid CSS!

Valid CSS!

Thank you to @neonbrand for providing the header image for this page for free on unsplash.com.

Read more

In the beginning there was 1.1.1.1

In the beginning there was 1.1.1.1

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! 1111-1 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’! 8888-min 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

HTTPS is just the tip of the sword

HTTPS is just the tip of the sword

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.

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:

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

Remember to clean up your services; WCF Clients need love too

Remember to clean up your services; WCF Clients need love too

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! profanity 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