Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On 1/17/2019 5:33 PM, Jordan Brown wrote: > Am I missing something? Seems I was. Thanks, all. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Thu, Jan 17, 2019 at 5:40 PM Jordan Brown wrote: > On 1/14/2019 4:09 AM, 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. > > > From what you say, and based on experimentation, it seems like the TLSv1.3 > ciphersuites are enabled even if you explicitly say to disable them. 3 of 5 TLS1.3 cipher suites are enabled by default I'm having to reverse engineer the intention, but I think that it was thought that the cipher list API with its mini language was too complex, so there is a new API for setting TLS1.3 cipher suites, _set_ciphersuites(), and for openssl cipher, you can pass args to it using the -ciphersuites option. You can also pass an empty string "" to clear them. Another reason for the second API and the odd interactions between them may be that there are existing apps calling the set_cipher_list() APIs.. if their arg applied to TLS1.3 ciphers, it would always clear them, so existing apps wouldn't use TLS1.3 even though they were theoretically capable. Anyhow, you are seeing that seperation of two APIs, each configuring suites for different protocol familes (pre/post TLS1.3). -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Friday, 18 January 2019 02:33:20 CET Jordan Brown wrote: > On 1/14/2019 4:09 AM, 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. > > From what you say, and based on experimentation, it seems like the > TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them. > > $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384 > *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] > > $ openssl ciphers AES:-SHA384 > *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] > > That doesn't seem right. Am I missing something? see man 1 ciphers section "TLS v1.3 cipher suites" specifies all ciphers that are supported for TLS 1.3 while -ciphersuites is used to change which are enabled -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Fri, Jan 18, 2019 at 01:33:20AM +, Jordan Brown wrote:
> On 1/14/2019 4:09 AM, 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.
>
>
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.
>
> $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
>
> $ openssl ciphers AES:-SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
>
> That doesn't seem right. Am I missing something?
Presumably. The TLS 1.3 ciphersuites are entirely separate from the traditional
cipher list:
-ciphersuites val
Sets the list of TLSv1.3 ciphersuites. This list will be combined with
any TLSv1.2 and below ciphersuites that have been configured. The format
for this list is a simple colon (":") separated list of TLSv1.3
ciphersuite names. By default this value is:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA25
-Ben
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
Hi, V Fri, 18 Jan 2019 01:33:20 + "Jordan Brown" napsáno: > On 1/14/2019 4:09 AM, 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. > > > From what you say, and based on experimentation, it seems like the > TLSv1.3 ciphersuites are enabled even if you explicitly say to > disable them. > > $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384 > *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] > > $ openssl ciphers AES:-SHA384 > *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] > > That doesn't seem right. Am I missing something? Yes. TLS 1.3 ciphers are configured differently, you need to use the -ciphersuites option. See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html Try # openssl ciphers -v -ciphersuites '' SHA384 Vita -- Vítězslav Čížek Emergency Update Team (EMU) "Whilst you sleep, we're probably saving the universe." -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On 1/14/2019 4:09 AM, 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. >From what you say, and based on experimentation, it seems like the TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them. $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384 *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] $ openssl ciphers AES:-SHA384 *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...] That doesn't seem right. Am I missing something? -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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_SHA256 Sorry, that shoulld "-tls1_3" not "tls1_3". > This shows which ciphers are applicable to TLS 1.3. If TLS 1.4 ever > appears, and supports both TLS 1.3 and TLS 1.4 ciphers, then: > > $ /usr/local/bin/openssl ciphers -s tls1_4 | tr ':' '\n' And likewise here: "-tls1_4" (if that comes to pass). -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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 | tr ':' '\n'
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
This shows which ciphers are applicable to TLS 1.3. If TLS 1.4 ever
appears, and supports both TLS 1.3 and TLS 1.4 ciphers, then:
$ /usr/local/bin/openssl ciphers -s tls1_4 | tr ':' '\n'
would show both, as both would be applicable.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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.
As you saw with both of your `ciphers` commands, they are printing the
3 TLS1.3 cipher suites that are enabled by default, but OpenSSL
supports 5 TLS1.3 cipher suites, two are missing from the output.
Cheers,
Sam
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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 the explanation.
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?
Regards,
Yann.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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_suites(). > > FWIW, the below works for me: > > $ openssl ciphers -v TLSv1.3 > TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD > TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any > Enc=CHACHA20/POLY1305(256) Mac=AEAD > TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD 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. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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_suites(). FWIW, the below works for me: $ openssl ciphers -v TLSv1.3 TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD Regards, Yann. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Wed 2019-01-09 04:16:05 +, Jordan Brown wrote: > On 1/8/2019 7:44 PM, Viktor Dukhovni wrote: >> You could just provide a free-form emergency string parameter that >> users are advised to not change unless some major advance makes it >> necessary. At that time, advice can be published as to what the >> override setting should be. > > That doesn't sound like a 21st century user interface. a 21st century interface is: upgrade your software to the new patch level that avoids the known flaws. --dkg -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On 1/8/2019 8:21 PM, Viktor Dukhovni wrote: > How do you plan to offer a built-in menu of algorithms that have not > yet been added to OpenSSL? I'm a bit confused as to why we would need to - if the underlying OpenSSL doesn't support a particular algorithm, then there's no need to disable it. The ideal would be that we ask OpenSSL what algorithms (and protocol versions) it supports, and we export that list to the user. However, practically we've found that we couldn't do that even with TLS1.2, because (a) "openssl ciphers" (and the underlying APIs) report PSK-* and other algorithms we don't intend to support, and (b) the underlying OpenSSL includes support for algorithms that our security policies don't allow us to support. Also, there's the question of whether a particular algorithm or protocol version is supported but disabled by default, or enabled by default. For instance, today we support TLS 1.0, 1.1, and 1.2, but 1.0 is disabled by default. That's a policy question that OpenSSL can't help us with. > And if users are better off leaving the list alone, why encourage that > with a fancy UI? That's a good question, but at the same time we have a high-level UI policy that we don't offer "non-fancy" UIs. >> However, as I think about it, I remember that we already need a >> softcoded list of algorithms, to avoid offering (e.g.) the PSK >> algorithms. > In TLS 1.3, the handshake parameters are configured separately from > the cipherlist. The use of (non-resumption) PSKs requires callbacks, > so they're never enabled out of the box. > >> It sounds like TLS 1.3 will need the same. > Actually, it won't, nor did earlier versions, the ciphers were > listed by "openssl ciphers -v", but they can't get activated without > application support. Right... we found that when we blindly asked for the cipher list, it included ciphers that weren't actually operable because we didn't have the associated application support. We had hoped to be able to use relatively simple rules to determine the list of allowable ciphers, but then found that we needed much more complex rules than were desirable. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On 1/8/2019 7:44 PM, Viktor Dukhovni wrote: > So what you get is AESGCM with SHA2 or CHACHA20 with Poly1305. > Breaks in either would be dramatic advances in cryptanalysis. History shows that protocols, algorithms, and implementations all have flaws. We assume that flaws will be discovered and design so that our customers can work around them. > You could just provide a free-form emergency string parameter that > users are advised to not change unless some major advance makes it > necessary. At that time, advice can be published as to what the > override setting should be. That doesn't sound like a 21st century user interface. However, as I think about it, I remember that we already need a softcoded list of algorithms, to avoid offering (e.g.) the PSK algorithms. It sounds like TLS 1.3 will need the same. That's unfortunate - I'd really like to treat the crypto subsystem as a black box - but completely survivable. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Wed, Jan 09, 2019 at 04:16:05AM +, Jordan Brown wrote: > > You could just provide a free-form emergency string parameter that > > users are advised to not change unless some major advance makes it > > necessary. At that time, advice can be published as to what the > > override setting should be. > > That doesn't sound like a 21st century user interface. How do you plan to offer a built-in menu of algorithms that have not yet been added to OpenSSL? And if users are better off leaving the list alone, why encourage that with a fancy UI? > However, as I think about it, I remember that we already need a > softcoded list of algorithms, to avoid offering (e.g.) the PSK > algorithms. In TLS 1.3, the handshake parameters are configured separately from the cipherlist. The use of (non-resumption) PSKs requires callbacks, so they're never enabled out of the box. > It sounds like TLS 1.3 will need the same. Actually, it won't, nor did earlier versions, the ciphers were listed by "openssl ciphers -v", but they can't get activated without application support. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Tue, Jan 8, 2019 at 7:10 PM Viktor Dukhovni wrote: > On Tue, Jan 08, 2019 at 02:23:27PM -0800, 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_suites(). > > The intent is that you SHOULD NOT generally customize the list. There are many reasons users might want to customize it, writing unit tests for example, to ensure that their software interoperates with clients that only support some of the ciphers. For the same reasons OpenSSL allows the cipher suite to be customized, Node.js exposes this capability to its users, along with a recommendation to not do this casually. The Node.js default will, of course, be the same as OpenSSL for TLS1.3. Anyhow, my question isn't about how to call set_cipher_suites(), its about how to get the list of ciphers supported by OpenSSL for TLS1.3 in such a way that when new ciphers become available, they are returned. I realized the link to the API I provided, not that its that relevant, was to my local dev filesystem, oops! The API is https://nodejs.org/api/crypto.html#crypto_crypto_getciphers. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Wed, Jan 09, 2019 at 03:27:44AM +, Jordan Brown wrote: > > Is there a good reason to want to change or freeze them at this time? > > Our products allow the user to enable and disable individual ciphers, to > allow for both customer policy (e.g. a customer-specific approved-cipher > list) and for the possibility that one is found to be vulnerable. They > are "quite safe" today... but what about tomorrow? The ciphersuites in TLS 1.3, are just the symmetric bulk encryption algorithms coupled with a PRF (HKDF). So what you get is AESGCM with SHA2 or CHACHA20 with Poly1305. Breaks in either would be dramatic advances in cryptanalysis. While protocol designs are brittle, and public key algorithms are potentially vulnerable to attack by future universal quantum computers, the basic building blocks of modern symmetric cryptography are looking quite robust for the forseeable future. We're no longer dealing with 1970's or 1980's designs like DES and RC4. Yes, they could perhaps be broken, but there's precious little evidence of that happening any time soon. You could just provide a free-form emergency string parameter that users are advised to not change unless some major advance makes it necessary. At that time, advice can be published as to what the override setting should be. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On 1/8/2019 7:10 PM, Viktor Dukhovni wrote: > The intent is that you SHOULD NOT generally customize the list. All > the ciphers in question are quite safe, and if the default changes, > you should probably go with that, rather than a frozen time-capsule > version. > > Is there a good reason to want to change or freeze them at this time? > Our products allow the user to enable and disable individual ciphers, to allow for both customer policy (e.g. a customer-specific approved-cipher list) and for the possibility that one is found to be vulnerable. They are "quite safe" today... but what about tomorrow? -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
I would expect that smartphone clients might want to prioritize CHACHA over AES, but I don't think Node cares about that environment. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
On Tue, Jan 08, 2019 at 02:23:27PM -0800, 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_suites(). The intent is that you SHOULD NOT generally customize the list. All the ciphers in question are quite safe, and if the default changes, you should probably go with that, rather than a frozen time-capsule version. Is there a good reason to want to change or freeze them at this time? -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] is there an API to list all the TLS 1.3 cipher suite names?
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_suites(). The openssl ciphers CLI doesn't seem able to do this either. https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html lists the 1.3 suites, there aren't many, so I could just hard-code them into our API, but that's pretty fragile, I assume there will be a few more, eventually. Or, I guess I could just link to the openssl man page online for TLS1.3, and tell people that file:///home/sam/w/core/node/out/doc/api/crypto.html#crypto_crypto_getciphers only works for TLS1.2 and below. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
