Web Standards - An In-Depth Look at IPv6 and HTTPS
Of the many web technologies and standards, IPv6 and HTTPS are among the most relevant for the average system and user. In addition to knowing they exist, it is also important to know how they work and why they function the way they do.
IPv6 - Internet Protocol version 6
As discussed in a previous post, the original internet address system, IPv4, is running out of addresses. While that statement is true and sounds easy to fix, it’s a little more complex than it sounds. IPv4 has existed for a long time - since 1983. This means there are a lot of systems that use it, including modems, routers, servers, toasters, and countless more. Unfortunately, converting to IPv6 isn’t always as simple as flipping a switch or loading some new software.
While the vast majority of new technology is built to support IPv6 by default, there is a lot of hardware still in use that doesn’t support it, and replacing hardware can be expensive and time-consuming.
There is still a lot of work to be done to fully convert the internet to IPv6. Thankfully, over the last decade, many entities have come to adopt and even push for IPv6 as the new standard. Many websites support both, which allows for consumers who use IPv6 networks to make use of it but doesn’t cut off those who haven’t yet caught up and made the change.
HTTPS - HTTP Secure
Hypertext Transfer Protocol (HTTP), is itself insecure; Fairly human-readable, it can be very easy to intercept and tamper with information (commonly called a man-in-the-middle attack). As a result of that obvious security risk, HTTPS was created to safeguard the users of the internet, and make web traffic secure.
That’s where the story ends for most users, but how does this wonderful technology do what it does?
On the surface, HTTPS is just a safe method to transfer data. Behind the scenes, however, the data being sent is encrypted and decrypted outside of the application that uses it. This makes it very easy for servers to start HTTPS. But how did it come to be?
The first technology to make HTTPS possible was SSL, or the Secure Sockets Layer protocol. This is a cryptographic protocol that encrypts data before the sender sends it, and decrypts it after the receiver receives it. It does this through the magic of public/private key encryption.
When the client and server first connect, they exchange public keys. A public key is used to encrypt data so only the matching private key can properly decrypt the data - also known as an asymmetric cipher. Although this method is secure, it is also slower than using a symmetric cipher like AES, which uses the same key for encryption and decryption. When two systems communicate with HTTPS, they use the secure public/private keys to agree on a sufficiently strong key for the faster, but still secure, symmetric cipher.
This order of exchanging keys is important. With public/private key communication, it doesn’t matter who sees the public key as long as the matching private key is kept secret. If two systems were to agree on a key for a symmetric cipher without an already secure connection, anyone could intercept the exchange and acquire that same key, and be able to decrypt and read all future messages.
While SSL was the first protocol to bring HTTPS to life, it has since been replaced by TLS or Transport Layer Security. The difference between these two protocols is largely mathematical, and the end result is essentially the same, but TLS is generally much more secure than SSL. Currently, to be up-to-date with security compliance, servers must use TLS to secure web traffic.
Look for future posts to further describe and explain other web security compliance standards.
