2
$\begingroup$

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

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ RFC 4346: Section 7.2.2: 70 is protocol_version which reads The 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$
    – SEJPM
    Feb 17, 2016 at 21:26
  • $\begingroup$ You can see in the encoding I have offered 3 1 which corresponds to TLS v 1.1. Also the port is 443. I am very confused? I think my encoding is correct and am having a look at this project in python to try and verify my encoding algorithm. github.com/bjornedstrom/toytls/blob/master/toytls/tls.py but python with it's syntax I am not experienced with. Thanks for response. $\endgroup$
    – marshal craft
    Feb 18, 2016 at 0:07
  • $\begingroup$ Oh wait TLS v 1.1 -> 3 -2. But the alert version is 3 -1 (TLS v 1.0). When I try 3 -2 I get same exact response. An 2 70 in version 3-1. Also other sites do not even respond or close the TCP connection, sometimes unexpectedly. Not sure if it is because they may be virtual host with others all on same ip address. $\endgroup$
    – marshal craft
    Feb 18, 2016 at 0:22
  • $\begingroup$ Also when I connect in my normal web browser and view the https connection it says it is using TLS v 1.2 {3,3} $\endgroup$
    – marshal craft
    Feb 18, 2016 at 0:23

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.