Web Transitions and Compatibility

I have spoken previously of web protocol transitions that are currently happening: and the encryption layer, the HTTP layer (OSI Layer 7), and even the TCP layer. But I wanted to dive deeper on this, and speak about the benefits of starting the transitions, and the risks of not finishing them.

The IT industry is terrible at discarding the abandoned and obsolete technologies it once heralded. The Change Management and ITIL process, the traditional project management approaches that constricted velocity of change have given rise to the culture of not changing anything – avoiding the work of actually moving forward.

Technology Enabling new version Disabling previous version
Risk Advantage Risk Advantage
HTTP/2 None Faster, less bandwidth May exclude older browser, integrations None
TLS 1.3 Middleboxes (transparent proxies) poor TLS implementation (most have patches available) Faster (less Round Trips), More Secure (less supported older ciphers, some new ciphers) May exclude older browser, system integrations Reduce security risk
Security Headers Uncover poor implementation in your products! Client helps with security
Network (web client) logging Lots of network traffic, turns requests (read operations) to events (write operations) Discover issues affecting clients you didn’t cater for

What I typically see is operations teams that leave every legacy protocols and cipher enabled, no headers inserted, no modern ciphers or protocols.

Today I’ll take you down one of these rabbit holes: TLS Protocols, CIphers, and Message Authentication (MAC).

Protocol Transitions and backwards compatibility

The TLS conversation between a web browser and the server starts with a selection of the newest protocol that both support. At this point in time (Dec 2018), there are 7 versions: SSLv1 which was never used in the wild; SSLv2, SSLv3, TLSv1 all of which are now deprecated by PCI DSS 3.2 and should not be used; TLSv1.1 which was only the “latest” version for around 18 months a decade ago – a period when only one new browser appeared – Safari – which has had many newer versions since then that support newer protocols; TLSv1.2; and the very new TLSv1.3.

The first step to a transition for web service operators is to ensure TLSv1.2, and if available, TLSv1.3 are enabled.

Don’t panic if you can’t enable TLSv1.3 right now, but keep patching and updating your OS, Web Server, Load Balancers, etc, and eventually it will become available.

Your next stop is to examine your logs and see if you can determine the Protocol and Cipher being used. Standard “combined” Log file formats don’t record this, but you can add it in. For example, Apache defines one of its log formats as:

LogFormat "%h %l %u %t \"%r\" %>s %O" common

We can adjust this with the addiitonal detail:

LogFormat "%h %l %u %t \"%r\" %>s %O %{SSL_PROTOCOL}x %{SSL_CIPHER}x" commontls

And now any of our sites can be modified from common to commontls and we can see the Protocol and Cipher used. At this point, sit back for a week, and then review what Protocols were actually seen over that period. Doing a combination of cut, sort, or some perl:

cat access.log.1 | perl -ne '/\s(\S+)\s(\S+)$/ && $h{$1}++; } { foreach $val ( keys %h) { print "$val = $h{$val}\n" }'

You’ll end up with something like:

TLSv1.3 = 468
- = 16
TLSv1.2 = 28188

So we see only modern connections here (we can ignore the 16 non-matching lines).

Of course, you may also see our older protocols mentioned, so your question should be what to do now. if these all originate from a few regular IP addresses, then you possibly have an old client, or an old script/integration process, for example, running from Python 2.x, old Perl, Java 6, etc.

If that’s the case, then you have a conundrum; those old integration processes will prevent you from securing those integrations!  In order to maintain a secure connection, the client/integration will need an update. Move to Java 8 (or 11), Python 3.6 (or 3.7), etc. If that’s an external service provider or 3rd party, then it’s out of your hands. If you’re a paying customer, then it’s time to request that your provider updates their environment accordingly. A key phrase I love to bandy about is:

We've upped our standards; up yours.

Of course, you can always just disable those older protocols (perhaps after some notice if its an important integration). Nothing gets work moving quite like a deadline. “We’re turning off TLSv1 on 1 April – no joke; TLS 1.2 is our new minimum”.

If you’re setting up a new service today, I would strongly suggest only enabling TLS 1.2 and 1.3 from the start.; and over the coming years, make a conscious plan to schedule the deprecation of TLS 1.2.

I you only have one (or two) Protocols enabled, then as part of your operational responsibility, you only have to worry about one (or two) protocols being compromised.


Some providers enable almost every cipher under the sun. I have no idea how they keep aware of the vulnerabilities in all those ciphers. I prefer to minimise this down to the smallest, strongest set I can offer. Today, that’s AES in GCM mode (either AES 128 or AES 256). AES in CBC mode is deprecated (but its the strongest that MS IE supports on many Windows versions). Microsoft announced in 2018 that CBC is no longer considered secure. So your choice is to support MS IE (on older platforms), or be secure. Do your developers a favour, and drop MS IE compatibility.

New ciphers such as CHACHA20 are only available under TLS 1.3 are fine as well. But all the older ones, such as RC4, DES and 3DES, should be gone. As above, check your logs after you have sufficient logging enabled to determine if these are actively being used.

Key Exchanges

When keys are exchanged, these should always be done using ephemeral (temporary) keys. Your Cipher Suite soup should have DHE for Diffie-Helman Ephemeral, or ECDHE for Elliptical Curve Diffie-Helman Ephemeral key exchange. Anything with plain DH is using the same keys repeatedly, and should be disabled. Again look at your now-enhanced logs and determine if you can disable older Key Exchange algorithms.

Message Authentication and Check-summing

The last part of a cipher suite often has something akin to a message digest or checksum function, such as SHA, MD5, etc. The only ones that should be available today are SHA256, SHA384, and SHA512.  The larger the number, the more unique the checksum is, but the higher the computational costs.

Over time, newer checksums will come, but most major browsers don’t support higher than SHA512 at this time.

In Conclusion

Migrating the TLS Cipher Suite and Protocol are probably two of the most security-critical pieces that needs professional tuning to avoid being accidentally configured in a way that can be compromised. The  standard approach of enabling everything, or accepting vendor defaults, is a dangerous approach.

If you’re not confident with this, then read more, or join Nephology during one of our Web Security training courses for face-to-face help.