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://www.rfc-editor.org/rfc/rfc2817
70
isprotocol_version
which readsThe protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons). This message is always fatal.
Note that Google takes TLS v1.1 on port 443 as can be seen in this report $\endgroup$