Hi,
Not my option, unfortunately, as we sell a toolkit for customer
implementations. But I guess I have the same problem in a non-SSL
environment in any case, so I have to handle it some way.
G.
-----Original Message-----
From: Greg Stark [mailto:[EMAIL PROTECTED]]
Sent: 19 April 2001 16:04
To: [EMAIL PROTECTED]
Subject: Re: Closing SSL connections
George,
Do you really need to allow SSLv2? I'm curious, as I would think that by now
there are almost no systems left which CANNOT use SSLv3.
_____________________________________
Greg Stark
Ethentica, Inc.
[EMAIL PROTECTED]
_____________________________________
----- Original Message -----
From: "Shaw, George" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 19, 2001 6:12 AM
Subject: RE: Closing SSL connections
> Thanks again Greg,
>
> I did a little more testing. As you indicated in your earlier mail, if I
> receive SSL_ERROR_ZERO_RETURN I can test SSL_get_shutdown() and for TLSv1
> and SSLv3 this will indicate the connection closure, which will be safe
> enough for me I think. But this state is not set for SSLv2.
>
> Your comment about how to know that the HTTP response is complete is
> entirely appropriate. The use of the Content Length header or data
chunking
> is recommended in the RFC, but socket closure as an indicator is allowed
by
> HTTP 1.0, and by 1.1 due to backwards compatibility. And if I test my
> client against Apache, with the URL configured to return no Content
Length,
> then if you use HTTP 1.1, Apache will include data chunking to indicate
the
> end-of-response, but if you use HTTP 1.0, then there is no indication at
> all, you just have to wait for the socket closure. This is all in a
non-SSL
> environment, but I would guess that this is the same using SSL.
>
> So this leaves me with a problem using HTTP 1.0 and SSL v2. SSL v2 still
> returns SSL_ERROR_ZERO_RETURN when the connection is closed. As I'm
working
> in a B2B environment, I guess I'll have to make some kind of restriction
on
> the application, or to issue a warning/alert of some kind.
>
> Unless somebody else has experience of this ...
>
> Thanks again,
>
> G.
>
>
> -----Original Message-----
> From: Greg Stark [mailto:[EMAIL PROTECTED]]
> Sent: 18 April 2001 20:10
> To: [EMAIL PROTECTED]
> Subject: Re: Closing SSL connections
>
>
> George,
>
> I don't really know what happens in the SSLv2 case. SSLv2 has no
> close_notify message, so there's no secure way for SSL to know that a
> connection is being closed. The higher level protocol must provide some
> equivalent secure mechanism for connection closure, or you are vulnerable
to
> truncation attacks.
>
> When you call SSL_shutdown() on an SSLv2 connection, the library doesn't
> actually do much of anything except mark the connection as having been
> shutdown. So I don't know what happens, you'll have to try it and see or
> perhaps someone else can answer.
>
> In SSLv2, without a Content-Length header or some other heursitic (like
> looking for the </HTML> tag), how can your client be certain the transport
> closure packet (TCP FIN) wasn't spoofed?
>
>
> _____________________________________
> Greg Stark
> Ethentica, Inc.
> [EMAIL PROTECTED]
> _____________________________________
>
>
>
> ----- Original Message -----
> From: "Shaw, George" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, April 18, 2001 1:25 PM
> Subject: RE: Closing SSL connections
>
>
> > Thanks Greg,
> >
> > Does this mean that SSL v2 would return a different return code from
> > SSL_read? And if not then how can I check for the particular
circumstance
> > of a socket disconnection in this mode. I'm just trying to get a handle
> on
> > how I can support the RFC with SSL v2, it must have been done by others
> > before now.
> >
> > G.
> >
> > -----Original Message-----
> > From: Greg Stark [mailto:[EMAIL PROTECTED]]
> > Sent: 18 April 2001 18:14
> > To: [EMAIL PROTECTED]
> > Subject: Re: Closing SSL connections
> >
> >
> > It is safe to treat this as a non-error if you are using SSL version 3
or
> > higher, but not if you connected with SSL version 2. So do not use SSL
v2.
> >
> > Sending an SSL_shutdown() is the safe way to close the connection, but
it
> > may have performace implications because of the rules OpenSSL uses for
> > managing session resumption. See the documentation for
SSL_set_shutdown()
> > (http://www.openssl.org/docs/ssl/SSL_set_shutdown.html#) for some hints
of
> > what to do.
> >
> > _____________________________________
> > Greg Stark
> > Ethentica, Inc.
> > [EMAIL PROTECTED]
> > _____________________________________
> >
> >
> >
> > ----- Original Message -----
> > From: "Shaw, George" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, April 18, 2001 12:38 PM
> > Subject: Closing SSL connections
> >
> >
> > > Hi,
> > >
> > > I'm working with an HTTP application, and according to the RFC when
> > sending
> > > the HTTP response it is permissible to signal the end of the response
by
> > > closing the socket (rather than using the Content-Length header).
> > >
> > > When implementing the HTTP client using SSL, SSL_read will return
> > > SSL_ERROR_ZERO_RETURN. Is it safe to treat this as a non-error. i.e.
> > there
> > > are no other circumstances in which this return code will signal a
true
> > > error?
> > >
> > > When implementing the HTTP server using SSL, is it safe to issue an
> > > SSL_shutdown and a socket disconnect while the client is listening?
> > >
> > > Thanks,
> > >
> > > G.
> > > ______________________________________________________________________
> > > OpenSSL Project http://www.openssl.org
> > > User Support Mailing List [EMAIL PROTECTED]
> > > Automated List Manager [EMAIL PROTECTED]
> >
> > ______________________________________________________________________
> > OpenSSL Project http://www.openssl.org
> > User Support Mailing List [EMAIL PROTECTED]
> > Automated List Manager [EMAIL PROTECTED]
> > ______________________________________________________________________
> > OpenSSL Project http://www.openssl.org
> > User Support Mailing List [EMAIL PROTECTED]
> > Automated List Manager [EMAIL PROTECTED]
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
