Re: [TLS] Unfortunate current practices for HTTP over TLS

[Martin Rex <[e-mail]>]

Nice collection -- thank you for the effort!.

Do we need a new document category "WCP" (worst current practice)?  :)

Adam Langley wrote:
> 
> 2.  Handshake message fragmentation
> 
>    Many servers will fail to process a handshake message that spans more
>    than one record.  These servers will close the connection when they
>    encounter such a handshake message.  HTTPS clients will commonly
>    ensure against that by either packing all handshake messages in a
>    flow into a single record, or by creating a single record for each
>    handshake message.

>From the SSLv3 draft302 document ("Work in progress" according to rfc5746):

   5.2 Record layer

   The SSL Record Layer receives uninterpreted data from higher layers
   in non-empty blocks of arbitrary size.

   5.2.1 Fragmentation

   The record layer fragments information blocks into SSLPlaintext
   records of 2^14 bytes or less.  Client message boundaries are not
   preserved in the record layer (i.e., multiple client messages of
   the same ContentType may be coalesced into a single SSLPlaintext
   record).

For experimentation I put together a few lines of code for a
simple TCP communication relaying that shreds TLS records containing
handshake messages into pathological fragments (1byte,2byte,3byte,...)
And I'm actually having difficulties find TLS implementations
that can cope with this.

Some (record layer) TLS code I've looked at makes a number of flawed
assumptions about fragmentation, and fixing that code to align with
the _real_ specifiction requires a non-trivial change of the code
modularization of the record layer...


>
> 3.  Protocol Fallback
>
>    Intolerance to the following has been observed:
>
>       Advertising a version greater than 0x03ff (around 65% of servers)

Keep in mind that this is about the first few bytes sent on a
new network connection.  The purpose of the check is a heuristic
to distinguish a real TLS connection attempt (initial ClientHello)
from arbitrary other protocols instead of letting the protocol
parser engine produce a potentially confusing error message about
data that obviously isn't meant to be TLS in the first place.

Servers that tolerate >=4 versions ahead of what is currently
defined SSLv3{0x03,0x00} -> TLSv1.2{0x03,0x03} provide sufficient
slack that they are no problem for the evolution of the TLS protocol.

TLS implementations that are completely agnostic to the version
will AFAIK confuse DTLS and TLS.

>
>    In all these cases, HTTPS clients will often enter a fallback mode.
>    The connection is retried using only SSLv3 and without advertising
>    any compression algorithms.  (This is obviously an easy downgrade
>    attack.)

Fallback mode is mostrly restricted to a few Web Browser that are
curiously exploring bleeding-edge TLS extensions.  Most programmatic
clients don't have a fallback mode, because the fallback has to
be performed at the application level over a new network connection,
potentially including proxy traversals.  Programmatic clients are
more likely to send very feature-conservative ClientHellos from
the beginning (no TLS extensions and either TLSv1.0 or SSLv3).


>
>    Also, the fallback can be triggered by transient network
>    problems, which often manifest as an abruptly closed connection.
>    Since SSLv3 does not provide any means of Server Name Indication
>    [RFC3546], the fallback connection can use the wrong certificate
>    chain, resulting in a very surprising certificate error.

Since a significant fraction of the installed base browsers and
most of the programmatic clients do not send a server name indication
in the first place, the effect is more of a common annoying
certificate error pointing to an inconsiderate/misconfigured server.

The majority where I've encountered such errors, it was with
servers and hostnames belonging to the same organization, so
the problem could be entirely avoided by a sensible admin through
the simple use of adequate TLS server certs, listing all of the servers
alternative hostnames.




-Martin