[TLS] Updated test server

Michael D'Errico <mike-list@pobox.com> Fri, 20 November 2009 16:39 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=v8OpX7DSTYhqx143oBS YZohrHeSSiZUERVuQz9XGlJ9E5F3j7d+yy+qfXA1INKf1gehfCnn+Wj+Cn4k0jNf 7DmYi1dQNlRUz/czHAl8pl8WCs2GwmH4O5TOcwEm39IhTWwRSXO2vACGo1UXYr1q EK5fLMTZf6XfWqNuUpGmbG+8=
Message-ID: <4B06C6A9.3080508@pobox.com>
Date: Fri, 20 Nov 2009 08:41:13 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [TLS] Updated test server
Precedence: list

I have updated my server at https://www.mikestoolbox.net to
support the upcoming draft from Martin Rex.  Here are the
particulars:

   - client adds a "magic" cipher suite to its list of
     cipher suites in the ClientHello message as a signal
     to the server that it supports secure renegotiation.
     the code point for testing is 0xBFFF.  the client
     MAY put the magic cipher suite anywhere in the list
     though it is RECOMMENDED that it be first to aid in
     the quick detection of patched clients by monitoring
     devices.

   - server looks for "magic" cipher suite in client's
     cipher suite list.  it may be anywhere in the list
     and the server MUST check the entire list

   - server proceeds as normal except that when composing
     the ServerHello message, the high bit of the server
     version is set to one.  this is only a signal to the
     client; the version is not changed.  notably the
     record layer version MUST NOT have the high bit set.

   - the server then adds the previous verify_data from the
     prior handshake (if any) to the running hash of the
     handshake messages.  this data MUST follow the
     ServerHello message.  the client verify_data is added
     first, followed by the server verify_data.  if this is
     an initial handshake, the data is empty, but if it is
     a renegotiation the data will be 72 bytes for SSLv3 or
     24 bytes for all versions of TLS (unless TLS 1.2 is
     used with a cipher suite that changes the default
     length of the verify_data).

   - the client checks for the top bit of the ServerHello
     version being set to 1 and if it is adds the verify_data
     from the previous handshake to the running handshake
     messages hash immediately after ServerHello. the client
     verify_data is added first followed by the server's
     verify_data.  the high bit of the version is reset to
     zero when used for the record layer version

Mike

[TLS] Updated test server Michael D'Errico
Re: [TLS] Updated test server Michael D'Errico