Re: [openssl-dev] Adding async support

[Dmitry Belyavsky]

Dear Matt,

On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  wrote:

>
>
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
>
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
>

If we have an engine executing long crypto operations, how can we adopt the
engine and software using this engine to process them asynchronously?


-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 21:44, Dmitry Belyavsky wrote:
> Dear Matt, 
> 
> On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
> 
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
> 
> 
> If we have an engine executing long crypto operations, how can we adopt
> the engine and software using this engine to process them asynchronously? 

The engine needs to have a way of offloading the work to "something
else" so that it can come back and pick up the results later. Typically
for an engine this would mean some external hardware, but as I suggested
above it could be done using threads.

>From an engine perspective the work would be:
- Receive a request to do some crypto work in the normal way via the
engine API.
- Offload the work to "something else"
- Call the new API function ASYNC_pause_job(). This will return control
back to the calling application.
- At sometime later, preferably when the application knows the work has
completed (* see below), the application will resume the async job. From
an engine perspective this just appears as the ASYNC_pause_job()
function call returning - so it just continues where it left off
- The engine should verify that the work offloaded to "something else"
has completed.
- If not it just calls ASYNC_pause_job() again as before.
- If it has completed then it collects the results and returns them back
in the normal way for an engine

>From an application perspective it depends whether it is using libcrypto
directly, or whether it is using libssl.

If libssl then:
- the application essentially operates as normal
- additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to
set the SSL_ASYNC_MODE
- In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must
be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in
essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
i.e sometime later (* see below) it recalls
SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed.

If using libcrypto then:
- the application must determine which crypto operations it wants to
perform asynchronously. Those operations should be wrapped in an
application defined function.
- the application initiates the async job by calling ASYNC_start_job and
passing in a pointer to the function to be started as a job.
- from an engine perspective it will work in exactly the same way as for
libssl initiated crypto work.
- ASYNC_start_job may return with an ASYNC_PAUSE response. The
application can go off and do other work, and then resume the job at a
later time by recalling ASYNC_start_job.


So the next question is how does the application know when it is ok to
resume a job? There are two basic models:

- Event based...essentially the engine signals to the application that
the results are ready for collection
- Polling...in this model the application will have to periodically
restart the job to see if it is ready to be continued or not

There are API calls available for the event based model. See
ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and
SSL_get_async_wait_fd() in the documentation links I sent out previously.

There is some example code in the ASYNC_start_job() documentation. You
can also look at the source code for the dummy async engine.

Matt

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

Re: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests

[Kurt Roeckx via RT]

On Tue, Jun 02, 2015 at 03:50:19PM +0200, Pascal Cuoq via RT wrote:
> The attached archive contains a collection of patches for undefined behaviors
> that happen while the tests in directory tests/ are executed, with a recent
> (as of June 2015) OpenSSL git version.
> 
> Each undefined behavior really happens for at least one
> execution, the execution of the test. In other terms, none of these is a
> "false positive". The issues broadly fall in the following categories:

So some of the patches got applied, but I have some comments about
the remaining:

- cast_lcl.h.patch: Your patch has the same effect as defining
  PEDANTIC.  I recommend you at least run your tool with PEDANTIC
  defined.
- ssl_locl.h.patch: I don't see a struct timeval
  crypto/x509v3/v3_scts.c.  Does this comment still apply?  Maybe
  we fixed the issue in some other way.
- malloc.patch: I started looking at it, and I have some
  comments/questions:
  - I currently don't see a way that s->d1 can be NULL except
after an dtls1_free() call.  The same seem to go for
DTLS_RECORD_LAYER_free(), ssl3_free(), pkey_hmac_cleanup(),
aes_gcm_cleanup() and aes_ocb_cleanup().
Are you saying there are cases we could end up calling those
twice?
  - It seems to contain changes to the test suite to check return
values.  It seems non-obvious that this is about memory
allocation that might have failed, but it's probably the only
reasons those failures can happen.  It's a little confusing
that it's in the same patch where you can't directly see the
malloc failing.


Kurt


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

[openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello people,

An enhancement request here for OpenSSL to add support for Camellia in GCM
with ECC key exchange.

Rationale:
Camellia has been recognized as a modern and supported cipher by ENISA,
NESSIE, CRYPTREC, ISO and IETF among others so should be supported
long-term. OpenSSL currently only supports the (rather expensive) DHE/RSA
CBC+IV versions of the suite, and should be updated with the ECC and GCM
modes of operation.

It's important to have at least one cipher coming from non-US expert bodies
that is maintained to the same level as AES currently is, and OpenSSL seems
to be trailing behind in that respect. I would request addition of at least
the following:

TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a)
And possibly their 256-bit counterparts

These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, iiuc.
Firefox will also be adding the GCM versions of Camellia to NSS, and my own
browser (Pale Moon) also has it slated for the next milestone. Considering
the large use of OpenSSL to build other software on, including big names,
e.g. nginx, it's of great importance to add these suites.

Thanks for your consideration,
  Moonchild (AKA Mark)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlYVsD8ACgkQEguw022l8qzGgAD+K6r2gxYYQRjrfAqz+JX1ClG9
1wsCrrMe1GZlnQLjAS0BAJmLVXej56Xpd8qNK4+tMucquUIjip8TNxTKyQu/MOeB
=wzz5
-END PGP SIGNATURE-

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] Adding async support

[Matt Caswell]

Hi all

A number of people have expressed interest in the async work that I have
been doing in collaboration with Intel. This has now progressed to the
point where it is going through team review. I thought some of you might
like to get early sight of this so I have pushed it to my personal
github repo (see the "main-async" branch):

https://github.com/mattcaswell/openssl

Obviously there may be some tweaks that occur during the review process
but hopefully it is stable enough to give you an idea of how it will work.

I have also opened a github pull request so you can post comments on the
code there if you wish:

https://github.com/openssl/openssl/pull/433

The idea is that async aware application code will be able to use
OpenSSL to initiate crypto operations asynchronously. In order to work
this will require the presence of an async capable engine. For example
you could imagine an engine that could initiate work on some external
hardware and enable application code to come back at some later time for
the results.

This has been implemented through the concept of an ASYNC_JOB. At the
libcrypto level an application developer would write a function that
they wish to execute asynchronously which might call a number of
different crypto operations. They can then initiate that job using a new
API call "ASYNC_start_job()". The function will then execute until the
engine (or indeed anything - it doesn't have to be in an engine; it
could be user code) calls "ASYNC_pause_job()". At this point control
returns back to the application code. The job can be resumed later
through a second call to "ASYNC_start_job()" - it will pick up where it
left off. The main restriction here is that this must be done from the
same thread as the original ASYNC_start_job() call. A flagging mechanism
has been implemented to enable application code to know whether the
async job is "ready" to be resumed.

libssl has been made async aware through the introduction of a new mode
"SSL_MODE_ASYNC". The mode is set using a call to one of the existing
functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
calls to functions such as SSL_read/SSL_write etc, may now start
returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
is present). To resume you simply recall SSL_read/SSL_write in the same
way as you would if you got an SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
thread as the original call.

In order to enable people to test this out I have provided a "Dummy
Async" engine (dasync). This can't really do async work, but it pretends
it can :-). For certain crypto operations (currently only SHA1 and RSA)
it will call ASYNC_pause_job() at various points. Once you resume the
job it will just continue synchronously.

I have also added async support to s_server and s_client through the new
"-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
effect you will obviously also need an async engine (such as dasync)
loaded through the "-engine" flag. Note that dasync will only be loaded
dynamically and thus OpenSSL must be built "shared" for this to work.

Documentation including some example code is available on all of this here:
https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod

I'd be interested to hear your thoughts.

Matt

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

Re: [openssl-dev] Elliptical Cipher Suites

[Thirumal, Karthikeyan]

Vik
Am using 0.9.8a version. Am trying to fix few weak ciphers in my SSL connection 
and also to make Elliptical cipher suites enable.
I see that ECDHE ciphers are elliptical - need more info on this.

Thanks & Regards

Karthikeyan Thirumal

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Viktor 
Dukhovni
Sent: Wednesday, October 07, 2015 6:26 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Elliptical Cipher Suites

On Wed, Oct 07, 2015 at 12:14:38PM +, Thirumal, Karthikeyan wrote:

> Can some one tell me how to enable all the Elliptical Cipher suites ? 
> Is there a single flag to enable all of the elliptical ciphers ?

This question belongs on the openssL-users list, and even there much more 
detail needs to be provided along with the question.

* Compiling OpenSSL or using a precompiled version?
* Which version?
* Writing a program that use the API, or using the command-line tools?
* What motivates this question?  What have you tried and what were the 
results?

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

**
This message and any files or attachments sent with this message contain 
confidential information and is intended only for the individual named.  If you 
are not the named addressee, you should not disseminate, distribute, copy or 
use any part of this email.  If you have received this message in error, please 
delete it and all copies from your system and notify the sender immediately by 
return Email.

Email transmission cannot be guaranteed to be secure or error-free as 
information can be intercepted, corrupted, lost, destroyed, late, incomplete or 
may contain viruses.  The sender, therefore, does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
email transmission.
**
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Elliptical Cipher Suites

[Viktor Dukhovni]

On Wed, Oct 07, 2015 at 12:14:38PM +, Thirumal, Karthikeyan wrote:

> Can some one tell me how to enable all the Elliptical Cipher suites ? Is
> there a single flag to enable all of the elliptical ciphers ?

This question belongs on the openssL-users list, and even there
much more detail needs to be provided along with the question.

* Compiling OpenSSL or using a precompiled version?
* Which version?
* Writing a program that use the API, or using the command-line tools?
* What motivates this question?  What have you tried and what were the 
results?

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 14:29, Viktor Dukhovni wrote:
> On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> 
>> I have also added async support to s_server and s_client through the new
>> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
>> effect you will obviously also need an async engine (such as dasync)
>> loaded through the "-engine" flag. Note that dasync will only be loaded
>> dynamically and thus OpenSSL must be built "shared" for this to work.
>>
>> Documentation including some example code is available on all of this here:
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
>>
>> I'd be interested to hear your thoughts.
> 
> Will existing applications doing non-blocking I/O with OpenSSL need
> to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> only if they explicitly request "async mode"?

No, they should not need to be modified. You will only get
SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.

> 
> Should applications generally enable async mode because that might
> be beneficial down the road?  Or is this just for exotic hardware
> not likely to be seen in most environments?

It will only be helpful if you have an engine capable of supporting
async. I can't really answer the question because I don't know how
common this will be. My hope is that this will become relatively common.
I have been toying with the idea of creating a multi-threaded async
engine where the engine manages a pool of threads to offload async work
to which would then offer true async support even if you don't have
specialist hardware.

> For example, should Postfix enable "async" support?  It does timed
> non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.

If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
would encourage making the changes. You may want to consider making it a
configurable option. There is a small overhead with creating ASYNC_JOBs
and context switching into them when they start and finish.

Matt

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

Re: [openssl-dev] Adding async support

[Mark Ellzey]

As a maintainer of libevent, and spending heaps of time in the ssl
abstractions, anything to remove all the insane things you must do now for
async io would be a reprieve of the horrors we've dealt with over the
years.

I do worry that these patches may take too much of the work away to the
point of no decent control mechanism. When I see poll() everywhere, it
throws up red flags.

I will spend some time with the proposed patches here, and see if I can
make libevent happy, and hopefully very less complex.

Fingers crossed. Cheers!

On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell  wrote:

>
>
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> >
> >> I have also added async support to s_server and s_client through the new
> >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
> >> effect you will obviously also need an async engine (such as dasync)
> >> loaded through the "-engine" flag. Note that dasync will only be loaded
> >> dynamically and thus OpenSSL must be built "shared" for this to work.
> >>
> >> Documentation including some example code is available on all of this
> here:
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
> >>
> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
> >>
> >> I'd be interested to hear your thoughts.
> >
> > Will existing applications doing non-blocking I/O with OpenSSL need
> > to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> > only if they explicitly request "async mode"?
>
> No, they should not need to be modified. You will only get
> SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.
>
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
>
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
>
> > For example, should Postfix enable "async" support?  It does timed
> > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.
>
> If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
> not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
> would encourage making the changes. You may want to consider making it a
> configurable option. There is a small overhead with creating ASYNC_JOBs
> and context switching into them when they start and finish.
>
> Matt
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4074] [PATCH] Fixes for when PSK, SRP, SRTP and DTLS1 are disabled

[Short, Todd via RT]

Hello OpenSSL Org:

While evaluating the master branch, I discovered that the code does not 
compile, nor do the unit tests pass, when disabling certain features. 
Specifically, PSK, SRP, SRTP and DTLS1.

The following patch for master branch will fix the issues.

Thanks,

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."



0001-Fix-when-SRP-SRTP-DTLS1-PSK-are-disabled.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Test, sorry, please ignore.

[Salz, Rich]

Thanks.
/r$

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz

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

[openssl-dev] Sorry, another test

[Salz, Rich]

/r$

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

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 16:57, Devchandra L Meetei wrote:
> 
> 
> On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell  >
> wrote:
> 
> 
> 
> libssl has been made async aware through the introduction of a new mode
> "SSL_MODE_ASYNC". The mode is set using a call to one of the existing
> functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
> calls to functions such as SSL_read/SSL_write etc, may now start
> returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
> is present). To resume you simply recall SSL_read/SSL_write in the same
> way as you would if you got an SSL_ERROR_WANT_READ or
> SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
> thread as the original call.
> 
>  
> Does this also mean that there will not be any libssl API change?

There are no changes to the fundamental way the libssl API works. This
is about integrating a new source of async events i.e. the capability to
asynchronously process crypto operations by pushing the work off into
some async capable engine. It's not about changing the way async events
are presented to applications in libssl.

> 
> I have been developing async calls of TLS I/O using bio pair, for instance
> for SSL_read, it is something like
> 
>> int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf,
> int sz))
> 
> The cb will be called asynchronously whenever there is application data.
> 
> Will there be any such change? Such API's will make integrating OpenSSL
> with other
> async lib like libevent, libev and libuv etc.

There are no such changes planned.

Matt

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

Re: [openssl-dev] Adding async support

[Devchandra L Meetei]

Hello Mark
I have been working recently on evt ,
which is still in WIP, exposing a callback based async API's on top of
libssl.

The idea was to abstract libssl with well defined APIs that can be
integrated with libraries like libevent and libuv.

Thought It might be of interest to libevent.

On Wed, Oct 7, 2015 at 7:35 PM, Mark Ellzey  wrote:

> As a maintainer of libevent, and spending heaps of time in the ssl
> abstractions, anything to remove all the insane things you must do now for
> async io would be a reprieve of the horrors we've dealt with over the
> years.
>
> I do worry that these patches may take too much of the work away to the
> point of no decent control mechanism. When I see poll() everywhere, it
> throws up red flags.
>
> I will spend some time with the proposed patches here, and see if I can
> make libevent happy, and hopefully very less complex.
>
> Fingers crossed. Cheers!
>
> On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell  wrote:
>
>>
>>
>> On 07/10/15 14:29, Viktor Dukhovni wrote:
>> > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
>> >
>> >> I have also added async support to s_server and s_client through the
>> new
>> >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have
>> an
>> >> effect you will obviously also need an async engine (such as dasync)
>> >> loaded through the "-engine" flag. Note that dasync will only be loaded
>> >> dynamically and thus OpenSSL must be built "shared" for this to work.
>> >>
>> >> Documentation including some example code is available on all of this
>> here:
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
>> >>
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
>> >>
>> >> I'd be interested to hear your thoughts.
>> >
>> > Will existing applications doing non-blocking I/O with OpenSSL need
>> > to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
>> > only if they explicitly request "async mode"?
>>
>> No, they should not need to be modified. You will only get
>> SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.
>>
>> >
>> > Should applications generally enable async mode because that might
>> > be beneficial down the road?  Or is this just for exotic hardware
>> > not likely to be seen in most environments?
>>
>> It will only be helpful if you have an engine capable of supporting
>> async. I can't really answer the question because I don't know how
>> common this will be. My hope is that this will become relatively common.
>> I have been toying with the idea of creating a multi-threaded async
>> engine where the engine manages a pool of threads to offload async work
>> to which would then offer true async support even if you don't have
>> specialist hardware.
>>
>> > For example, should Postfix enable "async" support?  It does timed
>> > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.
>>
>> If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
>> not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
>> would encourage making the changes. You may want to consider making it a
>> configurable option. There is a small overhead with creating ASYNC_JOBs
>> and context switching into them when they start and finish.
>>
>> Matt
>>
>> ___
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>


-- 
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb
changed the world more than Karl Marx ever did,” Steve Jobs
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Devchandra L Meetei]

On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell  wrote:


>
>
> libssl has been made async aware through the introduction of a new mode
> "SSL_MODE_ASYNC". The mode is set using a call to one of the existing
> functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
> calls to functions such as SSL_read/SSL_write etc, may now start
> returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
> is present). To resume you simply recall SSL_read/SSL_write in the same
> way as you would if you got an SSL_ERROR_WANT_READ or
> SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
> thread as the original call.
>

Does this also mean that there will not be any libssl API change?

I have been developing async calls of TLS I/O using bio pair, for instance
for SSL_read, it is something like

> int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf, int
sz))

The cb will be called asynchronously whenever there is application data.

Will there be any such change? Such API's will make integrating OpenSSL
with other
async lib like libevent, libev and libuv etc.

Please forgive me if I am asking a dumb question without looking at code
changes done.

-- 
Warm Regards
--Dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev