Thanks, Jakob. I was under the impression that in my environment, Diffie
Hellman key exchange would be in use, and that it would prevent the use of
decryption, even with private key. Is that wrong?
--
View this message in context:
On 27/05/2016 18:29, Matt Caswell wrote:
On 27/05/16 16:20, counterpoint wrote:
Thanks Matt, good points. Not easy to implement though!
In the problem case, my code is the server (it is a proxy), and the standard
MariaDB command line client is the client. Yes, it does look as if
everything is
Fixed the problem in the end, using eNULL was useful to get the full picture.
The issue my assumption that if there was data available to process (after
read ahead was turned off) then SSL_pending would tell me so. But it seems
that when the data extends beyond a single block (with OpenSSL
> Perhaps using an eNULL ciphersuite might help?
> Matt
Good idea, I'll give it a try.
--
View this message in context:
http://openssl.6102.n7.nabble.com/OpenSSL-non-blocking-epoll-hanging-on-data-receiving-tp66355p66398.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
On 27/05/16 16:20, counterpoint wrote:
> Thanks Matt, good points. Not easy to implement though!
>
> In the problem case, my code is the server (it is a proxy), and the standard
> MariaDB command line client is the client. Yes, it does look as if
> everything is happening as it should, except
Thanks Matt, good points. Not easy to implement though!
In the problem case, my code is the server (it is a proxy), and the standard
MariaDB command line client is the client. Yes, it does look as if
everything is happening as it should, except that the process stops before
all the data has been
On 27/05/16 15:51, counterpoint wrote:
> Seems to always be zero, Matt, as it should be. This gives some idea of
> what is going on:
>
> Breakpoint 4, dcb_basic_read_SSL (dcb=0x7fffdc0158d0,
> nsingleread=0x7fff86fc) at /root/MaxScale/server/core/dcb.c:1218
> 1218switch
Seems to always be zero, Matt, as it should be. This gives some idea of what
is going on:
Breakpoint 4, dcb_basic_read_SSL (dcb=0x7fffdc0158d0,
nsingleread=0x7fff86fc) at /root/MaxScale/server/core/dcb.c:12181218
switch (SSL_get_error(dcb->ssl, *nsingleread))$352 = 16384Breakpoint
On 27/05/16 13:23, counterpoint wrote:
> Thanks for the comments, Matt.
>
>> read_ahead and SSL_pending() do not play nicely together unfortunately.
>> See the master (1.1.0) version of the SSL_pending() documentation which
>> discusses this issue and introduced the new function
Thanks for the comments, Matt.
> read_ahead and SSL_pending() do not play nicely together unfortunately.
> See the master (1.1.0) version of the SSL_pending() documentation which
> discusses this issue and introduced the new function SSL_has_pending()
> which addresses it:
>
On 27/05/16 07:32, counterpoint wrote:
> Hmm, some progress, but still puzzled. When my code is acting as the client,
> it seems that the problem can be overcome by calling SSL_set_read_ahead with
> a zero parameter, to turn off reading ahead. This is done just before
> calling SSL_connect. The
Hmm, some progress, but still puzzled. When my code is acting as the client,
it seems that the problem can be overcome by calling SSL_set_read_ahead with
a zero parameter, to turn off reading ahead. This is done just before
calling SSL_connect. The application now seems able to read megabytes of
I'm working on a proxy application that uses non-blocking socket I/O. A
limited number of threads use epoll to handle events, and each thread runs
process bound as much as it can.
The SSL implementation uses read_SSL and write_SSL, with logic to handle
"read wants write" etc.
When reading,
13 matches
Mail list logo
