Hayden Hudson
Explaining SSL/TLS using Game of Thrones
Any fan of the Game of Thrones series can appreciate that the characters have a Secure Communication problem. Secret messages being intercepted is a frequent plot point as is apparent in the following scene from Season 7:

Clearly Daenerys and Jon Snow (the King in the North) are having trouble keeping their messages private - what can they do about it and what can the modern system of SSL encryption offer them?

As a quick primer- SSL or Secure Socket Layer a.k.a. TLS or Transport Layer Security encryption describes the modern standard which savvy internet consumers depend on to know not only that they are accessing the official website of their choice but that their traffic with said website cannot be spied upon.

How does it work? It uses a public key cryptography system based upon the RSA Algorithm. Don’t worry if you are not familiar with this concept, this article is not very technical and is certainly not about math. Let’s establish only that the RSA Algorithm encrypts and decrypts messages using functions that are inverses of one another:

Encrypt : c = me mod n
A message m is encrypted to become code c, using exponent e and public key n
Decrypt: m = cd mod n
In the reverse, Code c is then decrypted back to message m using exponent d and public key n

Again, this article is not about math. But it may be helpful to know at least this much. For more on the RSA Algorithm, you can check out my other post on this subject.

Compliance with the SSL standard is advertised with the designation of ‘Secure’ in your browser bar, as below:

You may have noticed in recent years that this is an increasingly ubiquitous feature of the modern web. Indeed, now that free ssl encryption services like Let’s Encrypt have emerged, the speed at which this standard gets adopted is likely only to accelerate.

Theory in practice

Let’s engage creatively with how TLS Encryption works and how Daenerys and the king in the north could use it to keep their communication private. Currently, if Daenerys sends a message to King Snow, any number of people can potentially intercept it. As a result, Daenerys is inhibited in her ability to send high stakes content.

The handshake

Here’s how our 2 characters can coordinate so that Daenerys can send Snow a secure message. The 1st step in the TLS Encryption system is called: The handshake.

Snow initiates the Handshake process by bundling up the following 2 things:

Game of Thrones SSL system
Number 1: An unlocked padlock, to which only he has the key. In the RSA Algorithm the unlocked padlock is roughly analogous to public key n and exponent e, and his key is exponent d.
Number 2 : He makes sure to include Strong evidence that the padlock is coming from him - which we’ll assume is a variety of seals and signatures. This would be the equivalent of his SSL/TLS certificate.
He sends this bundle to Daenerys by raven, but holds onto his key.
Continuing the handshake process, upon receipt of Snow’s bundle of goods, Daenerys may consult the most impartial third party authority she can find - say Tycho Nestoris of the Iron Bank of Braavos, to confirm the authenticity of the Stark seal. In the TLS system, this step is the equivalent of Daenerys’ browser checking the digital signature in Snow’s SSL certificate against an existing library of official root certificates.
The unique cipher

Satisfied that the padlock is authentic, Daenerys initiates the 2nd step in the TLS process : The Unique Cipher.

Snow initiates the Handshake process by bundling up the following 2 things:

Game of Thrones SSL system
Daenerys commissions her metallurgist to craft 2 unique keys (one for herself and one for Snow) and one associated padlock. In SSL system, this step is the equivalent of Daenerys establishing a unique cipher for her web session.
Daenerys then completes the process by enclosing her newly forged padlock and one of the 2 associated keys inside of a box, locked using Snow’s padlock.
She can now sending him the bundle, confident that only Snow can access her newly forged key (or cipher).
In a browser, this is analogous to Daenerys encrypting her cipher using the RSA algorithm : Her message m is encrypted to become code c, using the public encryption parameters Snow sent her, namely exponent e and public key n.
Upon receipt of Daenerys’ envoy, Snow can easily unlock / decrypt it, using his private key. Code c is then decrypted back to message m using exponent d and public key n.

Now that Snow has the unique key and padlock / cipher that Daenerys created, they can send padlocked content back and forth securely knowing that only the 2 of them have the keys to unlock it.

Limitations of the analogy

Of course, you’ll notice in this hypothetical scenario, that Snow doesn’t take the trouble to authenticate that the padlock is coming from Daenerys and this where our analogy for SSL encryption falls a little short. In this analogy, Daenerys represents a common web user, like you and me, and Snow represents an TLS encrypted website, like google, facebook and amazon. In the real mechanics of SSL encryption Amazon engages in TLS handshakes with millions of anonymous users every hour. Their method of authenticating users is not TLS encryption but rather it is requiring users to sign up and sign in.

The limitations of the analogy being what they are, let’s persist down this path a little further to make a few more important points about TLS encryption.

Man in the Middle Attack

As may or may not be obvious so far, the real challenge to the modern TLS encryption system is actually not the encryption part but rather the authentication part. When we visit google in our browser or when Daenerys gets a message from Snow, how do we know the authenticity of the content we are consuming and how does Daenerys know that someone isn’t impersonating Snow in an attempt to perform a ‘Man in the Middle’ attack?

Using Game of Thrones analogies, Petyr Baelish could falsify the Stark seal and attempt to convince Daenerys to exchange ciphers with him and intercept her messages to Snow. He could further improve the charade by impersonating Daenerys with Snow with another TLS handshake and he can relay their messages to one another in a convincing fraud. The most dangerous part of the fraud is that Daenerys and Snow may relax their vigilance because they know their communication is encrypted.

Certificate Authorities

So Tycho Nestoris of the Iron Bank of Braavos in this scenario is performing an extremely valuable service when he authenticates that the Stark seals are the real thing. Who performs this Trusted Third Party authentication service for us common web users? Purveyors of this service include:

These so-called ‘Certificate Authorities’ coordinate with your browser to authenticate the public keys of the TLS encrypted websites you visit. To spell it out, your browser stores a library of root certificates which can confirm that the the public key being disseminated by the amazon.com you are visiting in your browser, matches the public key that amazon.com published when it initiated its TLS encryption.

System Weaknesses

It bears saying of course that the TLS system has some weaknesses, some of them possibly unavoidable.

An important example: the system depends upon users paying close attention to the content in the url bar. At first glance, you may not immediately spot the differnence between, say:
amazon.com and arnazon.com.
TLS encryption is not intended to be an endorsement of the business practices the website engages in.

A second (possibly obvious) weakness - TLS encryption is difficult but not impossible to crack. Certainly, say, a government with a team of programmers would have little problem, for example, cracking GoDaddy’s private key and thereby spoofing any website of they want.

Concluding remark

With this in mind, Users are of course encouraged to maintain their vigilance when browsing the web.

All in all, the TLS encryption standard is a complex and powerful feat of social coordination. I hope using Game of Thrones scenarios helped liven up what could otherwise be a rather abstruse subject.

Date : Sept. 11, 2017