DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c

[Chethan Kumar]

Thanks for the information.

I understood the flow.
Does t1_srvr.c is used to call respective TLS*_server_method in s3_srvr.c when tls1_get_server_method() is set while creating SSL_CTX()?
Is similar logic followed for openssl as client also? Like s2_clnt.c is called when SSLv2 is used.
S23_clnt.c is called for SSLv3 and above. Or is it different.?

Also, please let me know if there is any document/link which describes the codeflow when clienthello  is received.

Thanks in advance,
Chethan Kumar



-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Tuesday, April 23, 2019 7:30 PM
To: openssl-users at openssl.org
Subject: Re: DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c



On 23/04/2019 14:40, Chethan Kumar wrote:
> Dear all,
> 
>  
> 
> Can someone please explain the need for different files like 
> s2_srvr.c, s3_srvr.c and s23_srvr.c in ssl folder.
> 
> I need to know the difference because ssl23_client_hello() is getting 
> called for all communication happening using sslv3, tls1.0/1.1/1.2
> 
> Then what is the use of ssl3_client_hello() in s3_srvr.c and 
> client_hello() in s2_srvr.c
> 
> Does ssl23_client_hello() is getting called internally for all versions?
> 
> If so, can some please point where does this internal call happens.

s2_srvr.c processes SSLv2 only.
s3_srvr.c processes SSLv3 and above for a fixed protocol version (it does not do version negotiation).

s23_srvr.c does version negotiation. It pulls apart the ClientHello that has been received and works out what protocol version should be used. It then sets the protocol version in the SSL object, pushes the ClientHello back into a read buffer and restarts the process. If SSLv2 was selected then the client hello processing in s2_srvr.c is used. If SSLv3 or above was selected then the client hello processing in s3_srvr.c is used.

You can see the code to set the protocol version in the SSL object, and then push the ClientHello back into the read buffer here:

https://github.com/openssl/openssl/blob/f937540ec40a5e838460b8f19d2eb722529126b8/ssl/s23_srvr.c#L598-L639

At the end of this function we call SSL_accept again to restart the process:

https://github.com/openssl/openssl/blob/f937540ec40a5e838460b8f19d2eb722529126b8/ssl/s23_srvr.c#L650

If you use SSLv2_server_method(), SSLv3_server_method(), TLSv1_server_method(),
TLSv1_1_server_method() or TLSv1_2_server_method() when you create your
SSL_CTX() then this "fixes" the protocol version at the specified level. In this case s23_srvr.c is never used and you just go straight to s3_srvr.c (or s2_srvr.c).

If you use SSLv23_server_method() then version negotiation is used an you go to s23_srvr.c initially.

In OpenSSL 1.1.0+ version negotiation was completely rewritten so this works very differently there. The fixed protocol server methods are deprecated and you are encouraged to use TLS_server_method() instead (which is the new name for SSLv23_server_method).

Hope that helps

Matt

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.