Re: [openssl-dev] Check for heartbeat response without reading?

It's for research. I need a way, using only SSL layer functionality, for a client to know with certainty that the server has received a message. This is trivial at the application layer, but that is not what is wanted. In particular, the client needs to know that the server has completed a

Re: [openssl-dev] Check for heartbeat response without reading?

Really? Strange. They are recommended for TLS 1.3 On Sun, Jan 24, 2016 at 5:17 PM, Salz, Rich wrote: > Like I said, I don't know that you can do it without changing some > source. And also, heartbeats for TLS (and maybe DTLS) are going away in > the next release. > >

Re: [openssl-dev] Check for heartbeat response without reading?

I was hoping SSL_peek might work, but I can't find any documentation. I do have the guarantee from the application layer that messaging occurs in a strict client request -> server response sequence, without any pipelining, etc. I know with certainty that the heartbeat response is the next

Re: [openssl-dev] Check for heartbeat response without reading?

The table in the following section of the latest draft for TLS 1.3 started the confusion: https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-11 On Sun, Jan 24, 2016 at 6:03 PM, Salz, Rich wrote: > > Really? Strange. They are recommended for TLS 1.3 > > No they're

[openssl-dev] Check for heartbeat response without reading?

Is it possible to check for a heartbeat response without calling SSL_read? I'm pretty sure the answer is no. This is problematic for me. I'm trying to make a library layer on top of OpenSSL that uses the heartbeat as an authenticated ack of earlier messages, without changing the application layer

Re: [openssl-dev] renegotiation failure causes SSL_shutdown to return 1?

Cool! Thanks for doing that :) On Wed, Jan 20, 2016 at 6:04 AM, Matt Caswell <m...@openssl.org> wrote: > > > On 05/12/15 09:42, Judson Wilson wrote: > > I am noticing the following sequence of events: > > > > 1) SSL_renegotiate(...), followed by SSL_write(..

Re: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

Here is an OpenSSL port of a patch in BoringSSL. It requires a call from the application to set a file BIO. You could probably do this from within SSL_CTX_new or something like that if you want a solution that doesn't change the application.

Re: [openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

Here is an OpenSSL port of a patch in BoringSSL. It requires a call from the application to set a file BIO. You could probably do this from within SSL_CTX_new or something like that if you want a solution that doesn't change the application.

[openssl-dev] s_client uses SSL_write(..., 0) for renegotiation?

Should s_client really be using a zero-byte-length SSL_write(...) as a followup to SSL_renegotiate(...)? All versions of the man pages on the OpenSSL web site state this will yield undefined behavior (which I find odd, but whatever). Is SSL_do_handshake(...) more appropriate?

[openssl-dev] renegotiation failure causes SSL_shutdown to return 1?

I am noticing the following sequence of events: 1) SSL_renegotiate(...), followed by SSL_write(..., 0) fails when a web server rejects it by sending a TCP FIN 2) SSL_get_error returns SSL_ERROR_SSL 3) SSL_in_init(...) is true 4) SSL_shutdown returns 1 <-- this seems strange. I'm not sure that