Re: [openssl-users] Shutdown details

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 longe

Re: [openssl-users] Shutdown details

> 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 cont

Re: [openssl-users] Shutdown details

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

Re: [openssl-users] Shutdown details

> 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 threa

Re: [openssl-users] Shutdown details

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

Re: [openssl-users] Shutdown details

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. >

Re: [openssl-users] Shutdown details

> 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

Re: [openssl-users] Shutdown details

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:

Re: [openssl-users] Shutdown details

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

Re: [openssl-users] Shutdown details

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. Ku

Re: [openssl-users] Shutdown details

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. > >

Re: [openssl-users] Shutdown details

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

Re: [openssl-users] Shutdown details

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

Re: [openssl-users] Shutdown details

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

Re: [openssl-users] Shutdown details

[...] 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_RECE

Re: [openssl-users] Shutdown details

> 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 sen

Re: [openssl-users] Shutdown details

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 ba

[openssl-users] Shutdown details

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?