On Mon, Jan 14, 2019 at 03:31:36PM -0500, Viktor Dukhovni wrote:
> > to not depend on this "accident", right?
>
> The correct form would be:
>
> $ /usr/local/bin/openssl ciphers -s tls1_3 | tr ':' '\n'
> TLS_AES_256_GCM_SHA384
> TLS_CHACHA20_POLY1305_SHA256
> TLS_AES_128_GCM_SHA2
On Mon, Jan 14, 2019 at 02:18:18PM +0100, Yann Ylavic wrote:
> I suppose one can always, e.g.:
>
> $ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering
>
> to not depend on this "accident", right?
The correct form would be:
$ /usr/local/bin/openssl ciphers -s tls1_3
Thanks @Michael. I read up on TIME_WAIT Assassination.
I think that sort of thing may have been the problem I was trying to fix.
After an "error" disconnection, the customer was reporting that their client
could not re-connect. I had trouble getting good traces out of the customer,
but I suspect t
On Mon, Jan 14, 2019 at 5:18 AM Yann Ylavic wrote:
> I suppose one can always, e.g.:
>
> $ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering
>
> to not depend on this "accident", right?
No, `ciphers` gives you the TLS cipher suites that are enabled, it
doesn't give all.
On Mon, Jan 14, 2019 at 1:09 PM Matt Caswell wrote:
>
> This works more "by accident". There is no ciphersuite alias called "TLSv1.3",
> so using it as above results in no ciphersuites matched. Since the TLSv1.3
> ciphersuites are on by default anyway that's all that you get back.
OK, thanks for
Hi
I have a 64bit windows application that uses openSSL, and I am using the
indy distribution from https://indy.fulgan.com/SSL/. This makes the file
names of the openssl dlls libeay32.dll and ssleay32.dll (even though they
are 64bit). Other distributions use other names (libcrypto-XX-x64.dll etc)
On 13/01/2019 21:11, Yann Ylavic wrote:
> On Tue, Jan 8, 2019 at 11:24 PM Sam Roberts wrote:
>>
>> node.js has an API that lists all the cipher suite names that can be
>> validly passed to set_cipher_list(), but I don't see how to get them
>> for TLS1.3 to list the valid inputs to set_cipher_su
On 13/01/2019 04:36, Ananthu Unnikrishnan wrote:
> Hi Matt,
>
> Thanks a lot for the response. The alternative method to resume
> job
> operation is a good one.
>
> I need some more clarifications regarding the async job operation.
> Please help.
>