Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

SSL_connect returns 0, with no error

1,330 views

Skip to first unread message

Andrew Dennison

unread,

May 5, 2006, 9:53:06 AM5/5/06

------=_Part_1685_5681888.1146837160840
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I am currently experiencing an issue using SSL_connect() on a non-blocking
socket.

I have set SSL_MODE_AUTO_RETRY so that it would not return right away, and
as a backup measure have included handling for SSL_WANT_READ/SSL_WANT_WRITE
such that the entire connection process is handled in it's own thread that
will only exit once a connection has been made (or the main thread timeout
for that thread expires, but that is set for 5 minutes).

The issue arises on the second connection attempt after having already
established a successful connection. What I am attempting to do is to
shutdown the SSL layer and perform a full handshake to re-establish a new
SSL connection without affecting the underlying TCP socket (whose connectio=
n
I hope to maintain throughout this process).

The sequence of commands is more or less this:

SSL_connect()
- SSL_WANT_READ/SSL_WANT_WRITE
- SSL_state_string_long(): SSLv3 read server hello A
- SSL_WANT_READ/SSL_WANT_WRITE
- SSL_state_string_long(): SSLv3 read finished A

[connection established, all is well]

[time passes, data is sent/received]

Read and write threads are suspended pending session re-establishment

SSL_shutdown() =96 close-notify sent (OK)
SSL_shutdown() =96 host close-notify received (OK)

- connection shutdown

SSL_clear() =96 prepare for next connection (* - see notes below)

- SSL_free is NOT issued in order to preserve session
information

SSL_connect() issued =96 problem occurrence!
SSL_connect() returned (0); failed with error: SSL_ERROR_SYSCALL

errno : No error

WSAGetLastError: 0

ERR_error_string - 0 - error:00000000:lib(0):func(0):reason(0)

SSL_state_string_long(): SSLv3 read server hello A

An additional call to SSL_want() at this time returns: SSL_READING

At this point, I have tried both to issue SSL_connect again, or to issue th=
e
requested SSL_read()** first (which succeeds), and then to issue SSL_connec=
t
again. Both result in the following:

SSL_connect() returned (-1); failed with error: SSL_ERROR_SYSCALL

errno : No error

WSAGetLastError: 10053 - WSAECONNABORTED

ERR_error_string - 0 - error:00000000:lib(0):func(0):reason(0)

SSL_state_string_long(): SSLv3 read server hello A

And that's it. I have no recourse but to remake the whole connection (TCP
layer included).

Notes:
* Even If this SSL_clear is not issued, the same thing happens.
** If two SSL_read()s are issued in succession, the connection will return
WSAECONNABORTED as well.

My questions are these:

1) Is what I am attempting even possible? Is it possible to re-establish
the SSL layer without affecting the underlying connection?

2) If it is possible to do this, where am I going wrong, how might I correc=
t
it, or should it be done in some different way?

3) I am aware of and have also used SSL_renegotiate in a different
situation. The intent here is for a full handshake to occur for security
purposes. Renegotiation (via SSL_renegotiate) is used in this application
in another circumstance, but it is unclear whether this fully re-establishe=
s
the communications security for this link. Is it any less secure than the
negotiations that occur during connection?

4) Regardless of the legitimacy of this method for re-establishment of the
SSL connection, why does SSL_connect() return 0 with no useful error
information as to what should be done to correct the problem. It doesn't
even report SSL_WANT_READ in it's return, though SSL_want() is quite ready
to return with SSL_READING, a condition where (according to the docs) a cal=
l
to SSL_get_error() should result in SSL_WANT_READ, not SSL_ERROR_SYSCALL.
This would seem to be somewhat contradictory.

If someone could shed some light on some or all of these questions, I would
appreciate it.

Andrew Dennison

------=_Part_1685_5681888.1146837160840
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

------=_Part_1685_5681888.1146837160840--
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

Gayathri Sundar

unread,

May 6, 2006, 2:49:07 AM5/6/06

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C67107.DD560630
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: owner-ope...@openssl.org
[mailto:owner-ope...@openssl.org]On Behalf Of Andrew Dennison
Sent: Friday, May 05, 2006 7:23 PM
To: openss...@openssl.org
Subject: SSL_connect returns 0, with no error

I am currently experiencing an issue using SSL_connect() on a non-block=
ing
socket.

I have set SSL_MODE_AUTO_RETRY so that it would not return right away, =
and
as a backup measure have included handling for SSL_WANT_READ/SSL_WANT_WRI=
TE
such that the entire connection process is handled in it's own thread tha=
t
will only exit once a connection has been made (or the main thread timeou=

t
for that thread expires, but that is set for 5 minutes).

SSL connection without affecting the underlying TCP socket (whose connect=
ion

I hope to maintain throughout this process).

The sequence of commands is more or less this:

SSL_connect()

- SSL_WANT_READ/SSL_WANT_WRITE
- SSL_state_string_long(): SSLv3 read server hello A
- SSL_WANT_READ/SSL_WANT_WRITE
- SSL_state_string_long(): SSLv3 read finished A

[connection established, all is well]

[time passes, data is sent/received]

Read and write threads are suspended pending session re-establishment

SSL_shutdown() =96 close-notify sent (OK)
SSL_shutdown() =96 host close-notify received (OK)
- connection shutdown

SSL_clear() =96 prepare for next connection (* - see notes below)

- SSL_free is NOT issued in order to preserve session
information

SSL_connect() issued =96 problem occurrence!
SSL_connect() returned (0); failed with error: SSL_ERROR_SYSCALL

errno : No error
WSAGetLastError: 0

ERR_error_string - 0 - error:00000000:lib(0):func(0):reason(0=
)

SSL_state_string_long(): SSLv3 read server hello A

An additional call to SSL_want() at this time returns: SSL_READING

At this point, I have tried both to issue SSL_connect again, or to issu=
e
the requested SSL_read()** first (which succeeds), and then to issue

SSL_connect again. Both result in the following:

SSL_connect() returned (-1); failed with error: SSL_ERROR_SYSCALL

errno : No error

WSAGetLastError: 10053 - WSAECONNABORTED

ERR_error_string - 0 - error:00000000:lib(0):func(0):reason=
(0)

SSL_state_string_long(): SSLv3 read server hello A

And that's it. I have no recourse but to remake the whole connection (=
TCP
layer included).

Notes:

* Even If this SSL_clear is not issued, the same thing happens.

** If two SSL_read()s are issued in succession, the connection will ret=
urn
WSAECONNABORTED as well.

My questions are these:

1) Is what I am attempting even possible? Is it possible to re-establi=

sh
the SSL layer without affecting the underlying connection?

AFAIK, once closure alerts are sent, the TCP connection cannot be reuse=
d
by another SSL connection. Am not sure if SSL as such supports this scene=
rio
of reusing a TCP connection across multiple Client Hello Pkts. Renegotiat=
ion
can happen, but the TCP fd cannot be re-used..for a new handshake.
SSL_ERR_SYSCALL seems to happen coz the fd is invalidated and you cant
send/recv on that anymore. .

2) If it is possible to do this, where am I going wrong, how might I

correct it, or should it be done in some different way?

I could be wrong, but this is not possible.

3) I am aware of and have also used SSL_renegotiate in a different
situation. The intent here is for a full handshake to occur for security

purposes. Renegotiation (via SSL_renegotiate) is used in this applicatio=
n
in another circumstance, but it is unclear whether this fully re-establis=
hes
the communications security for this link. Is it any less secure than th=

e
negotiations that occur during connection?

I think your asking abt the "hello request", which triggers a new
handshake on the same fd over which you had already a SSL connection
established. Now the thing is the SESSION is reused as such for subsequen=
t
connections between peers, so that the handshake time is reduced, doing a
complete negotiation of security params on a per connection basis, is onl=
y a
performance overhead, but ofcourse more secure (debatable), but otherwise
only the change cipher spec messages are exchanged and the master secret =
is
reused. Not sure if you really want to negotiatie a new master secret for
every TCP connect..but all depends on your requirement.

You can disable SSL SESSION reuse, which will trigger ssl handshakes fr=
om
scratch on a per connection basis, but once again u need to do a TCP acce=
pt
before doing an SSL Accept, the fd cannot be reused, you can treat it inl=
ine
with IKE phase-1 and IKE phase-2 rekey..

4) Regardless of the legitimacy of this method for re-establishment of =

the
SSL connection, why does SSL_connect() return 0 with no useful error
information as to what should be done to correct the problem. It doesn't

even report SSL_WANT_READ in it's return, though SSL_want() is quite read=
y
to return with SSL_READING, a condition where (according to the docs) a c=
all

to SSL_get_error() should result in SSL_WANT_READ, not SSL_ERROR_SYSCALL.
This would seem to be somewhat contradictory.

If someone could shed some light on some or all of these questions, I
would appreciate it.

Andrew Dennison

------=_NextPart_000_0014_01C67107.DD560630
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2900.2873" name=3DGENERATOR></HEAD>
<BODY>
<DIV>-----Original =
Message----- From:=20
owner-ope...@openssl.org =
[mailto:owner-ope...@openssl.org]On=20
Behalf Of Andrew Dennison Sent: Friday, May 05, 2006 7:23=20
PM To: openss...@openssl.org Subject: =
SSL_connect=20
returns 0, with no error </DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV style=3D"DIRECTION: ltr">
I=20
am currently experiencing an issue using SSL_connect() on a =
non-blocking=20
socket.
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
I=20
have set SSL_MODE_AUTO_RETRY so that it would not return right away, =
and as a=20
backup measure have included handling for SSL_WANT_READ/SSL_WANT_WRITE =
such=20
that the entire connection process is handled in it's own thread that =
will=20
only exit once a connection has been made (or the main thread timeout =
for that=20
thread expires, but that is set for 5 minutes). 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The issue arises on the =
second=20
connection attempt after having already established a successful=20
connection.  What I am attempting to do is to shutdown the SSL =
layer and=20
perform a full handshake to re-establish a new SSL connection without=20
affecting the underlying TCP socket (whose connection I hope to =
maintain=20
throughout this process). 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The sequence of commands =
is more=20
or less this:
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">SSL_connect()
<DIV style=3D"MARGIN-LEFT: 54pt; TEXT-INDENT: -18pt">-<FONT=20
face=3D"Times New Roman" size=3D1>=20
         =20
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">SSL_WANT_READ/SSL_WANT_WRITE</DIV>
<DIV style=3D"MARGIN-LEFT: 54pt; TEXT-INDENT: =
-18pt"><FONT=20
face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">-<FONT=20
face=3D"Times New Roman"=20
size=3D1>         =20
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_state_string_long(): =
SSLv3=20
read server hello A </DIV>
<DIV style=3D"MARGIN-LEFT: 54pt; TEXT-INDENT: -18pt"><FONT=20
face=3DArial size=3D2>-<FONT=20
face=3D"Times New Roman"=20
size=3D1>         =20
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">SSL_WANT_READ/SSL_WANT_WRITE=20
</DIV>
<DIV style=3D"MARGIN-LEFT: 54pt; TEXT-INDENT: -18pt"><FONT=20
face=3DArial size=3D2>-<FONT=20
face=3D"Times New Roman"=20
size=3D1>         =20
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_state_string_long(): =
SSLv3=20
read finished A </DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">[connection established, =
all is=20
well]
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">[time passes, data is=20
sent/received]
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Read and write threads =
are=20
suspended pending session re-establishment
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_shutdown() =96 =
close-notify sent=20
(OK)</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_shutdown() =96 host=20
close-notify received (OK) </DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">-<FONT=20
face=3D"Times New Roman" size=3D1>=20
         =20
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">connection=20
shutdown</DIV></BLOCKQUOTE>
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_clear() =96 prepare =
for next=20
connection (* - see notes below)
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">           =
=20
- SSL_free is NOT issued in order to preserve session=20
information
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_connect() issued =96 =
problem=20
occurrence!</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_connect()=20
returned (0); failed with error: SSL_ERROR_SYSCALL =
</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"> </DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">          errno =

: No error</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">WSAGetLastError:=20
0 </DIV></BLOCKQUOTE>
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">         =20
ERR_error_string - 0 -=20
error:00000000:lib(0):func(0):reason(0)
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">SSL_state_string_long(): SSLv3=20
read server hello A</BLOCKQUOTE>
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"> </DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">An additional call to =
SSL_want()=20
at this time returns: SSL_READING</DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">At this point, I have =
tried both=20
to issue SSL_connect again, or to issue the requested SSL_read()** =
first=20
(which succeeds), and then to issue SSL_connect again. Both result in =
the=20
following: 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"> <FONT=20
face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_connect() returned =
(-1);=20
failed with error: SSL_ERROR_SYSCALL 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">           =
=20
errno : No error
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">           =
=20
WSAGetLastError: 10053 - WSAECONNABORTED
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">           =
=20
ERR_error_string - 0 -=20
error:00000000:lib(0):func(0):reason(0)
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SSL_state_string_long(): =
SSLv3=20
read server hello A 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">And that's it.  I =
have no=20
recourse but to remake the whole connection (TCP layer=20
included).
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Notes:
<DIV style=3D"MARGIN-LEFT: 18pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">* Even If this SSL_clear =
is not=20
issued, the same thing happens.</DIV>
<DIV style=3D"MARGIN-LEFT: 18pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">** If two =
SSL_read()s=20
are issued in succession, the connection will return WSAECONNABORTED =
as=20
well.  </DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">My questions are=20
these:
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
1) Is=20
what I am attempting even possible?  Is it possible to =
re-establish the=20
SSL layer without affecting the underlying connection? <SPAN=20
class=3D484394106-06052006> 
<SPAN=20
class=3D484394106-06052006>AFAIK, once closure =
alerts are=20
sent, the TCP connection cannot be reused by another SSL connection. =
Am not=20
sure if SSL as such supports this scenerio of reusing a=20
TCP connection across multiple Client Hello Pkts.=20
Renegotiation can happen, but the TCP fd cannot be =
re-used..for a=20
new handshake. SSL_ERR_SYSCALL seems to happen coz the fd is =
invalidated=20
and you cant send/recv on that anymore. <FONT=20
color=3D#000080>.
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
2) If it=20
is possible to do this, where am I going wrong, how might I correct =
it, or=20
should it be done in some different way?   <SPAN=20
class=3D484394106-06052006> 
<SPAN=20
class=3D484394106-06052006><FONT=20
face=3DArial>I could be wrong, but this is not=20
possible. 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">3) I am =
aware of and=20
have also used SSL_renegotiate in a different situation.  The =
intent here=20
is for a full handshake to occur for security purposes.  =
Renegotiation=20
(via SSL_renegotiate) is used in this application in another =
circumstance, but=20
it is unclear whether this fully re-establishes the communications =
security=20
for this link.  Is it any less secure than the negotiations that =
occur=20
during connection? 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I=20
think your asking abt the "hello request", which triggers a new =
handshake on=20
the same fd over which you had already a SSL connection established. =
Now the=20
thing is the SESSION is reused as such for subsequent connections =
between=20
peers, so that the handshake time is reduced, doing a complete =
negotiation of=20
security params on a per connection basis, is only a performance =
overhead, but=20
ofcourse more secure (debatable), but otherwise only the change cipher =
spec=20
messages are exchanged and the master secret is reused. Not sure if =
you really=20
want to negotiatie a new master secret for every TCP connect..but all =
depends=20
on your requirement.
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">You=20
can disable SSL SESSION reuse, which will trigger ssl handshakes from =
scratch=20
on a per connection basis, but once again u need to do a TCP accept =
before=20
doing an SSL Accept, the fd cannot be reused, you can treat it inline =
with IKE=20
phase-1 and IKE phase-2 rekey..
<SPAN=20
class=3D484394106-06052006>  
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">4) Regardless of the =
legitimacy of=20
this method for re-establishment of the SSL connection, why does =
SSL_connect()=20
return 0 with no useful error information as to what should be done to =
correct=20
the problem.  It doesn't even report SSL_WANT_READ in it's =
return, though=20
SSL_want() is quite ready to return with SSL_READING, a condition =
where=20
(according to the docs) a call to SSL_get_error() should result in=20
SSL_WANT_READ, not SSL_ERROR_SYSCALL.  This would seem to be =
somewhat=20
contradictory. 
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">If someone could shed =
some light=20
on some or all of these questions, I would appreciate=20
it.</DIV>
<DIV style=3D"DIRECTION: ltr">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Andrew=20
Dennison</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0014_01C67107.DD560630--

Kyle Hamilton

unread,

May 6, 2006, 3:40:05 AM5/6/06

On 5/5/06, Andrew Dennison <aden...@gmail.com> wrote:
>
> The issue arises on the second connection attempt after having already
> established a successful connection. What I am attempting to do is to
> shutdown the SSL layer and perform a full handshake to re-establish a new
> SSL connection without affecting the underlying TCP socket (whose connect=
ion
> I hope to maintain throughout this process).

If you're trying to use the same SSL_SESSION, you're going to go into
an abbreviated reconnection unless you disable SSL session reuse.

If you've sent a closure alerts, after sending them the protocol
specifies that no more data can be sent in that direction. After
you've received a closure alert, SSL specifies that you close the
socket in that direction.

To force a renegotiation, SSL_renegotiate is appropriate -- it will
(from the server end) send out a server_hello packet, which causes the
client to send a client_hello packet, and the protocol starts anew --
even to the point of revalidating the certificates. This is all done
within the current encrypted streams.

> SSL_clear() =96 prepare for next connection (* - see notes below)
>
> - SSL_free is NOT issued in order to preserve session
> information

If you preserve session information, you're going to get an
abbreviated negotiation, not a full one.

> SSL_connect() issued =96 problem occurrence!
> SSL_connect() returned (0); failed with error: SSL_ERROR_SYSCALL
>
> errno : No error
>
> WSAGetLastError: 0
>
> ERR_error_string - 0 -

> error:00000000:lib(0):func(0):reason(0)

>
>
> SSL_state_string_long(): SSLv3 read server hello A
>
>
>
> An additional call to SSL_want() at this time returns: SSL_READING
>

> At this point, I have tried both to issue SSL_connect again, or to issue =
the
> requested SSL_read()** first (which succeeds), and then to issue SSL_conn=
ect

> again. Both result in the following:

The server must perform an SSL_accept() at this point, as the socket
descriptor it has is invalid. From this trace, it appears that the
server has performed a listen(), but it's on queue.

> And that's it. I have no recourse but to remake the whole connection (TC=
P
> layer included).

Don't call SSL_shutdown(). It's that simple. SSL_shutdown causes the
TCP layer to shutdown().

> My questions are these:
>
>
>
> 1) Is what I am attempting even possible? Is it possible to re-establish

> the SSL layer without affecting the underlying connection?

It's possible to re-establish the SSL layer without affecting the
underlying connection. If you want to get rid of the current key
completely (though there's no practical reason for doing so, as it's
not used as a source of entropy) you can set SSL_cipher_list to +NULL,
SSL_renegotiate(), then to "STRONG", and SSL_renegotiate. Note that
the client must also have the NULL cipher suites enabled for this to
work -- otherwise, just call SSL_renegotiate and it'll work within the
current framework.

> 2) If it is possible to do this, where am I going wrong, how might I corr=
ect

> it, or should it be done in some different way?

You're calling SSL_shutdown. Don't. Call SSL_renegotiate with the
ciphers list, server cert, server key, and acceptable client cert CA
names in the SSL_CTX already reset to what you want to renegotiate
with.

> 3) I am aware of and have also used SSL_renegotiate in a different
> situation. The intent here is for a full handshake to occur for security
> purposes. Renegotiation (via SSL_renegotiate) is used in this applicatio=
n
> in another circumstance, but it is unclear whether this fully re-establis=
hes
> the communications security for this link. Is it any less secure than th=
e
> negotiations that occur during connection?

Then why are you trying to preserve the SSL_SESSION? A session
maintains key state and data, and allows for an abbreviated (i.e., not
full) handshake when a new SSL connection is created.

> 4) Regardless of the legitimacy of this method for re-establishment of th=

e
> SSL connection, why does SSL_connect() return 0 with no useful error
> information as to what should be done to correct the problem. It doesn't
> even report SSL_WANT_READ in it's return, though SSL_want() is quite read=
y
> to return with SSL_READING, a condition where (according to the docs) a c=
all
> to SSL_get_error() should result in SSL_WANT_READ, not SSL_ERROR_SYSCALL.
> This would seem to be somewhat contradictory.

Because the underlying TCP layer hasn't gotten an RST or FIN yet.=20
Once the FIN is received, the underlying TCP layer will return an
error on read, which leads to the SSL_ERROR_SYSCALL.

-Kyle H

handshak3

unread,

Dec 1, 2011, 1:13:30 PM12/1/11

Hi,

Found this really old thread which is what i am trying to do as well.

But there is a slight difference

In my case the session is not established as the CA cert verification fails on the client (it uses CAPath). So client returns a failure to server. After that i want to load the pem file in the ssl_context and then try to re-establish a connection.

Is that possible in any way?

Regards,

0 new messages