On 26/01/2022 11:27, Jan Lana wrote:
Hi,
When I run
openssl ciphers -v -provider fips | grep TLS_CHACHA20_POLY1305_SHA256
it shows this non complain cipher is available.
This looks correct behaviour to me. Your openssl.cnf file is explicitly
activating the default provider. The
Hi,
When I run
openssl ciphers -v -provider fips | grep TLS_CHACHA20_POLY1305_SHA256
it shows this non complain cipher is available. To add '-propquery
fips=yes' argument does not help. IMHO it is not correct behavior.
I have the default and fips providers enabled in o
> Look at
> https://testssl.sh/
> That is an openssl wrapper which enumerates ciphers and protocols ( and a
> whole lot more)
Nice tool, I didn’t know it yet. I was already recommended to me by Michael
Wojcik in his first reply, but thanks nevertheless for the link.
Matthias
Look at https://testssl.sh/
That is an openssl wrapper which enumerates ciphers and protocols ( and
a whole lot more)
Hexcode Cipher Suite Name
(OpenSSL) KeyExch. Encryption Bits Cipher Suite Name
(IANA/RFC
o and see what is the next cipher that
server selects, repeat until connection rejected.
That's not simple to do in bash (for a way to do it look at
mozilla/cipherscan)
The big problem is that this approach works only for ciphers supported and
enabled in openssl. If a cipher is unsupported
> From: Dr. Matthias St. Pierre
> Sent: Monday, 6 December, 2021 07:53
> To: Michael Wojcik ; openssl-
>
>
> > "Comparable elegant" is underspecified.
>
> (I guess, "Comparably elegant" would have been grammatically more
> correct.)
I just meant that elegance is in the eye of the beholder.
Ma
> "Comparable elegant" is underspecified.
(I guess, "Comparably elegant" would have been grammatically more correct.)
> Perhaps try testssl.sh (https://testssl.sh/)? It has various options for
> reducing the number and types of tests it runs. We've used it for
> profiling internal TLS-enabled
From: openssl-users On Behalf Of Dr.
Matthias St. Pierre
Sent: Monday, 6 December, 2021 07:12
> today I learned that nmap has a nice feature to enumerate the protocol
> versions and cipher
> suites supported by the peer (see below).
> Is there a comparable elegant way to obtain the same result
Hi all,
today I learned that nmap has a nice feature to enumerate the protocol versions
and cipher suites supported by the peer (see below).
Is there a comparable elegant way to obtain the same results using the `openssl
s_client` tool?
Matthias
--
$ nmap -script ssl-enum-ciphers -p 443
"openssl ciphers" will show you the correct names which in this case is
DHE-RSA-AES128-GCM-SHA256
On Wed, 2021-11-17 at 16:25 +0800, M K Saravanan wrote:
> Hi,
>
> Do I need to do any config to enable DHE based ciphers in openssl for
> command line usage?
>
>
gt; >
> >
> > On 17/11/2021 08:25, M K Saravanan wrote:
> > > Hi,
> > >
> > > Do I need to do any config to enable DHE based ciphers in openssl for
> > > command line usage?
> > >
> > > $ openssl s_client -cipher 'DHE_RSA_WITH_
Thanks Matt.
I am extremely for making such a basic stupid mistake.
On Wed, 17 Nov 2021 at 18:33, Matt Caswell wrote:
>
>
>
> On 17/11/2021 08:25, M K Saravanan wrote:
> > Hi,
> >
> > Do I need to do any config to enable DHE based ciphers in openssl for
> > c
On 17/11/2021 08:25, M K Saravanan wrote:
Hi,
Do I need to do any config to enable DHE based ciphers in openssl for
command line usage?
$ openssl s_client -cipher 'DHE_RSA_WITH_AES_128_GCM_SHA256' -connect
10.10.16.100:443
You have the wrong name for this ciphersuite. OpenSSL us
Hi,
Do I need to do any config to enable DHE based ciphers in openssl for
command line usage?
$ openssl s_client -cipher 'DHE_RSA_WITH_AES_128_GCM_SHA256' -connect
10.10.16.100:443
Error with command: "-cipher DHE_RSA_WITH_AES_128_GCM_SHA256"
13977599845689
On Tue, Jul 20, 2021 at 11:47:25PM -0300, Webstrucs wrote:
> I needed to generate a cipher to insert as a parameter in a python function
> context = ssl.SSLContext.set_ciphers(ciphers), what I'm finding strange
> would be the generated size. My question would be if I should inser
Good luck to us all. I am João openssl's apprentice and below I describe my
doubts:
I needed to generate a cipher to insert as a parameter in a python function
context = ssl.SSLContext.set_ciphers(ciphers), what I'm finding strange
would be the generated size. My question would be i
<https://www.openssl.org/docs/man1.0.2/man1/ciphers.html> and hence was
curious
Support for ChaCha20/Poly1305 was first added in OpenSSL 1.1.0 so they
are not listed in the 1.0.2 man pages you are referring to.
You will find these ciphers in the man pages for the current 1.1.1
versio
> Bonus question :-) I have a 2 more
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 and
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>
> I dont even find these listed on the man pages -
> https://www.openssl.org/docs/man1.0.2/man1/ciphers.html and hence was curious
https://www.openssl.org/new
t likely you are using a version of OpenSSL that does have support
>for these ciphersuites, but you are not seeing it in the "ciphers"
>output because of the above. You can get "ciphers" to display the
>standard name as well as the OpenSSL name using the command below:
On 10/05/2021 06:38, Mario Ds Briggs wrote:
In the openssl libs that i have installed on ubuntu/rhel/mac-os, i dont
find the following ciphers when i run 'openssl ciphers' command
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_
In the openssl libs that i have installed on ubuntu/rhel/mac-os, i dont find the following ciphers when i run 'openssl ciphers' command
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_
Wow!
I was unattentive :(
The leading minus before enable-weak-ssl-ciphers was the problem. Many
thanks Satyam!
On Mon, Oct 26, 2020 at 8:41 PM Satyam Mehrotra wrote:
> I think i have resolved it . if you use the following option and then do a
> make , the openssl binary don
Dear Satyam,
It looks like a compiler bug for me.
When configured via ./config -ggdb -O0 -enable-weak-ssl-ciphers, I get the
code working. The same happens when -O1 is in use.
When I either omit optimization (which implies -O3) or specify -O2, I get a
segfault.
On Mon, Oct 26, 2020 at 8:09 PM
Dear Dmitry,
The below is the process i have followed
- Downloaded the openssl-1.1.1h from the official OpenSSL site
- ./config -ggdb -enable-weak-ssl-ciphers
- make
- make install
- Execute openSSL command ( Looks like any openSSL command the binary
is
Dear Satyam,
Do I correctly understand that
- you built openssl-1.1.1h from scratch with -enable-weak-ssl-ciphers
- installed it
-run some command? Which one(s)? Initially, you were speaking about
'ciphers', but the stack trace is from the 'ca'.
On Mon, Oct 26, 2020 at 7:2
Segmentation fault is not seen if i don't compile* ./config with*
*-enable-weak-ssl-ciphers.*
Is it something I am missing or some more options needs to be provided to
./config ?
Thanks
Satyam
On Mon, 26 Oct 2020 at 20:21, Dmitry Belyavsky wrote:
> It has nothing to do with the
It has nothing to do with the ciphers command...
On Mon, Oct 26, 2020 at 5:18 PM Satyam Mehrotra wrote:
> Dear Dmitry,
>
> >>Are the /usr/local/lib64/libssl.so.1.1 and
> /usr/local/lib64/libcrypto.so.1.1 the same libraries that were built by you?
> Yes, they are same
>
a backtrace.
>
> On Mon, Oct 26, 2020 at 4:54 PM Satyam Mehrotra
> wrote:
>
>> Dear Dmitry,
>>
>> As suggested i have build the openssl with -ggdb ( ./config -ggdb
>> -enable-weak-ssl-ciphers ) and after building i did make install as well.
>>
>>
nssl with -ggdb ( ./config -ggdb
> -enable-weak-ssl-ciphers ) and after building i did make install as well.
>
> The strace output is as below
> ==
>
> *strace ./openssl*
>
>
> execve("./openssl", ["./openss
Dear Dmitry,
As suggested i have build the openssl with -ggdb ( ./config -ggdb
-enable-weak-ssl-ciphers ) and after building i did make install as well.
The strace output is as below
==
*strace ./openssl*
execve("./openssl", ["./openssl"],
lrwxrwxrwx. 1 root root 13 Oct 26 12:58 libssl.so ->
> libssl.so.1.1
>
>drwxr-xr-x. 2 root root 39 Oct 26 12:58 engines-1.1
>
>
>
>*openssl ciphers -V*
>
> * Segmentation fault*
>
>
> *gdb ./openssl core.3370 *
>
>
> GNU gd
*openssl ciphers -V*
* Segmentation fault*
*gdb ./openssl core.3370 *
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you
compiling it with
> *-enable-weak-ssl-ciphers
> ,* also what is the location of the crash file.
>
> Thanks
> Satyam
>
> On Sun, 25 Oct 2020 at 12:57, Satyam Mehrotra wrote:
>
>> Hello Everyone,
>>
>> I have just joined the openssl users community.
>>
Hello,
Any Suggestions on how this can be done ?
why openssl binary is crashing if i am compiling it with
*-enable-weak-ssl-ciphers
,* also what is the location of the crash file.
Thanks
Satyam
On Sun, 25 Oct 2020 at 12:57, Satyam Mehrotra wrote:
> Hello Everyone,
>
> I have just j
Hello Everyone,
I have just joined the openssl users community.
My requirement is to have the SSLv3 and weak ciphers enable with openssl
installation .
I have a query regarding enabling SSLv3 protocol and weak ciphers with
openssl-1.1.1h installation
I have followed the below steps
1
On 8/13/20 3:03 PM, Thomas Dwyer III wrote:
> I think you want "openssl ciphers" rather than "openssl enc -ciphers". Per
> the "enc" man page:
>
> The enc program does not support authenticated encryption modes like
> CCM and GCM,
e that to a CHACHA20 variant.
As listed by
https://www.php.net/manual/en/function.openssl-get-cipher-methods.php
the list of php-supported openssl ciphers includes
[92] => chacha20
[93] => chacha20-poly1305
double checking available encryption ciphers @ ope
t -connect localhost:18010 -cert clnt.crt \
-key test.key -CAfile testca.crt -debug \
-cipher 'COMPLEMENTOFALL:eNULL' -dtls1_2
NULL ciphers work fine with OpenSSL 1.0.2g.
With OpenSSL 1.1.1g the handshake fails on the server side with
140295725053248:error:14102438:SSL routines:dtls1_read
ect localhost:18010 -cert clnt.crt \
> -key test.key -CAfile testca.crt -debug \
> -cipher 'COMPLEMENTOFALL:eNULL' -dtls1_2
>
> NULL ciphers work fine with OpenSSL 1.0.2g.
>
> With OpenSSL 1.1.1g the handshake fails on the server side with
> 140295725053248:error:1410
MENTOFALL:eNULL' -dtls1_2
NULL ciphers work fine with OpenSSL 1.0.2g.
With OpenSSL 1.1.1g the handshake fails on the server side with
140295725053248:error:14102438:SSL routines:dtls1_read_bytes:tlsv1 \
alert internal error:../ssl/record/rec_layer_d1.c:611:SSL alert number \
80
Even on OpenSSL 1.1
*Requirement : * The cipher suites(PSK-AES128-GCM-SHA256 and PSK-NULL-SHA256)
are needed to be set during the handshake process between client and server
in python(3.7) testframe using standard library ssl module(wrapper for
openssl). My understanding is that PSK and weak ciphers are not enabled
On 04/06/2020 00:39, Benjamin Kaduk via openssl-users wrote:
> only reports the TLS 1.3 ciphersuites and some SEED ciphers for an
> input of MEDIUM, and IIRC the SEED ciphers have been foisted off to the
> legacy provider and are not available by default.
Yes - this is exactly t
On Wed, Jun 03, 2020 at 07:05:32PM +0200, Claus Assmann wrote:
> Just curious: Why is the output of
> openssl ciphers MEDIUM
> "empty" for 3.0.0.a2?
There are no ciphers available by default that are at the MEDIUM
level (which, to be honest, does not make a huge amount of
Just curious: Why is the output of
openssl ciphers MEDIUM
"empty" for 3.0.0.a2?
Error in cipher list
00:00:00:00:error:SSL routines:SSL_CTX_set_cipher_list:no cipher
match:ssl/ssl_lib.c:2705:
Using 1.1.1 lists several, and at least
TLS_AES_128_GCM_SHA256
is also listed by
openss
feature.
This particular case was a bit frustrating to me because with OpenSSL
1.0.x, there is a much simpler way to check if particular ciphers can be
instantiated with the SSL_METHOD API exposed…
/* XX: Based on my reading of the SSL_METHOD API
* (
https://github.com/opens
te based on 3DES or
RC4 available, and fail otherwise.
> It was suggested that I should try EVP_get_ciphername().
The ciphers available via the EVP API are only indirectly related to the
ciphersuites available in libssl. If there are no 3DES based ciphers
available via EVP then there won't be a
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Daniel Lenski
> Sent: Saturday, May 23, 2020 17:24
>
> > Other than looping through all of the ciphers with SSL_get_ciphers()
> > right after this… is there a better way to check for 3DES/
> Other than looping through all of the ciphers with SSL_get_ciphers()
> right after this… is there a better way to check for 3DES/RC4 support
> right at startup, so we can give immediate feedback that connecting to
> such a server cannot succeed?
It was suggested that
ing to do is
SSL_CTX_set_cipher_list(ctx, "DEFAULT:+3DES:+RC4"). However, this
fails silently on subsequent connection if 3DES/RC4 support isn't
available.
Other than looping through all of the ciphers with SSL_get_ciphers()
right after this… is there a better way to check for 3DES/RC4
Nicola...my apologies for the typo...
From: openssl-users on behalf of Jason
Schultz
Sent: Friday, February 21, 2020 1:05 PM
To: Nicola Tuveri
Cc: openssl-users
Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL
Nicole-
This was very
way to test before
they have their own certificate, signed by a CA).
Thanks again.
From: Nicola Tuveri
Sent: Wednesday, February 19, 2020 9:42 PM
To: Jason Schultz
Cc: Kyle Hamilton ; openssl-users
Subject: Re: Questions about using Elliptic Curve ciphers in
s for your response. It does help, but at the same time it also
> raises questions and maybe conflicts with what I thought I was doing
> correct earlier in this thread. I'm talking mostly about where I landed in
> this post:
>
> https://www.mail-archive.com/openssl-users@openssl
l.org/msg87538.html
Re: Questions about using Elliptic Curve ciphers in
OpenSSL<https://www.mail-archive.com/openssl-users@openssl.org/msg87538.html>
Thank you for your response Thulasi, this helped. I'm posting this back to the
OpenSSL users list in case it helps anyone else, and in case anyon
oriparthi ; openssl-users <
> openssl-users@openssl.org>
> *Subject:* Re: Questions about using Elliptic Curve ciphers in OpenSSL
>
> Be aware that you just posted your certificate's private key, and thus you
> should regenerate a new keypair/certificate to use. Otherwise, an
using Elliptic Curve ciphers in OpenSSL
Be aware that you just posted your certificate's private key, and thus you
should regenerate a new keypair/certificate to use. Otherwise, anyone who can
manipulate traffic to your machine can execute a man-in-the-middle attack.
-Kyle H
On Fri, Feb 14, 2
!
From: Thulasi Goriparthi
mailto:thulasi.goripar...@gmail.com>>
Sent: Wednesday, February 12, 2020 8:29 AM
To: jetso...@hotmail.com<mailto:jetso...@hotmail.com>
mailto:jetso...@hotmail.com>>
Cc: rs...@akamai.com<mailto:rs...@akamai.com>
m
on from a client
> using ECDHE-ECDSA-AES256-GCM-SHA384.
>
> And yes, I think my main confusion was on what to do with the DH
> parameters file. I thought using ECDHE key exchange was similar to DSA with
> DH. With ECDHE, I don't need to read in a parameters file at all.
>
e let me know, otherwise, thanks for all
the help!
From: Thulasi Goriparthi
Sent: Wednesday, February 12, 2020 8:29 AM
To: jetso...@hotmail.com
Cc: rs...@akamai.com
Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL
To clarify further, EC keys can be gen
I believe you just load your ECDSA cert and the other stuff – Dhparams!! – is
not needed.
Rich-
Thanks for your reply. At this point I'm 99% sure I have ECDH with RSA working.
My question in the previous post was just to confirm. But I have my RSA cert
and key pair, and a client can successfully connect to my server using
ECDHE_RSA* ciphers.
My questions are more related to
The first thing I would suggest is to separate ECDH, the session key exchange,
from ECDSA, the signature. Try to make ECDH with RSA work. Then just load
your ECDSA cert; you can load one cert of each type (RSA DSA) and the runtime
will figure out what to do, depending on what the client offers
Anyone have any advice on Elliptic Curve?
Thanks in advance.
From: openssl-users on behalf of Jason
Schultz
Sent: Friday, February 7, 2020 2:58 AM
To: openssl-users@openssl.org
Subject: Questions about using Elliptic Curve ciphers in OpenSSL
I’m somewhat
I’m somewhat confused as to what I need to do to use ECDHE ciphers
(ECDHE-ECDSA-AES128-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, etc). I’m hoping
this list can help, or at least point me to a good tutorial somewhere. A lot of
the information I’ve looked at is from the following links:
https
On 7/22/19, 3:38 PM, "Richard Levitte" wrote:
> > Turned out the failure was my misconfiguration - but the "config"
> > man page doesn't seem to describe the *exact* order of the
> > statements/sections.
>
> It does, but perhaps not in a way you expected.
:-)
> So the "o
On Mon, 22 Jul 2019 21:17:01 +0200,
Blumenthal, Uri - 0553 - MITLL wrote:
>
> Turned out the failure was my misconfiguration - but the "config"
> man page doesn't seem to describe the *exact* order of the
> statements/sections.
It does, but perhaps not in a way you expected. Here's a paragraph
f
st.log
dgst: Unrecognized flag md_gost94
dgst: Use -help for summary.
$ openssl dgst -engine gost -md_gost94 ~/LastTest.log
engine "gost" set.
md_gost94(/Users/ur20980/LastTest.log)=
e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
$
Second - even
Pro-A-ParamSet
> init = 1
> #
>
> Note, whether the above has "init = 1" or not, does not alter the outcome.
>
> Engine in question is "gost".
>
> First, the engine does not load automatically/dynamically. For "openssl
> dgst"
lp for summary.
$ openssl dgst -engine gost -md_gost94 ~/LastTest.log
engine "gost" set.
md_gost94(/Users/ur20980/LastTest.log)=
e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
$
Second - even when I explicitly specify the engine, "openssl speed" refuses to
recognize the
hms it
> provides, are not available:
>
> $ openssl dgst -md_gost94 ~/LastTest.log
> dgst: Unrecognized flag md_gost94
> dgst: Use -help for summary.
> $ openssl dgst -engine gost -md_gost94 ~/LastTest.log
> engine "gost" set.
> md_gost94(/Users/ur20980/LastTest.log)=
> e
ond - even when I explicitly specify the engine, "openssl speed" refuses to
recognize the ciphers provided by it, though "openssl enc" shows that it can
access them:
$ openssl speed -engine gost -evp gost89-cbc
speed: gost89-cbc is an unknown cipher or digest
$ openssl enc -eng
lp for summary.
> $ openssl dgst -engine gost -md_gost94 ~/LastTest.log
> engine "gost" set.
> md_gost94(/Users/ur20980/LastTest.log)=
> e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
> $
>
> Second - even when I explicitly specify the engine, "openssl speed&qu
am discounting his report of success. The full set of TLS 1.3
> ciphers is enabled by default. If he did not use the -ciphersuites
> option, he was overriding just the 1.2 code points, and somehow
> managed to ultimately list just the TLS 1.3 code points. He
> also had a typo in t
On 7/20/19 8:17 AM, Viktor Dukhovni wrote:
On Sat, Jul 20, 2019 at 07:35:49AM -0700, PGNet Dev wrote:
Checking cipherlist for just TLSv1.3 ciphers FAILs here,
openssl ciphers -stdname -s -V
'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-S
On Sat, Jul 20, 2019 at 07:35:49AM -0700, PGNet Dev wrote:
> >> Checking cipherlist for just TLSv1.3 ciphers FAILs here,
> >>
> >>openssl ciphers -stdname -s -V
> >> 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA
Hi,
On 7/20/19 7:28 AM, Viktor Dukhovni wrote:
> On Fri, Jul 19, 2019 at 10:38:19AM -0700, PGNet Dev wrote:
>
>> I suspect I've misunderstood usage of TLSv1.3 @
>>
>> https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/
>>
>> Checking ciphe
On Fri, Jul 19, 2019 at 10:38:19AM -0700, PGNet Dev wrote:
> I suspect I've misunderstood usage of TLSv1.3 @
>
> https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/
>
> Checking cipherlist for just TLSv1.3 ciphers FAILs here,
>
> openssl ciphers -stdname
>>> Configuration file difference?
>
>> which config file are you referring to?
>
> The default OpenSSL configuration file. openssl.cnf, in the directory
> displayed by "openssl version -d". But I can't think offhand of anything in
> the configuration file that I'd expect to have this sort of
> Works for me:
> $ openssl ciphers -stdname -s -V
> 'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384'
simplifying to build defaults
./config -v \
--prefix=/usr/local/ssl-test \
--openssldir=/usr/local/ssl-test
[Apologies if the formatting here is a little screwy. For the moment I have to
use Outlook Web Interface, which is even more problematic than the standalone
Outlook client.]
> > Different OpenSSL release?
> yes
> openssl version
> OpenSSL 1.1.1c 28 May 2019
Eh, that's probably it.
> Works for me:
heh. of COURSE it does!
sanity check here,
openssl ciphers -stdname -s -V
'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384'
Error in cipher list
140042399306176:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_li
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> PGNet Dev
> Sent: Friday, July 19, 2019 11:38
>
> Checking cipherlist for just TLSv1.3 ciphers FAILs here,
>
> openssl ciphers -stdname -s -V 'TTLS13-CHACHA20-POLY1305-
> SHA256:T
md_gost94
dgst: Use -help for summary.
$ openssl dgst -engine gost -md_gost94 ~/LastTest.log
engine "gost" set.
md_gost94(/Users/ur20980/LastTest.log)=
e82e6e515c86851498eac606722b50b724b1f95952d4edb7202029f127751816
$
Second - even when I explicitly specify the engine, "openssl speed&q
I suspect I've misunderstood usage of TLSv1.3 @
https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/
Checking cipherlist for just TLSv1.3 ciphers FAILs here,
openssl ciphers -stdname -s -V
'TTLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-
;;
even the webserver config check FAILs,
nginxconfcheck
TLS13-AES-128-GCM-SHA256") failed (SSL: error:1410D0B9:SSL
routines:SSL_CTX_set_cipher_list:no cipher match)
nginx: configuration file /usr/local/etc/nginx/nginx.conf test
failed
and the server fails to st
On 7/10/19 1:10 AM, shiva kumar wrote:
Hi,
How to List the ssl3 ciphers in openssl1.1.1
The command "openssl ciphers -ssl3" is not working. Please help me
jupiter # /usr/local/bin/openssl version
OpenSSL 1.1.1c 28 May 2019
jupiter # /usr/local/bin/openssl ciphers -help
Usag
ows,
> openssl ciphers [-help] [-s] [-v] [-V] [-ssl3] [-tls1] [-tls1_1] [-tls1_2]
> [-tls1_3] [-s] [-psk] [-srp] [-stdname] [-convert name] [-ciphersuites val]
> [cipherlist]
>
> but, in the command line when I list the options with help command, it is not
> showing ssl
HI,
In OpenSSL 1.1.1 documentation it is mentioned as -ssl3 option is there as
follows,
*openssl* *ciphers* [*-help*] [*-s*] [*-v*] [*-V*] [*-ssl3*] [*-tls1*] [
*-tls1_1*] [*-tls1_2*] [*-tls1_3*] [*-s*] [*-psk*] [*-srp*]
[*-stdname*] [*-convert
name*] [*-ciphersuites val*] [*cipherlist*]
but, in
Hi,
How to List the ssl3 ciphers in openssl1.1.1
The command "openssl ciphers -ssl3" is not working. Please help me
Thanks and Regards
Shivakumar
--
*With Best Regards*
*Shivakumar S*
On 18/06/2019 10:13, Alexander Gryanko wrote:
> Hello,
>
> I'm looking for the way to do something like SSL_CTX_set_alpn_select_cb but
> for
> ciphers and ssl/tls protocol version. As I see ssl_choose_server_version and
> ssl3_choose_cipher
Hello,
I'm looking for the way to do something like SSL_CTX_set_alpn_select_cb but
for ciphers and ssl/tls protocol version. As I see
ssl_choose_server_version and ssl3_choose_cipher has no any callbacks in
tls_early_post_process_client_hello. Is there any way to disable protocols
for some
are configured separately.
On 11/04/2019 00:06, Michael Richardson wrote:
> I think that those are the ones that constrained devices prefer,
> such as ECDHE-ECDSA-AES128-CCM8?
> So is there a way to validate that they are available, that there were
> compiled in?
You can get "open
Benjamin Kaduk via openssl-users wrote:
>> Very odd. I thought that there were more at one point.
> The ones with truncated (8-byte) authentication tag are not intended
> for general use and don't make it into the default list.
I think that those are the ones that constrained device
On Wed, 10 Apr 2019 at 17:25, Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:
> On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
>
> > Very odd. I thought that there were more at one point.
>
> The ones with truncated (8-byte) authentication tag are not intended
The ones with truncated (8-byte) authentication tag are not intended for
general use and don't make it into the default list.
There must be a Configuration option in 10-main.conf to enable them also?
Dennis
On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
> >Hi All,
> >
> >I haven't found a way to list the supported openssl ciphers from the
> >command line (i.e. get the list of potential values for -ciphersuites)
On 10/04/2019 17:13, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
>> Hi All,
>>
>> I haven't found a way to list the supported openssl ciphers from the command
>> line (i.e. get the list of potential values for -ciphersuites). I understand
&g
On 4/10/19 7:37 AM, Richard Moore wrote:
Hi All,
I haven't found a way to list the supported openssl ciphers from the
command line (i.e. get the list of potential values for -ciphersuites).
I understand that currently there are only 5 options however this could
change over time, so I w
Hi All,
I haven't found a way to list the supported openssl ciphers from the
command line (i.e. get the list of potential values for -ciphersuites). I
understand that currently there are only 5 options however this could
change over time, so I wanted to avoid hard coding the list in a scrip
On 14/02/2019 16:42, Patrice Guérin wrote:
> Hello,
>
> I have two questions :
>
> * I use OBJ_NAME_do_all_sorted() with OBJ_NAME_TYPE_CIPHER_METH to get the
> list of supported cipher methods
> Is there a difference between lowercase and uppercase names ?
> I've noticed that som
Hello,
I have two questions :
* I use OBJ_NAME_do_all_sorted() with OBJ_NAME_TYPE_CIPHER_METH to
get the list of supported cipher methods
Is there a difference between lowercase and uppercase names ?
I've noticed that some do not have uppercase name (ex. aes-128-ccm)
Is there a pre
1 - 100 of 555 matches
Mail list logo