Re: Blocking on a non-blocking socket?

On 5/24/24 03:30, Wiebe Cazemier via openssl-users wrote: Hi Matt, - Original Message - From: "Matt Caswell" To: openssl-users@openssl.org Sent: Friday, 24 May, 2024 00:26:28 Subject: Re: Blocking on a non-blocking socket? Not quite. When you call SSL_read() it is because you are h

Re: SSL_accept doesn't retry BIO_write

On 5/6/24 11:48, Michael Richardson wrote: > Now I treat the flush as 'OpenSSL isn't interested in the result > of the last write anymore'. I'm not sure this assumption is correct, > but it seems to work... (Well, it could cause duplicate messages It does not sound correct. I

SSL_accept doesn't retry BIO_write

Hello, I'm trying to write a non-blocking UDP based BIO to use for a DTLS connection. When the write() is called then the data is placed for transmission and '0' is returned. The respective OpenSSL function returns -1 with SSL_ERROR_WANT_WRITE. When the data is actually put on the wire a functio

OCSP verification in a non-blocking environment

I have a non-blocking DTLS server and use SSL_VERIFY_PEER. Now I'd like to use the verify_callback that I set with SSL_CTX_set_verify() to check via OCSP for revocation. This works fine in a simple blocking test program, where I can just wait for the OCSP reply and then return 0 or 1 from my verif

Re: Real MTU problems with BIO pair

On 2020-08-21 19:48, Benjamin Kaduk wrote: On Fri, Aug 21, 2020 at 05:05:51PM +0200, Detlef Vollmann wrote: On 2020-08-20 21:44, Detlef Vollmann wrote: Is there any way to set the maximum fragment size for DTLS handshake with a BIO pair? One solution is to set the MTU and the int_bio size to

Re: Real MTU problems with BIO pair

On 2020-08-20 21:44, Detlef Vollmann wrote: if I create a BIO pair with   BIO_new_bio_pair(&int_bio, 0, &ext_bio_, 0); then I tried to use SSL_set_mtu(), DTLS_set_link_mtu() and SSL_CTX_set_max_send_fragment(ctx, 1000). None of them gave me an error, but also none of them wor

Real MTU problems with BIO pair

Hello, if I create a BIO pair with BIO_new_bio_pair(&int_bio, 0, &ext_bio_, 0); then I tried to use SSL_set_mtu(), DTLS_set_link_mtu() and SSL_CTX_set_max_send_fragment(ctx, 1000). None of them gave me an error, but also none of them worked: the ServerHello was still sent as a single packet (>

Surprising behaviour of DTLSv1_listen

Hello, if I do: // ctx is setup with certificate, key and cookie callbacks BIO *bio = BIO_new_dgram(sock, BIO_NOCLOSE); SSL *ssl = SSL_new(ctx); SSL_set_bio(ssl, bio, bio.get()); DTLS_set_link_mtu(ssl, 1000); SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE); SSL_set_accept

Re: NULL ciphers

On 2020-08-13 20:20, Benjamin Kaduk wrote: On Thu, Aug 13, 2020 at 08:19:10PM +0200, Detlef Vollmann wrote: Hello, with the following commands: openssl s_server -accept 18010 -cert srv.crt -key test.key \ -CAfile testca.crt -debug -cipher 'NULL-SHA256' -dtls1_2 openssl s_clien

NULL ciphers

Hello, with the following commands: openssl s_server -accept 18010 -cert srv.crt -key test.key \ -CAfile testca.crt -debug -cipher 'NULL-SHA256' -dtls1_2 openssl s_client -connect localhost:18010 -cert clnt.crt \ -key test.key -CAfile testca.crt -debug \ -cipher 'COMPLEMENTOFALL:eNULL' -dtls1

DTLS reconnect

Hello, section 4.2.8 "Establishing New Associations with Existing Parameters" of RFC 6347 () recommends ("SHOULD") that a new ClientHello from a client IP/port pair for which a session already exists initiates a new handshake. I tried to test su