Alert Protocol in TSL

One of the content types supported by the TLS record layer is the
alert type.Alert messages convey the severity of the message
(warning or fatal) and a description of the alert.Alert messages
with a level of fatal result in the immediate termination of the
connection.In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new
connections.Like other messages, alert messages are encrypted and
compressed, as specified by the current connection state.

enum { warning(1), fatal(2), (255) } AlertLevel;

enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(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),
unsupported_extension(110),
(255)
} AlertDescription;

struct {
AlertLevel level;
AlertDescription description;
} Alert;

Fragmentation in TSL

The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks 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 TLSPlaintext record, or a single message MAY be
fragmented across several records).

struct {
uint8 major;
uint8 minor;
} ProtocolVersion;

enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;

struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

type
The higher-level protocol used to process the enclosed fragment.

version
The version of the protocol being employed.This document
describes TLS Version 1.2, which uses the version { 3, 3 }.The
version value 3.3 is historical, deriving from the use of {3, 1}
for TLS 1.0.(See Appendix A.1.)Note that a client that
supports multiple versions of TLS may not know what version will
be employed before it receives the ServerHello.See Appendix E
for discussion about what record layer version number should be
employed for ClientHello.

length
The length (in bytes) of the following TLSPlaintext.fragment.The
length MUST NOT exceed 2^14.

fragment
The application data.This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol
specified by the type field.

Implementations MUST NOT send zero-length fragments of Handshake,
Alert, or ChangeCipherSpec content types.Zero-length fragments of
Application data MAY be sent as they are potentially useful as a
traffic analysis countermeasure.

Note: Data of different TLS record layer content types MAY be
interleaved.Application data is generally of lower precedence for
transmission than other content types.However, records MUST be
delivered to the network in the same order as they are protected by
the record layer.Recipients MUST receive and process interleaved
application layer traffic during handshakes subsequent to the first
one on a connection.

Goals of TLS, RFC 5246

The goals of the TLS protocol, in order of priority, are as follows:

1. Cryptographic security: TLS should be used to establish a secure
connection between two parties.

2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange
cryptographic parameters without knowledge of one another's code.

3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
necessary.This will also accomplish two sub-goals: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.

4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations.For this
reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to be
established from scratch.Additionally, care has been taken to
reduce network activity.

in .NET, some strings will have the same hash code

 Console.WriteLine("0.89265452879139".GetHashCode());
Console.WriteLine("0.280527401380486".GetHashCode());

Do you know what will happen in .NET ? Have a try:

2060653827

2060653827

these 2 string share the same hash code!