2019

As software developers, we often want to talk to services over the internet, usually using HTTP. However, it’s now very common to see online services using HTTPS – an extension of HTTP which enables secure communications over a network.

This move has made life more interesting for developers who want to interact with these services. Most of the time, connecting to a host over HTTPS “just works” from Java, but sometimes things don’t quite work … and Java can be a bit cryptic in how it reports the failure.

Chain of Trust

When a Java program connects to a host over HTTPS, it’s important to know you’re really communicating with who you think you are. If I write a program which connects to https://www.example.com, then I’m sending information over a secure channel. How can I be sure I’m not talking to a malicious third party who is somehow intercepting my traffic, such as user credentials?

The identity of a server is proven with certificates. As an overview, when a Java program connects to a host over HTTPS, before secure communication can take place, the server sends back its certificate. Java then verifies that this certificate was issued by a legitimate Certificate Authority (CA). This is possible because Java ships with a trust store, containing a white list of trusted Certificate Authorities. As Java updates are rolled out, from time to time certificates are added to (or removed from) this trust store.

Ciphers

So far, we’ve looked at how certificates can support the Authentication property of HTTPS. The certificate also enables a second property of HTTPS – Encryption of the traffic. This encryption is possible because the certificate contains a public key which allows clients to encrypt data, so only those holding the corresponding private key (the website owner) will be able to decrypt.

This encryption is achieved using ciphers. There may be a range of ciphers available on both ends of the connection, and the cipher chosen for the communication will be agreed in the initial TLS handshake. If no cipher can be agreed upon – say if the web server wants to use a strong, modern cipher such as AES 256, and Java cannot support that cipher, then Java will fail to connect with the message we saw earlier: Received fatal alert: handshake_failure.

Perfect Forward Secrecy

At the present time, with the possibility of data breaches and digital eavesdropping, privacy is an important subject. What’s to prevent a malicious third-party from collecting traffic going to or from a website?

It might seem adequate to use HTTPS to encrypt traffic to a website, meaning it’s impossible to decrypt the traffic unless you also have access to the private key. But what if a malicious actor collects encrypted traffic over a long period of time? They may not be able to decrypt the traffic just yet … but what if at a later date they recover the private key which secures the website? Would they be able to decrypt all the collected traffic?

Here was composition project for part 3 of the Developing Your Musicianship course

Here was composition project for part 2 of the Developing Your Musicianship course

I spent some time in early 2019 learning more about music composition.

I found a four-part course from Coursera called Developing your Musicianship. This course looked particularly interesting because it went beyond the basics into more interesting subjects such as extended chords.

It’s a four-part course, and I was most interested in parts 3 and 4. I couldn’t access these parts until I’d completed the first two, so I did need to review some familiar material. It was worthwhile as it gave me good experience writing and finishing composition projects.

Here was the output of part 1 - a twelve-bar Blues progression.