[openssl-dev] [openssl.org #3764] [BUG REPORT] Missing message Alert on ssl23_get_server_hello negotiation failure

[Fernando Mognon via RT]

Hi,

openSSL version: 1.0.1l
openSUSE-release 13.1-1.10

This problem only show for s23_clnt.c module. The flow is correct for
s3_clnt.c module.
If the TLS client starts a client hello, with tls1.1 for example and the
server only supports tls1.0, if the TLS client receives a protocol version
from the server that it does not support it should break the TLS
negotiation by sending a protocol_version Alert to the TLS Server

Although there is debug SSLerr the message ALERT is not sent.

SSL_connect:error in SSLv2/v3 read server hello A

3074041532:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported
protocol:s23_clnt.c:740:


This behavior is described in RFC5246


Backward Compatibility
E.1 <https://tools.ietf.org/html/rfc5246#appendix-E.1>.  Compatibility
with TLS 1.0/1.1 and SSL 3.0

   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
   the specific protocol version to use.  The TLS protocol provides a
   built-in mechanism for version negotiation so as not to bother other
   protocol components with the complexities of version selection.

   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
   compatible ClientHello messages; thus, supporting all of them is
   relatively easy.  Similarly, servers can easily handle clients trying
   to use future versions of TLS as long as the ClientHello format
   remains compatible, and the client supports the highest protocol
   version available in the server.

   A TLS 1.2 client who wishes to negotiate with such older servers will
   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
   ClientHello.client_version.  If the server does not support this
   version, it will respond with a ServerHello containing an older
   version number.  If the client agrees to use this version, the
   negotiation will proceed as appropriate for the negotiated protocol.

   If the version chosen by the server is not supported by the client
   (or not acceptable), the client MUST send a "protocol_version" alert
   message and close the connection.



A Possible fix would be just call function ssl3_send_alert() like it
is done in the function ssl3_get_server_hello(), s3clnt.c, which works
fine.


I need to use the module s23_xxx.c because the application (Kamailio)
needs to be configured to support 1.0 and higher version
(TLS_USE_TLSv1_PLUS)


Att.

Fernando Mognon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: BadCase_ClientRejectsTLSv10_No_ALERT.pcap
Type: application/octet-stream
Size: 3253 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150323/1c4ca75f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GoodCase_ClientRejectsTLSv10_withAlertProtocolVersion.pcap
Type: application/octet-stream
Size: 4330 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150323/1c4ca75f/attachment-0001.obj>