The Beginning of the End for "http:"?

When you receive a message from Google telling you that they will mark some of your pages as not secure, you take note. While encryption is being targeted by governments around the world, companies such as Google are pushing forward with ways to drive the industry towards https by default.

SSL/TLS works by creating a key negotiation and where we create a unique encryption key for each session. This encryption is normally either AES, ChaCha (a stream cipher promoted by Google here), 3DES or RC4 (a stream cipher here). At the end of the negotiation, only the client and the server will have the unique key, and no-one spying on the network traffic will be able to make any sense of the information passed. Overall we have three main phases:

• Client Hello. This is sent from the client to the server and defines the cipher suites that the client supports.
• Server Hello. This sends back the digital certificate from the server and the selected cipher suite from the list that the client sent.
• Client Key Exchange. This is sent from the client and contains the information required to generate the session key.

An outline of the process is given below. In this case the client sends a Client Hello to the server to say that it supports 28 suites. Each of these defines the key handshake method, the encryption to be used for the tunnel and the hashing method:

The Server Hello then shows the cipher suite that the server has picked (in this case it is TLS_RSA_WITH_3DES_CBC_SHA - which is RSA for the key negotiation, 3DES with CBC for the encryption and SHA-1 for the hashing method). With the Server Hello we also get the digital certificate of the server passed, and which has the public key of the server. In this case the session key created by the client will be passed back to the server by encrypting the key with the server's public key and then only the server will be able to decrypt it - as it has the associated private key.

The greatest weakness here is that if someone leaks the private key of the server, then someone could listen to all the encrypted traffic, and also spoof the server. All of the previous communications that were associated with the key pair could also be decrypted too.

So now Google is targeting the <input> tags on sites, and where they find these, they will mark the page as being insecure. As Chrome has nearly 50% of the browser market, it is likely that they will be able to drive the industry in a way that few other companies could.

For me, I run an IIS site, so all I had to do was write a rule which captured the HTTP request, and redirect it to HTTPS:

<rule name="HTTP/S to HTTPS Redirect" enabled="true" 
 ?stopProcessing="true">
        <match url="(.*)" />
        <conditions logicalGrouping="MatchAny">
          <add input="{SERVER_PORT_SECURE}" pattern="^0$" />
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" 
  ?redirectType="Permanent" />
</rule>

In 2017, Dell released their analysis of the SonicWall GRID Threat Network (which has over one million end points) and observed that 62% web traffic used SSL/TLS in 2016. If you are interested, too, they found that ransomware attacks grew 167 times since 2015, from 3.8 million in 2015 to 638 million in 2016. They think that this was due to a perfect storm of the usage of ransomware-as-a-service (RaaS) and increasing usage of Bitcoin.

By 2019, Google estimates that 75% of all Web traffic will be by HTTPS. If you want to find out what we found, here is a cryptography analysis of the top sites on the Web is here. This will cause a major headache for ISPs logging information on Web accesses, as traffic is tunnelled through their networks, and all that can be revealed for interesting information is the source and destination IP address (and the TCP ports used).