Analysis of errors and potential errors that TLS can produce. This is based on a
reading of rfc4346.

(Section)  Error

(4.3) The TLS record syntax could cause errors, e.g. foo <3...4> and only two foos are
present - not clear what different implementations might do, nor where exactly these
errors might crop up.

(4.5) Emumerated types. Out-of-range errors might occur.

(4.6.1) Select (aka case) statement value might not be valid.

(4.7) Cryptographic parameters include lengths, padding, structure etc and could
(but shouldn't) generate errors.

(6) Illegal record type - only 4 are defined. Bad values SHOULD be igored.

(6.1) Connection states involve a number of emumerated types that could be
extended over time or corrupted. There is no clear error handling specfied
in this section for bad values.

(6.2.1) The TLSPlainText structure could contain an invalid type, or version
or a bad length. (What if length==0?) The length "should not" exceed 2^14, but
no error handling is specified if it does. The text says that different
content types can be found in the same TLSPlainText (presumably e.g. if some
appn data is followed by a change cipher spec), but I'd bet that not all
implementations will get that right.

(6.2.2) Compression methods other than NULL might cause errors (since
probably few implementations support compression afaik).

(6.2.3) Various crypto checks could generate errors (MAC check) including
some new fields in TLS 1.1 vs. TLS 1.0 (IV & CBC residue) that could
cause errors.

(7) The handshake protocol is allowed to supply a NULL certificate. That
might cause a higher layer error in some applications if they always
expect some certificate.

(7) There's no clear length guidance for the session identifier nor
a requirement for it to be random, so I guess some bad code make that
so small that collisions were regular resulting in oddities when
resuming a session.

(7.1) An implementation might react badly to a significant number
of ChaneCipherSpec messages.

(7.2) The AlertDescription includes a mixture of various different
types of error, from crypto to bad certs to authorization problems.
Probably abstracting those into categories would be good.
                 close_notify(0),
                 unexpected_message(10),
                 bad_record_mac(20),
                 decryption_failed(21),
                 record_overflow(22),
                 decompression_failure(30),
                 handshake_failure(40),
                 no_certificate_RESERVED (41),
                 bad_certificate(42),
                 unsupported_certificate(43),
                 certificate_revoked(44),
                 certificate_expired(45),
                 certificate_unknown(46),
                 illegal_parameter(47),
                 unknown_ca(48),
                 access_denied(49),
                 decode_error(50),
                 decrypt_error(51),
                 export_restriction_RESERVED(60),
                 protocol_version(70),
                 insufficient_security(71),
                 internal_error(80),
                 user_canceled(90),
                 no_renegotiation(100),
                 (255)

(7.4.1.2) The ClientHello contains a time_t value that could
be treated as bad by a higher layer (unlikely).

(7.4.2) certificate list can contain a chain of certs that
might not chain properly, possibly for abtruse reasons, e.g.
due to some policy setting. Probably most implementations
wouldn't have that problem, but they might.

(7.4.3) DH_anon ciphersuites could cause higher layer errors
if negotiated.

(7.4.3) An implementation could reject an RSA key due to a
modulus with leading zeros or a large exponent.

(7.4.4) ClientCertificateType values from 224...255 are for
private use, which could find bugs in implementations, if
used.

(7.4.4) DistinguishedName's are sent encoded, so decoding
could result in some unsupported RDN causing weird errors (say
if an OID contained a very high valued arc).

(7,4,6) Not an error, but can cause user interaction - if
the server requests a certificate, then user's get confused
(when they have >1 matching cert)

(7.4.7.1) The version in the premastersecret and the
ClientHello version MUST be the same (to prevent rollback
attacks).

(7.4.7.2) A static DH public value need not be resent in
the PublicValueEncoding, but a server might not properly
implement that (even though its a MUST, its probably
rare enough to be problematic)).

(9) The mandatory ciphersuite is TLS_RSA_WITH_3DES_EDE_CBC_SHA,
but only "in the absence of an application profile" so one
could presumably come across an implementation that didn't
support that because of such a profile (I don't know of
any though)

(A.5) Says that TLS_NULL_WITH_NULL_NULL "must not" (lowercase?)
be negotiated, but I guess a bug could cause that to happen.
Similarly EXPORT ciphersuites MUST NOT be negotiated, but
an implementation might not conform there.

(A.5) Ciphersuites starting with 0xff are for private
use and so weird stuff could happen.