HTTPS What is it good for….

By kamui 12 Dec, 2018 Leave a comment

Quite a lot really, I know that’s not how the song goes but, HTTPS, the common abbreviation for Hyper Text Transfer Protocol Secure, is a requirement of all sites you visit, and really you should be questioning the authenticity of any site without it. Even if you are not logging in or giving over payment details, it is important for a number of reasons.

What really is it?
HTTP, or the Hyper Text Transfer Protocol, is the protocol of the web, it is how web pages are delivered to you, it is stateless, which means that each request is independent of another (essentially you arrive on the site and the server and request a page and the server responds, you click on a link to get another page and as far as the server is concerned you are a completely new person). One thing you should always be aware of is that the information sent over HTTP to the server and back to you is plain for anyone to see, read or modify.

HTTPS is end-to-end encrypted HTTP traffic using TLS (Transport Layer Security) or SSL (Secure Sockets Layer). Both the TLS and SSL protocols use what is known as Public Key Cryptography. An asymmetric system uses two ‘keys’ to encrypt communications, a ‘public’ key and a ‘private’ key. Anything encrypted with the public key can only be decrypted by the private key and vice-versa. As the name suggests, the ‘private’ key should be kept strictly private and should only be accessible the owner of the private key. In the case of a website, the private key remains securely held on the web server. Conversely, the public key is intended to be distributed to anybody and everybody that needs to be able to decrypt information that was encrypted with the private key.

When you request an HTTPS connection, the website will initially send its SSL certificate to your browser. This certificate contains the public key needed to begin the secure session. Based on this initial exchange, your browser and the website then initiate the SSL handshake. The SSL handshake involves the generation of shared secrets to establish a uniquely secure connection between yourself and the website. At this point, the certificate is checked against a certificate authority to check that it is valid and you are really communicating with the website you think you are communicating with.

HTTPS protects more than just form data! HTTPS keeps the URLs, headers, and contents of all transferred pages confidential. Any website that requires login credentials should be using HTTPS. In modern browsers such as Chrome, sites which do not use HTTPS are marked differently than those that are, in April 2018, Google Chrome has started flagging all non-HTTPS websites as insecure, which they are because your information is not protected between the server and the end user over HTTP.

You’ll hear a number of arguments against using HTTPS, most of which are based on old information or are just plain wrong.

I don’t have anything sensitive on my site. It is just a static HTML page.
The internet is not just your computer connected to their server, there are a lot of other pieces of hardware, organisations, and governments, in-between, such as your coffee shop, their Internet Service Provider, a government (not necessarily yours). Do you really want someone injecting scripts, images, or ad content onto your page so that it looks like you put them there? Or changing the words on your page? Or using your site to attack other sites? HTTPS prevents all of it. It guarantees the integrity of the data and the ability to detect tampering.

HTTPS certificates are expensive
No, letsencrypt provides certificates free of charge. This used to be the case 10 years ago, but most certificate issuers now provide HTTPS certificates free of charge, and the ones that do charge are only charging for support or administration.

HTTPS is slow
This was because the server had to do more work, to encrypt the data, but this argument is no longer valid. In fact with the invention of HTTP/2, due to the compression that it offers, HTTPS is now faster than HTTP.


Source: https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/

We hash our passwords and encrypt our data at rest.
Great! But what about when it travels between the server and the visitor to your site. Don’t get me wrong, this is good security practice, to encrypt your sensitive data but only protects data at rest. If you are not using HTTPS, your data is transmitted as plain text for anyone to read.

Attackers can still impersonate my website, even if I use HTTPS.
They can certainly try, this is the reason for Certificates, to make sure you are communicating with is authentic, i.e. is who you think you are communicating with. If attackers present a mismatched or invalid TLS certificate. And if the attacker does not use HTTPS at all, browsers should mark the imposter page as insecure.

Phishing sites use HTTPS
Yes, so what, does that mean you shouldn’t use it yourself?!

HTTPS impacts SEO.
Yes that’s correct, in most cases it improves it. Google ranks HTTPS sites higher than non-protected sites.

Why Building security backdoors into software is a bad idea

By kamui 19 Jul, 2018 Leave a comment

This should be obvious, but on the surface, to reasonable people, this seems reasonable. If bad people are doing bad things and the police can get enough evidence to approach a court, they can get a wire-tapping order, which will allow them to intercept any communications in the mail, or telephone that will allow them to gather evidence against the criminals.

TLDR; the basic idea is flawed and it puts individuals at risk.

This seems like an invasive but reasonable approach to protect public safety, and why software should be different? Why should there not be a master key that opens the encryption locks that criminals are using to conduct their nefarious activities? It is just those pesky software companies preventing the police from protecting us from criminals, who want to do us harm. We should make them change and allow the police to view these hidden communications. This seems reasonable, at least until you think about it.

This basic premise assumes that the ones controlling the master key or even the company that makes the software are infallible, there could never be any bugs, and there could never be anyone in those organisations who could be bribed or coerced to reveal the key, an overworked, stressed, or sleep-deprived individual could never mishandle it. This is building an intentional flaw in a defence, like the infamous drain in Helms Deep from the Lord of the Rings.

and that ended well for the men of Rohan.

This also assumes that the organisation that wants the protection can instruct the organisation that makes the software to make this weakness, and that criminals would not just use something else. True the government could restrict sales of the software to disallow the sale of software without the backdoor in force, but again this assumes that criminals are only going to use software that is legal within that region, because of course criminals are well known for following the law. The basic idea is flawed and it puts individuals at risk.

Test Driven Development (TDD) – A practical example

By kamui 1 Jul, 2018 Leave a comment

Recently the development teams here have been improving their coding skills by taking on the challenge of Clean code, a practice by Robert C. Martin (Uncle Bob) who has a number of very informative clean code books and clean code videos practised by many developers and to improve the quality of their code, so they can code faster.

If you want to go fast. If you want to get done quickly. If you want your code to be easy to write, make it easy to read. The only way to go fast—is to keep the code clean.

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Clean code is not the topic of this post though, I’ll leave that for another day. Today I’m going over the practice of TDD – Test Driven Development.

It has a number of advantages:

  • The biggest and most important is that it eliminates fear of change – refactor or modify at any time with no fear.
  • Reduce debugging time by between 50-90% – imagine a group of developers and pick one, any time, sometime in the last minute everything that person was working on worked and all its tests passed. It doesn’t matter who, it doesn’t matter when. Being good at the debugger is not a desirable skill, being good at the debugger, means you are experienced at interacting with bad code.
  • Reduce defects
  • Unit tests are the best low-level design document. If you want to do something, you can just copy the test that does it.
  • Writing tests first will mean that you write code that is testable, in other words, decoupled.
    This in turn Saves time, reduces estimates, which reduces costs
  • Avoid the grand cleanup – which inevitably fails due to lack of tests.
  • Increased confidence in the quality of the code – in the example app, if the tests pass they ship it. Your tests are like a parachute to prove your system works, imagine you are working on the code a life support system that you yourself might need to use at some point. Would you trust a system with its tests, would you jump out of an aircraft with a parachute that has holes in it?
  • Writing tests afterword is procedural, it is required of you for your job, but it feels like extra work for little gain. You already know your code works, because you have manually tested it, the danger then is that you take shortcuts with your parachute.

The 3 Rules of TDD

  • Write only enough test code to make it fail
  • Write enough code to make it pass
  • Refactor then repeat

The cycle is only 30 seconds to a few minutes long but it leads to code which you can have confidence in, code which you can entrust your life to.

Take the following example, I’ve taken the liberty to fill in the first few steps as comments so you can repeat the steps and then expand on them.

The Example

Below, you will see the typical High School computing problem of building a calculator, the requirements are simple to start with but slowly grow with complexity, but this can easily demonstrate TDD. See the jsFiddle site for the example.

Requirements

  1. it needs be able to sum multiple values
  2. it needs be able to able to subtract multiple values
  3. it needs to be able to multiply multiple values
  4. it needs to be able to divide one value from another
  5. it needs to be able to work with floating point numbers
  6. it needs to be able to calculate the value of an input number to the power of another number.
  7. it needs to be able to calculate the square root of a value
  8. it should have the ability to take a string of calculation values and compute the correct result.
  9. it should be able to handle multiple operators at the same time.
  10. it should output values to 5 decimal places
  11. it would be good if it could have a text field and button that when pressed would validate and calculate a user input calculation.
  12. it would be good if it could generate the calculations from calculator buttons

The application is written in Typescript and uses Jasmine as the testing framework. It starts with the simplist failing test, implement the calculator class, which can easily be made to pass by uncommenting parts of the code above.

To simulate the cycle, uncomment each test one at a time then uncomment the respective code to make it pass. Repeat this process until all the tests pass and the begin the 3rd acceptance criteria “needs to be able to multiply multiple values”.

Write the failing test and then implement it in the same fashion.

NDC – Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

By kamui 4 Aug, 2017 Leave a comment

I have recently been listening to a few of the NDC talks from around the world and the one today that has caught my interest is this one, Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks by Kevlin Henney.

I particularly liked the inclusion of FizzBuzz Enterprise Edition. For those that don’t know FizzBuzz is a simple programming challenge, that used to be and still is in some organisations an interview question.

The problem is

For numbers 1 through 100,

if the number is divisible by 3 print Fizz;
if the number is divisible by 5 print Buzz;
if the number is divisible by 3 and 5 (15) print FizzBuzz;
else, print the number.

It is not a difficult problem, and it can be solved in a few simple lines of code.


def fizzbuzz(n):
if n % 15 == 0:
return 'FizzBuzz'
elif n % 3 == 0:
return 'Fizz'
elif n % 5 == 0:
return 'Buzz'
else:
return str(n)

there are even more concise versions of this code but this is simple to read and understand.

What FizzBuzz Enterprise Edition does is humorously take certain enterprise software design principles to their extreme.