Re: RFC 7250 raw public keys?
On Wed, Jul 08, 2020 at 02:24:47PM -0400, Felipe Gasper wrote: > > This is also supported in Postfix, just don't authenticate > > the client cert at all (no PKI), grab the key digest and > > use it directly for access control. > > Wouldn’t there need to be a shared secret, though, or some other way > for the server to have some influence on the randomness of what the > client’s private key signs? (I don’t know TLS well enough to comment > on whether that happens in an ordinary TLS handshake, but I assume it > does?) TLS takes care of that: https://tools.ietf.org/html/rfc5246#section-7.4.8 https://tools.ietf.org/html/rfc8446#section-4.4.3 In particular, the client and server random values are included, as well as any ephemeral public values in DH or ECDH key exchange. -- Viktor.
Re: RFC 7250 raw public keys?
> On Jul 8, 2020, at 1:51 PM, Viktor Dukhovni > wrote: > > On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote: > >> What I’m looking for is a way to authenticate a user over TLS in >> essentially the same manner that SSH’s handshake uses, where a >> signature of a shared secret validates the public key, which is on a >> preconfigured allowlist. I could do it post-handshake by using RFC >> 5705 key material exports as the shared secret--this usage seems to >> exemplify the intent of that extension--but TLS raw public keys seem a >> bit closer to “prior art”. > > Indeed DANE is only a good fit for authenticating servers, for > authenticating clients, you just want to compute a public key > fingerprint and do a database lookup. > > This is also supported in Postfix, just don't authenticate > the client cert at all (no PKI), grab the key digest and > use it directly for access control. Wouldn’t there need to be a shared secret, though, or some other way for the server to have some influence on the randomness of what the client’s private key signs? (I don’t know TLS well enough to comment on whether that happens in an ordinary TLS handshake, but I assume it does?) -F
RE: DTLS Heartbeat Removed in OpenSSL 1.1.1
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Vijayakumar Kaliaperumal > Sent: Wednesday, July 08, 2020 11:32 > I now understand that the heartbeat mechanism is completely removed in OpenSSL > 1.1.1, whereas it's still available in gnuTLS. gnuTLS would not be my personal choice of exemplar. "gnuTLS does it" often seems to be a better argument against something than for it. > So I do not understand why it was removed from OpenSSL Well, PR 1928 (https://github.com/openssl/openssl/pull/1928), which removed it, doesn't have a lot of discussion. Richard Levitte created the changes and the request, and Tim Hudson approved them; there's not much else, aside from some comments regarding deprecating the Configure option (which I believe was done). The PR does mention Issue 4856 (https://github.com/openssl/openssl/issues/4856), in which Hanno Boeck cites Heartbleed and claims "there don't seem to be any real world use cases". I'm not convinced that there aren't *any* real-world use cases. Your message suggests you have one, and Seggelmann et al. presumably had one when they wrote RFC 6520 and Seggelmann submitted the code change for OpenSSL. RFC 6520 notes that Heartbeat can be used for PMTU discovery for DTLS, besides its nominal "are you still there?" function. And keepalives are used in a number of protocols, both to keep a path active (though that was more relevant when virtual-circuit-switching and on-demand physical links were more common) and to periodically test a path to ensure the peer was still reachable and responding. However, Hanno Boeck knows as much about real-world TLS and DTLS usage as anyone I can think of, and Heartbeat is widely viewed as over-engineered and unnecessarily complex, which is why we had Heartbleed in the first place. None of the products I currently work on use DTLS, but if they did, I wouldn't be sorry to see Heartbeat go. > Having your own keepalive mechanism(at application level) the only way > forward? If you're using OpenSSL, then I'd say it's either implement one in the application, or create an intermediate library that adds a keepalive mechanism on top of OpenSSL's DTLS support, or hack Heartbeat back into OpenSSL. I definitely would not recommend the third. The first lets you tailor the keepalive to the application's architecture and needs; the second lets you reuse the implementation. -- Michael Wojcik
Re: RFC 7250 raw public keys?
On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote: > > On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni > > wrote: > > > > On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote: > > > >> Does OpenSSL support authentication via raw public keys? (RFC 7250) I > >> can’t find anything to this effect on openssl.org. > > > > These are not presently supported. However, you can use DANE-EE(3) TLSA > > records to authenticate essentially empty leaf certificates: > > That would also require changes to DNS, right? Sure, but DANE-EE(3) is just one way to authenticate a stand-alone self-signed certificate. Indeed OpenSSL does not do the DNS lookups, you can store the matching digest anywhere and retrieve it in whatever way makes sense for your application. You can even compute it on the fly from a copy of the expected certificate. Postfix (in which I'm the maintainer of the TLS stack), creates synthetic DANE TLSA records as the way that it matches certificates by pre-configured "fingerprint" values. That said, you also don't need to use DANE authentication, you can implement your own certificate verification callbacks, ... My point was primarily that a bit of space overhead side, a minimal X.509 certificate is in most cases equivalent to a bare public key, but has broader API support. > What I’m looking for is a way to authenticate a user over TLS in > essentially the same manner that SSH’s handshake uses, where a > signature of a shared secret validates the public key, which is on a > preconfigured allowlist. I could do it post-handshake by using RFC > 5705 key material exports as the shared secret--this usage seems to > exemplify the intent of that extension--but TLS raw public keys seem a > bit closer to “prior art”. Indeed DANE is only a good fit for authenticating servers, for authenticating clients, you just want to compute a public key fingerprint and do a database lookup. This is also supported in Postfix, just don't authenticate the client cert at all (no PKI), grab the key digest and use it directly for access control. -- Viktor.
Re: DTLS Heartbeat Removed in OpenSSL 1.1.1
Hi, I am just following up with my earlier mail as I did not get an answer. I now understand that the heartbeat mechanism is completely removed in OpenSSL 1.1.1, whereas it's still available in gnuTLS. So I do not understand why it was removed from OpenSSL Having your own keepalive mechanism(at application level) the only way forward ? I am still looking for some answers.Can someone throw some light on it ? Regards, Vijay On Tue, Jun 9, 2020 at 2:25 PM Vijayakumar Kaliaperumal wrote: > Hello, > > From the release notes of OpenSSL 1.1.1, I could see that DTLS heartbeat > has been removed > . > Heartbeat support has been removed; the ABI is changed for now. > > With RFC 6520 in standards track, any specific reason(Vulnerability/other > security issue reported) for the removal ?, How can we re-enable it ? > Recompile OpenSSL without OPENSSL_NO_HEARTBEATS macro ? Please advise. > > Regards, > Vijay >
Re: RFC 7250 raw public keys?
> On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni > wrote: > > On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote: > >> Does OpenSSL support authentication via raw public keys? (RFC 7250) I >> can’t find anything to this effect on openssl.org. > > These are not presently supported. However, you can use DANE-EE(3) TLSA > records to authenticate essentially empty leaf certificates: That would also require changes to DNS, right? What I’m looking for is a way to authenticate a user over TLS in essentially the same manner that SSH’s handshake uses, where a signature of a shared secret validates the public key, which is on a preconfigured allowlist. I could do it post-handshake by using RFC 5705 key material exports as the shared secret--this usage seems to exemplify the intent of that extension--but TLS raw public keys seem a bit closer to “prior art”. Anyhow, thank you! -FG
Re: Order of protocols in MinProtocol
On 08.07.20 17:57, Matt Caswell wrote: > > > On 08/07/2020 17:48, Klaus Umbach via openssl-users wrote: > > On 08.07.20 12:21, Viktor Dukhovni wrote: > >> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > >> > >>> On 08/07/2020 16:28, Viktor Dukhovni wrote: > > How could I set the a System default "MinProtocol" for DTLS and TLS to > > 1.2? > > AFAIK, that's not presently possible. You can specify application > profiles, for applications that specify an application name when > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > select an alternative configuration file for DTLS applications. > >>> > >>> Arguably, that is a bug. You *should* be able to do that - perhaps based > >>> on some sensible mapping between TLS protocol versions based on whether > >>> we have a DTLS or TLS based SSL_METHOD. > > > > Should I open an issue at https://github.com/openssl/openssl/issues? > > Yes please. Done: https://github.com/openssl/openssl/issues/12394 > > > > But for my personal problem right now (openconnect uses TLS and DTLS, so > > even if it would set an application name I couldn't set a "proper" > > setting), until this bug is fixed, I use this now: > > > ># MinProtocol = TLSv1.2 > >Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 > > Looks sane - although do you also mean to disable DTLSv1? Perhaps for > safety you should also disable SSLv3 (although support for it is not > built by default anyway). Ah, thanks, I missed DTLSv1. (SSLv3 is not enabled in my build, but for safety-reasons, you are right) Thank you! - Klaus
Re: RFC 7250 raw public keys?
On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote: > Does OpenSSL support authentication via raw public keys? (RFC 7250) I > can’t find anything to this effect on openssl.org. These are not presently supported. However, you can use DANE-EE(3) TLSA records to authenticate essentially empty leaf certificates: $ openssl req -new \ -newkey ed25519 -nodes -keyout key.pem \ -x509 -days 36500 -subj / -out cert.pem The resulting certificate contains pretty much only a public key: $ openssl x509 -text -in cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 03:ff:26:4b:48:53:95:3c:4e:db:5d:db:b8:e5:13:1c:a7:67:e0:49 Signature Algorithm: ED25519 Issuer: Validity Not Before: Jul 8 16:54:41 2020 GMT Not After : Jun 14 16:54:41 2120 GMT Subject: Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: ad:48:26:95:0f:70:c4:c6:8c:8b:da:9a:d1:3c:18: ef:ec:60:b1:d9:d6:40:7a:5c:4f:6e:8e:36:a2:9e: b0:c7 X509v3 extensions: X509v3 Subject Key Identifier: A1:47:10:54:37:97:45:C0:3D:5B:3A:F2:1A:3D:EE:9F:4A:46:7B:D2 X509v3 Authority Key Identifier: keyid:A1:47:10:54:37:97:45:C0:3D:5B:3A:F2:1A:3D:EE:9F:4A:46:7B:D2 X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: ED25519 48:e7:e2:1a:a0:3b:00:42:7c:66:46:67:26:08:ed:df:f8:64: 70:17:ff:72:8e:1d:42:8e:9b:99:e8:54:e5:e1:eb:97:fe:4e: dd:e6:89:b8:05:e5:b3:d8:da:a6:97:91:90:c5:54:56:0e:90: f5:b7:5a:54:c9:78:0b:b5:ed:03 -BEGIN CERTIFICATE- MIIBFjCByaADAgECAhQD/yZLSFOVPE7bXdu45RMcp2fgSTAFBgMrZXAwADAgFw0y MDA3MDgxNjU0NDFaGA8yMTIwMDYxNDE2NTQ0MVowADAqMAUGAytlcAMhAK1IJpUP cMTGjIvamtE8GO/sYLHZ1kB6XE9ujjainrDHo1MwUTAdBgNVHQ4EFgQUoUcQVDeX RcA9WzryGj3un0pGe9IwHwYDVR0jBBgwFoAUoUcQVDeXRcA9WzryGj3un0pGe9Iw DwYDVR0TAQH/BAUwAwEB/zAFBgMrZXADQQBI5+IaoDsAQnxmRmcmCO3f+GRwF/9y jh1CjpuZ6FTl4euX/k7d5om4BeWz2Nqml5GQxVRWDpD1t1pUyXgLte0D -END CERTIFICATE- And while it is larger than the bare key, the size penalty is not prohibitive. -- Viktor.
Re: Order of protocols in MinProtocol
On 08/07/2020 17:48, Klaus Umbach via openssl-users wrote: > On 08.07.20 12:21, Viktor Dukhovni wrote: >> On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: >> >>> On 08/07/2020 16:28, Viktor Dukhovni wrote: > How could I set the a System default "MinProtocol" for DTLS and TLS to > 1.2? AFAIK, that's not presently possible. You can specify application profiles, for applications that specify an application name when initializing OpenSSL. Or use the OPENSSL_CONF environment variable to select an alternative configuration file for DTLS applications. >>> >>> Arguably, that is a bug. You *should* be able to do that - perhaps based >>> on some sensible mapping between TLS protocol versions based on whether >>> we have a DTLS or TLS based SSL_METHOD. > > Should I open an issue at https://github.com/openssl/openssl/issues? Yes please. > But for my personal problem right now (openconnect uses TLS and DTLS, so > even if it would set an application name I couldn't set a "proper" > setting), until this bug is fixed, I use this now: > ># MinProtocol = TLSv1.2 >Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 Looks sane - although do you also mean to disable DTLSv1? Perhaps for safety you should also disable SSLv3 (although support for it is not built by default anyway). Matt
RFC 7250 raw public keys?
Hello, Does OpenSSL support authentication via raw public keys? (RFC 7250) I can’t find anything to this effect on openssl.org. Thank you! cheers, -Felipe Gasper
Re: Order of protocols in MinProtocol
On 08.07.20 12:21, Viktor Dukhovni wrote: > On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > > > On 08/07/2020 16:28, Viktor Dukhovni wrote: > > >> How could I set the a System default "MinProtocol" for DTLS and TLS to > > >> 1.2? > > > > > > AFAIK, that's not presently possible. You can specify application > > > profiles, for applications that specify an application name when > > > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > > > select an alternative configuration file for DTLS applications. > > > > Arguably, that is a bug. You *should* be able to do that - perhaps based > > on some sensible mapping between TLS protocol versions based on whether > > we have a DTLS or TLS based SSL_METHOD. Should I open an issue at https://github.com/openssl/openssl/issues? > > I agree that the situation with MinProtocol in openssl.cnf is > unfortunate. But instead of mappings, I would propose a different > solution: > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > i.e. SSL_CTX objects with a TLS-based method. > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > that are similarly restricted to SSL_CTX objects with a DTLS-based > method. > > * Since SSL_CTX_new() takes a required method argument, we are in > never in doubt as to which pair of controls to apply to a given > context. > > Thoughts? To me this sounds sane. But for my personal problem right now (openconnect uses TLS and DTLS, so even if it would set an application name I couldn't set a "proper" setting), until this bug is fixed, I use this now: # MinProtocol = TLSv1.2 Protocol = -TLSv1, -TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.2 (with a big comment for future-me, why I did something, that i shouldn't) To my understanding, this will do exaclty what I want, up to that point in time, when there are newer versions of DTLS and/or TLS supported and I want to use them. (SSL3 is not supported in my build) Am I right? - Klaus
Re: Order of protocols in MinProtocol
On Wed, Jul 08, 2020 at 05:40:38PM +0100, Matt Caswell wrote: > > I agree that the situation with MinProtocol in openssl.cnf is > > unfortunate. But instead of mappings, I would propose a different > > solution: > > > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > > i.e. SSL_CTX objects with a TLS-based method. > > > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > > that are similarly restricted to SSL_CTX objects with a DTLS-based > > method. > > > > * Since SSL_CTX_new() takes a required method argument, we are in > > never in doubt as to which pair of controls to apply to a given > > context. > > > > Thoughts? > > Yes - that could work. Although it begs the question - would it change > the way SSL_CTX_set_min_proto_version() works? (I assume that currently > works just fine as is) No changes in SSL_CTX_set_(min|max)_proto_version() required. The API remains the same, and a user calling it on a context with a DTLS-based method, would (as before) pass the appropriate *DTLS* versions. The only change would be in the .cnf file, where "MinProtocol" and "MaxProtocol" would now apply only in TLS-based contexts, and new DTLSMinProtocol and DTLSMaxProtocol only in DTLS-based contexts. > Another question that throws up is how much of that solution would we > backport to 1.1.1 since DTLS(Min|Max)Protocol would be a new feature. I'd be inclined to backport. > Should we backport it anyway with the justification that it is a "fix"? > Or do we just backport the bit that means it doesn't get applied to DTLS? I see it as a bugfix. Yes, at least not misapply TLS limits to DTLS, but at that point not adding the corresponding DTLS controls feels too cautious to me. -- Viktor.
Re: Order of protocols in MinProtocol
On 08/07/2020 17:21, Viktor Dukhovni wrote: > On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > >> On 08/07/2020 16:28, Viktor Dukhovni wrote: How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? >>> >>> AFAIK, that's not presently possible. You can specify application >>> profiles, for applications that specify an application name when >>> initializing OpenSSL. Or use the OPENSSL_CONF environment variable to >>> select an alternative configuration file for DTLS applications. >> >> Arguably, that is a bug. You *should* be able to do that - perhaps based >> on some sensible mapping between TLS protocol versions based on whether >> we have a DTLS or TLS based SSL_METHOD. > > I agree that the situation with MinProtocol in openssl.cnf is > unfortunate. But instead of mappings, I would propose a different > solution: > > * Restrict MinProtocol/MaxProtocol to just TLS protocols, > i.e. SSL_CTX objects with a TLS-based method. > > * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, > that are similarly restricted to SSL_CTX objects with a DTLS-based > method. > > * Since SSL_CTX_new() takes a required method argument, we are in > never in doubt as to which pair of controls to apply to a given > context. > > Thoughts? Yes - that could work. Although it begs the question - would it change the way SSL_CTX_set_min_proto_version() works? (I assume that currently works just fine as is) Another question that throws up is how much of that solution would we backport to 1.1.1 since DTLS(Min|Max)Protocol would be a new feature. Should we backport it anyway with the justification that it is a "fix"? Or do we just backport the bit that means it doesn't get applied to DTLS? Matt
Re: Order of protocols in MinProtocol
On Wed, Jul 08, 2020 at 04:36:55PM +0100, Matt Caswell wrote: > On 08/07/2020 16:28, Viktor Dukhovni wrote: > >> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > > > > AFAIK, that's not presently possible. You can specify application > > profiles, for applications that specify an application name when > > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > > select an alternative configuration file for DTLS applications. > > Arguably, that is a bug. You *should* be able to do that - perhaps based > on some sensible mapping between TLS protocol versions based on whether > we have a DTLS or TLS based SSL_METHOD. I agree that the situation with MinProtocol in openssl.cnf is unfortunate. But instead of mappings, I would propose a different solution: * Restrict MinProtocol/MaxProtocol to just TLS protocols, i.e. SSL_CTX objects with a TLS-based method. * Introduct new controls: DTLSMinProtocolDTLS, DTLSMaxProtocol, that are similarly restricted to SSL_CTX objects with a DTLS-based method. * Since SSL_CTX_new() takes a required method argument, we are in never in doubt as to which pair of controls to apply to a given context. Thoughts? -- Viktor.
Re: Order of protocols in MinProtocol
On 08/07/2020 16:28, Viktor Dukhovni wrote: >> How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? > > AFAIK, that's not presently possible. You can specify application > profiles, for applications that specify an application name when > initializing OpenSSL. Or use the OPENSSL_CONF environment variable to > select an alternative configuration file for DTLS applications. > Arguably, that is a bug. You *should* be able to do that - perhaps based on some sensible mapping between TLS protocol versions based on whether we have a DTLS or TLS based SSL_METHOD. Matt
Re: Order of protocols in MinProtocol
On Wed, Jul 08, 2020 at 04:58:39PM +0200, Klaus Umbach via openssl-users wrote: > when I set "MinProtocol" to "TLSv1.2" in openssl.cnf, DTLSv1.2 doesn't work > for > the client (in my specific case openconnect). Unfortunately, I think that's expected. The actual bounds are numeric, and TLS protocols start at 0x0301 (TLS 1.0) and go up to 0x304 (TLS 1.3): # define TLS1_VERSION0x0301 # define TLS1_1_VERSION 0x0302 # define TLS1_2_VERSION 0x0303 # define TLS1_3_VERSION 0x0304 # define TLS_MAX_VERSION TLS1_3_VERSION [ It is also possible to set the floor at SSL3_VERSION == 0x0300, if that's still enabled in your build. ] while DTLS protocols start at 0xFEFF (DTLS 1.0) and count down: # define DTLS1_VERSION 0xFEFF # define DTLS1_2_VERSION 0xFEFD # define DTLS_MIN_VERSIONDTLS1_VERSION # define DTLS_MAX_VERSIONDTLS1_2_VERSION So when on a particular SSL_CTX you set MinProtocol and/or MaxProtocol, that setting really only makes sense for TLS or for DTLS, but never both, and you need a separate SSL_CTX for DTLS if you intend to specify the protocol ranges. > How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? AFAIK, that's not presently possible. You can specify application profiles, for applications that specify an application name when initializing OpenSSL. Or use the OPENSSL_CONF environment variable to select an alternative configuration file for DTLS applications. -- Viktor.
Order of protocols in MinProtocol
Hi, when I set "MinProtocol" to "TLSv1.2" in openssl.cnf, DTLSv1.2 doesn't work for the client (in my specific case openconnect). According to https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html, only one value is possible, so I can't set both. The usage of "Protocol", where I could use a list, is marked as deprecated. If I set it to "DTLSv1.2", openconnect works fine, but why is "TLSv1.2" higher than "DTLSv1.2" and what is the minimal version of TLS now? How could I set the a System default "MinProtocol" for DTLS and TLS to 1.2? - Klaus
