Shutdown details

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Shutdown details

Alex Hultman
Hi,

I have trouble understanding the details of TLS shutdown. I get the basics but,

Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.

That is, after sending a close_notify, can I receive data before getting my client_notify response?

The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This indicates somehow I'm allowed to still send data after received a close_notify?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Alex Hultman
I would appreciate an answer to this question, it's holding me back and should be a simple yes/no.

And yes, "client_notify" is a typo and should be "close_notify".

Thanks

Den ons 1 aug. 2018 kl 08:27 skrev Alex H <[hidden email]>:
Hi,

I have trouble understanding the details of TLS shutdown. I get the basics but,

Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.

That is, after sending a close_notify, can I receive data before getting my client_notify response?

The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This indicates somehow I'm allowed to still send data after received a close_notify?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Viktor Dukhovni
In reply to this post by Alex Hultman


> On Aug 1, 2018, at 2:27 AM, Alex H <[hidden email]> wrote:
>
> Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.

TLS *does not* support half-closed connections (RFC5246):

   close_notify
      This message notifies the recipient that the sender will not send
      any more messages on this connection.  Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

   Note: It is assumed that closing a connection reliably delivers
   pending data before destroying the transport.

If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Alex Hultman
[...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes.

I've read this before, but I've also checked the sources of SSL_write and they seem contradictory:

SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the RFC states the end who receives a close_notify should discard any pending writes then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set?

....

> If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

I also believe so, especially since SSL_shutdown docs seem to hint that once SSL_shutdown is called, it should be called again until fully done (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown becomes the only function called until the SSL connection is fully closed, no more SSL_read is called and thus it cannot report any received data. SSL_shutdown does not return with any data.

Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug?

Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni <[hidden email]>:


> On Aug 1, 2018, at 2:27 AM, Alex H <[hidden email]> wrote:
>
> Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.

TLS *does not* support half-closed connections (RFC5246):

   close_notify
      This message notifies the recipient that the sender will not send
      any more messages on this connection.  Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

   Note: It is assumed that closing a connection reliably delivers
   pending data before destroying the transport.

If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Philip Prindeville
Hi.

This is something that I’m also interested, as a contributor to Libevent, which provides SSL-socket support.

I’ve opened an OpenSSL issue:


to collect the details on how a graceful shutdown can be implemented in Libevent.

Thanks,

-Philip


On Aug 1, 2018, at 1:46 PM, Alex H <[hidden email]> wrote:

[...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes.

I've read this before, but I've also checked the sources of SSL_write and they seem contradictory:

SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the RFC states the end who receives a close_notify should discard any pending writes then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set?

....

> If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

I also believe so, especially since SSL_shutdown docs seem to hint that once SSL_shutdown is called, it should be called again until fully done (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown becomes the only function called until the SSL connection is fully closed, no more SSL_read is called and thus it cannot report any received data. SSL_shutdown does not return with any data.

Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug?

Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni <[hidden email]>:


> On Aug 1, 2018, at 2:27 AM, Alex H <[hidden email]> wrote:
>
> Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.

TLS *does not* support half-closed connections (RFC5246):

   close_notify
      This message notifies the recipient that the sender will not send
      any more messages on this connection.  Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

   Note: It is assumed that closing a connection reliably delivers
   pending data before destroying the transport.

If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Alex Hultman
I ended up just treating those details as "unknown" and making my interface more low-level than I first aimed for.

I wanted to make the shutdown procedure more automated with a simpler API that wrapped things at a higher level but ended up with pretty much BSD-sockets, but SSL.

It is pretty easy to implement when you allow a little bit of uncertainty - it's not required to know 100% of how the internals work to implement shutdown.

Den lör 11 aug. 2018 kl 02:41 skrev Philip Prindeville <[hidden email]>:
Hi.

This is something that I’m also interested, as a contributor to Libevent, which provides SSL-socket support.

I’ve opened an OpenSSL issue:


to collect the details on how a graceful shutdown can be implemented in Libevent.

Thanks,

-Philip


On Aug 1, 2018, at 1:46 PM, Alex H <[hidden email]> wrote:

[...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes.

I've read this before, but I've also checked the sources of SSL_write and they seem contradictory:

SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the RFC states the end who receives a close_notify should discard any pending writes then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set?

....

> If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

I also believe so, especially since SSL_shutdown docs seem to hint that once SSL_shutdown is called, it should be called again until fully done (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown becomes the only function called until the SSL connection is fully closed, no more SSL_read is called and thus it cannot report any received data. SSL_shutdown does not return with any data.

Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug?

Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni <[hidden email]>:


> On Aug 1, 2018, at 2:27 AM, Alex H <[hidden email]> wrote:
>
> Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry.

TLS *does not* support half-closed connections (RFC5246):

   close_notify
      This message notifies the recipient that the sender will not send
      any more messages on this connection.  Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

   Note: It is assumed that closing a connection reliably delivers
   pending data before destroying the transport.

If your question is whether you can still read any data that may have
been in flight when you send your close_notify, I believe the answer
is no.  Further data received from the peer is discarded after a
close_notify is sent.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Kurt Roeckx
In reply to this post by Alex Hultman
On Wed, Aug 01, 2018 at 08:27:38AM +0200, Alex H wrote:

> Hi,
>
> I have trouble understanding the details of TLS shutdown. I get the basics
> but,
>
> Is it possible to receive data after calling SSL_shutdown? Reading the
> specs and docs leaves this rather blurry.
>
> That is, after sending a close_notify, can I receive data before getting my
> client_notify response?
>
> The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns
> with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This
> indicates somehow I'm allowed to still send data after received a
> close_notify?

TLS 1.3 makes it explicit that after you've send a close_notify,
the peer is still allowed to send data, so you can still read
data. It only closes the connection in one direction.

As far as I know, OpenSSL has always supported this, even when the
RFC said that the other side needs to send the close_notify back
on receiving it.

In -pre8 we even have tests covering this behaviour, and the
manpages have been update to say that it's possible. See
https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Kurt Roeckx
In reply to this post by Alex Hultman
On Wed, Aug 01, 2018 at 09:46:37PM +0200, Alex H wrote:

>
> > If your question is whether you can still read any data that may have
> been in flight when you send your close_notify, I believe the answer
> is no.  Further data received from the peer is discarded after a
> close_notify is sent.
>
> I also believe so, especially since SSL_shutdown docs seem to hint that
> once SSL_shutdown is called, it should be called again until fully done
> (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown
> becomes the only function called until the SSL connection is fully closed,
> no more SSL_read is called and thus it cannot report any received data.
> SSL_shutdown does not return with any data.

You are probably reading old documentation. The documentation has
been updated say that it's adviced to call SSL_read() until you
get SSL_ERROR_ZERO_RETURN.


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Kurt Roeckx
In reply to this post by Kurt Roeckx
On Sun, Aug 12, 2018 at 08:49:35PM +0200, Kurt Roeckx wrote:
> In -pre8 we even have tests covering this behaviour, and the
> manpages have been update to say that it's possible. See
> https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html

I think this was actually commited after pre8.


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Viktor Dukhovni
In reply to this post by Kurt Roeckx


> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx <[hidden email]> wrote:
>
> TLS 1.3 makes it explicit that after you've send a close_notify,
> the peer is still allowed to send data, so you can still read
> data. It only closes the connection in one direction.

Which is a change from previously required behaviour:

   https://tools.ietf.org/html/rfc8446#section-6.1

   Each party MUST send a "close_notify" alert before closing its write
   side of the connection, unless it has already sent some error alert.
   This does not have any effect on its read side of the connection.
   Note that this is a change from versions of TLS prior to TLS 1.3 in
   which implementations were required to react to a "close_notify" by
   discarding pending writes and sending an immediate "close_notify"
   alert of their own.  That previous requirement could cause truncation
   in the read side.  Both parties need not wait to receive a
   "close_notify" alert before closing their read side of the
   connection, though doing so would introduce the possibility of
   truncation.

> As far as I know, OpenSSL has always supported this, even when the
> RFC said that the other side needs to send the close_notify back
> on receiving it.

We might want to double-check that, I would have expected RFC-compliance
here...  Matt Caswell should know the definitive answer...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Alex Hultman
In reply to this post by Kurt Roeckx
Oh wow! That's perfect!

Now the docs are very clear on this and essentially SSL _does_ support half-closed sockets.

Thanks for clarifying this, TLS 1.3 seems like a big step forward.

Den sön 12 aug. 2018 kl 21:05 skrev Kurt Roeckx <[hidden email]>:
On Sun, Aug 12, 2018 at 08:49:35PM +0200, Kurt Roeckx wrote:
> In -pre8 we even have tests covering this behaviour, and the
> manpages have been update to say that it's possible. See
> https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html

I think this was actually commited after pre8.


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Viktor Dukhovni
In reply to this post by Viktor Dukhovni


> On Aug 12, 2018, at 3:59 PM, Viktor Dukhovni <[hidden email]> wrote:
>
>> As far as I know, OpenSSL has always supported this, even when the
>> RFC said that the other side needs to send the close_notify back
>> on receiving it.
>
> We might want to double-check that, I would have expected RFC-compliance
> here...  Matt Caswell should know the definitive answer...

It would also be good to know how the behaviour in master (pre8) differs
(if at all) from 1.1.0 and/or 1.0.2.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Matt Caswell-2
In reply to this post by Viktor Dukhovni


On 12/08/18 20:59, Viktor Dukhovni wrote:

>
>
>> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx <[hidden email]> wrote:
>>
>> TLS 1.3 makes it explicit that after you've send a close_notify,
>> the peer is still allowed to send data, so you can still read
>> data. It only closes the connection in one direction.
>
> Which is a change from previously required behaviour:
>
>    https://tools.ietf.org/html/rfc8446#section-6.1
>
>    Each party MUST send a "close_notify" alert before closing its write
>    side of the connection, unless it has already sent some error alert.
>    This does not have any effect on its read side of the connection.
>    Note that this is a change from versions of TLS prior to TLS 1.3 in
>    which implementations were required to react to a "close_notify" by
>    discarding pending writes and sending an immediate "close_notify"
>    alert of their own.  That previous requirement could cause truncation
>    in the read side.  Both parties need not wait to receive a
>    "close_notify" alert before closing their read side of the
>    connection, though doing so would introduce the possibility of
>    truncation.
>
>> As far as I know, OpenSSL has always supported this, even when the
>> RFC said that the other side needs to send the close_notify back
>> on receiving it.
>
> We might want to double-check that, I would have expected RFC-compliance
> here...  Matt Caswell should know the definitive answer...
>

We didn't make any changes to enable that for TLSv1.3. The library
already supported it - although perhaps the documentation wasn't so
clear (which should hopefully be fixed now).

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

JordanBrown
In reply to this post by Viktor Dukhovni
On 8/12/2018 12:59 PM, Viktor Dukhovni wrote:
Which is a change from previously required behaviour:

   https://tools.ietf.org/html/rfc8446#section-6.1

   Each party MUST send a "close_notify" alert before closing its write
   side of the connection, unless it has already sent some error alert.
   This does not have any effect on its read side of the connection.
   Note that this is a change from versions of TLS prior to TLS 1.3 in
   which implementations were required to react to a "close_notify" by
   discarding pending writes and sending an immediate "close_notify"
   alert of their own.  That previous requirement could cause truncation
   in the read side.  Both parties need not wait to receive a
   "close_notify" alert before closing their read side of the
   connection, though doing so would introduce the possibility of
   truncation.

I'm curious:  how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response?

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Viktor Dukhovni


> On Aug 13, 2018, at 2:13 PM, Jordan Brown <[hidden email]> wrote:
>
> I'm curious:  how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response?

This is no longer OpenSSL-specific.  Best to wind down this thread.
HTTP has a "Content-Length:" header or alternatively supports Chunked
transfers.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Alex Hultman
I don't mind upwinding it. These different reactions and input only help me design my things better. Very pleased with the discussion so far.

Den mån 13 aug. 2018 20:26Viktor Dukhovni <[hidden email]> skrev:


> On Aug 13, 2018, at 2:13 PM, Jordan Brown <[hidden email]> wrote:
>
> I'm curious:  how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response?

This is no longer OpenSSL-specific.  Best to wind down this thread.
HTTP has a "Content-Length:" header or alternatively supports Chunked
transfers.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

Michael Wojcik
In reply to this post by Viktor Dukhovni
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Viktor Dukhovni
>
> HTTP has a "Content-Length:" header or alternatively supports Chunked
> transfers.

For HTTP/1.1, RFC 2616 also allows the message body length to be determined by the use of the self-delimiting content-type such as multipart/byteranges. HTTP/1.0 permitted this for any self-delimiting content-type, but I don't know that I've ever seen an HTTP/1.0 implementation do it. (And messages which are not allowed to have a body, such as GET and HEAD, don't need to delimit the body, since there isn't one.)

Also relevant to Jordan's question:

- Nothing says the client has to do a half-close after sending the request. In fact, when HTTP/1.1 made persistent conversations the default, user agents mostly switched to keeping the conversation open after a request, until the server closed it or some idle timer expired.

- And, in fact, RFC 2616 implicitly *forbids* the client from using half-close to indicate the end of the response. The text oddly suggests the authors were unaware of half-close, though it's possible they simply wished to keep the same behavior if the transport didn't support half-close (as, indeed TLSv1.2 does not, if the specification is followed to the letter).

At any rate, RFC 2616 4.4 #5 says: " Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response." That's clearly wrong, for transports such as TCP that support half-close; but it handily eliminates any problem of a UA trying to delimit a request message-body with half-close when running over TLS.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Shutdown details

JordanBrown
In reply to this post by Viktor Dukhovni
On 8/13/2018 11:25 AM, Viktor Dukhovni wrote:
On Aug 13, 2018, at 2:13 PM, Jordan Brown [hidden email] wrote:

I'm curious:  how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response?
This is no longer OpenSSL-specific.  Best to wind down this thread.
HTTP has a "Content-Length:" header or alternatively supports Chunked
transfers.

You're right that it's not OpenSSL-specific, but the general topic of "how do you design protocols atop TLS" and "how do you take a TCP protocol and put it on top of TLS" seem relevant.

Huh.  Looking closely, I see that HTTP requires header-based framing information when the request has a body - either Content-Length or Transfer-Encoding.  And here I thought I had a pretty decent understanding of basic HTTP.  Maybe I've just never hand-crafted a POST request.  I learn something new every day.
-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users