I am trying to implement TLS v1.1 {3,1} but get alert 70 on hellomessage to goolge I am trying to implement TLS on top of the winsock api's from windows. I am using port 443 and have created a socket. I have sent this message

in decimal.

22 3 1 0      112 1 0 0  
108 3 1 48    227 142 116 0
1 4 9 1       25 4 17 0
17 4 25 16    9 4 1 0
1 4 9 16      25 4 17 0
17 14 25 16   0 0 68 192
10 192 20 0   136 0 135 0
57 0 56 192   15 192 5 0 
132 0 53 192  7 192 9 192
17 192 19 0   69 0 68 0
51 0 50 192   12 192 14 192
2 192 4 0     65 0 4 0
5 0 47 192    8 192 18 0
22 0 19 192   13 192 3 254
255 0 10 10


The response is 

21
3
1
0
2
2
70


This is the char* or string I am passing to winsock as the message, so that would imply this is my ciphertext simply with the null stream or block cipher which is the identity map of the plaintext fragment and with no MAC. As is the record state on the initial client hello message, the first step in the handshake. Perhaps I am getting the length wrong,

If the CipherSuite is TLS_NULL_WITH_NULL_NULL,
   encryption consists of the identity operation (i.e., the data is not
   encrypted, and the MAC size is zero, implying that no MAC is used).
   TLSCiphertext.length is TLSCompressed.length plus
   CipherSpec.hash_size.

I can not find the definition of CipherSpec.hash_size in the request for comments on TLS 1.1? 

Also I have tried different versions to no prev ale. Perhaps someone can look through my encoding  below and see if there is a problem? Other then an encoding issue I can only suspect that google.com does not take TLS on port 443 but instead an http upgrade to TLS on port 80? https://tools.ietf.org/html/rfc2817
I was able to realize that the above message is malformed(with help of wireshark). You will notice there are 33 random bytes instead of the 32 as prescribed by record layer protocol. It was an error on my part with the char * holding them. Zero was first char so should go up to 31, mine went to 32. Doh.

Now most servers respond with server hello and certificates.