[TLS] The Hardware Angle

[Michael D'Errico <mike-list at pobox.com>]

Dr Stephen Henson wrote:
> Well in terms of implementation and overhead I'd prefer that the client knows as
> soon as possible which method to use.

This is especially true for hardware.

I don't think anyone would argue that firewall/monitoring devices
will want to detect the patched status of clients and servers.
The non-extension approach to solving this problem is infinitely
better to a hardware engineer.  (I design digital hardware circuits
for fun[*] -- yes I know I'm a geek.)

The hardware for detecting a patched client is just a few lines of
Verilog code:

   wire  [7:0] session_id_len  = client_hello[34];
   wire  [7:0] first_cipher_hi = client_hello[37+session_id_len];
   wire  [7:0] first_cipher_lo = client_hello[38+session_id_len];
   wire [15:0] first_cipher    = {first_cipher_hi, first_cipher_lo};

   wire patched_client = (first_cipher == MAGIC_CIPHER_SUITE);

(I hope I got that right.)

The hardware for detecting a patched server is similarly easy:

   wire  [7:0] major_version  = server_hello[0];
   wire  [7:0] minor_version  = server_hello[1];
   wire [15:0] server_version = {major_version, minor_version};

   wire patched_server = (server_version >= 16'h0380);

This is all purely combinational logic, i.e. it is nearly instantaneous.

If our solution involves extensions or altered Certificate messages,
then the hardware becomes many orders of magnitude more difficult.  You
require "sequential logic" which means that state machines are needed
to parse through the Hello messages.  Many clock cycles will be wasted,
meaning that we will have significantly slowed down all secure Internet
traffic.

Mike


[*] see http://www.digilentinc.com (contact me off-list if interested
in this -- it has made me a much better software developer as well)