Re: [openssl-users] Shutdown details

[Alex H]

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 :

> 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

Re: [openssl-users] Shutdown details

[Viktor Dukhovni]

> On Aug 1, 2018, at 2:27 AM, Alex H  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

Re: [openssl-users] Shutdown details

[Alex H]

[...] 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 <
openssl-us...@dukhovni.org>:

>
>
> > On Aug 1, 2018, at 2:27 AM, Alex H  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

Re: [openssl-users] 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:

https://github.com/openssl/openssl/issues/6911 


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  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 
> mailto:openssl-us...@dukhovni.org>>:
> 
> 
> > On Aug 1, 2018, at 2:27 AM, Alex H  > > 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

Re: [openssl-users] Shutdown details

[Alex H]

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 <
philipp_s...@redfish-solutions.com>:

> 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:
>
> https://github.com/openssl/openssl/issues/6911
>
> 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  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 <
> openssl-us...@dukhovni.org>:
>
>>
>>
>> > On Aug 1, 2018, at 2:27 AM, Alex H  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 unsubsc

Re: [openssl-users] Shutdown details

[Kurt Roeckx]

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

Re: [openssl-users] Shutdown details

[Kurt Roeckx]

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

Re: [openssl-users] Shutdown details

[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

Re: [openssl-users] Shutdown details

[Viktor Dukhovni]

> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx  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

Re: [openssl-users] Shutdown details

[Alex H]

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 :

> 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

Re: [openssl-users] Shutdown details

[Viktor Dukhovni]

> On Aug 12, 2018, at 3:59 PM, Viktor Dukhovni  
> 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

Re: [openssl-users] Shutdown details

[Matt Caswell]

On 12/08/18 20:59, Viktor Dukhovni wrote:
> 
> 
>> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx  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

Re: [openssl-users] Shutdown details

[Jordan Brown]

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

Re: [openssl-users] Shutdown details

[Viktor Dukhovni]

> On Aug 13, 2018, at 2:13 PM, Jordan Brown  
> 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

Re: [openssl-users] Shutdown details

[Alex H]

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 
skrev:

>
>
> > On Aug 13, 2018, at 2:13 PM, Jordan Brown 
> 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

Re: [openssl-users] Shutdown details

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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

Re: [openssl-users] Shutdown details

[Jordan Brown]

On 8/13/2018 11:25 AM, Viktor Dukhovni wrote:
>> On Aug 13, 2018, at 2:13 PM, Jordan Brown  
>> 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