From philip at noerdcampus.de Sun Jun 6 15:47:34 2021 From: philip at noerdcampus.de (Philip Schaten) Date: Sun, 06 Jun 2021 15:47:34 +0200 Subject: [gnutls-help] gnutls offers rsa_pcks_sha1, but does not accept it Message-ID: Hello again, I wrote to this list on 15-05-2021 having trouble with my universities mail server. Thanks to Daiki Ueno, I got this to work on my system by changing the crypto policies, but I believe I may have found a bug in gnutls as well: - Using gnutls-cli, I try to establish a connection to the mail server. - From wireshark, I can see that gnutls offers rsa_pcks_sha1 as a signature algorithm. - The server is admittedly badly configured and chooses that signature algorithm. - gnutls aborts, complaining that "One of the involved algorithms has insufficient security level." (btw. Why can't it just state for what exact reason the security level was deemed insufficient? that would be incredibly useful...) Openssl, in contrast, doesn't even offer rsa_pcks_sha1 if it's not allowed per the systems crypto policies. Sooo I believe that the bug here is to offer SHA1 in the first place, ignoring the crpto policies. But I am very new to this (4 weeks ago I had'nt heard about GnuTLS), maybe I'm missing something here: Maybe TLSv1.2 is disabled completely to mitigate some sort of man-in-the-middle attack where the attacker forces the use of sha1 to be able to spoof the servers identity..? Very much looking forward to your responses. Best Philip From ueno at gnu.org Mon Jun 7 13:52:43 2021 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 07 Jun 2021 13:52:43 +0200 Subject: [gnutls-help] gnutls offers rsa_pcks_sha1, but does not accept it In-Reply-To: (Philip Schaten's message of "Sun, 06 Jun 2021 15:47:34 +0200") References: Message-ID: <87y2bldh84.fsf-ueno@gnu.org> Philip Schaten writes: > I wrote to this list on 15-05-2021 having trouble with my universities > mail server. > Thanks to Daiki Ueno, I got this to work on my system by changing the > crypto policies, but I believe I may have found a bug in gnutls as > well: Let me add Alexander, the current maintainer of crypto-policies, who could shed some light on this. > - Using gnutls-cli, I try to establish a connection to the mail server. > - From wireshark, I can see that gnutls offers rsa_pcks_sha1 as a > signature algorithm. Do you see this behavior also with the DEFAULT policy? > - The server is admittedly badly configured and chooses that signature > algorithm. > - gnutls aborts, complaining that "One of the involved algorithms has > insufficient security level." (btw. Why can't it just state for what > exact reason the security level was deemed insufficient? that would be > incredibly useful...) > > Openssl, in contrast, doesn't even offer rsa_pcks_sha1 if it's not > allowed per the systems crypto policies. > > Sooo I believe that the bug here is to offer SHA1 in the first place, > ignoring the crpto policies. > > But I am very new to this (4 weeks ago I had'nt heard about GnuTLS), > maybe I'm missing something here: Maybe TLSv1.2 is disabled completely > to mitigate some sort of man-in-the-middle attack where the attacker > forces the use of sha1 to be able to spoof the servers identity..? > > Very much looking forward to your responses. Regards, -- Daiki Ueno From philip at noerdcampus.de Tue Jun 8 10:37:07 2021 From: philip at noerdcampus.de (Philip Schaten) Date: Tue, 08 Jun 2021 10:37:07 +0200 Subject: [gnutls-help] gnutls offers rsa_pcks_sha1, but does not accept it In-Reply-To: <87y2bldh84.fsf-ueno@gnu.org> References: <87y2bldh84.fsf-ueno@gnu.org> Message-ID: Hi, > > > - Using gnutls-cli, I try to establish a connection to the mail > > server. > > - From wireshark, I can see that gnutls offers rsa_pcks_sha1 as a > > signature algorithm. > > Do you see this behavior also with the DEFAULT policy? yes. So, in brief: DEFAULT policy is enabled. GnuTLS proposes SHA1 as a signature algorithm during TLS Handshake. Server chooses SHA1. GnuTLS cancels because SHA1 is forbidden by DEFAULT crypto-policy. In the end, this leads to evolution mailclient not working anymore. Best Philip P.S.: I sent you the mailserver address privately, in case you want to reproduce the problem. From mk at cognitivedissonance.ca Wed Jun 9 16:35:13 2021 From: mk at cognitivedissonance.ca (MK) Date: Wed, 9 Jun 2021 10:35:13 -0400 Subject: [gnutls-help] Creating PKCS12 trust with certtool Message-ID: <20210609103513.5799d6cc976a5eeeb6f17d9d@cognitivedissonance.ca> Hi! I've been using java's keytool to create private PKIX ecosystems starting with the CA certificate, which is then used to sign server and client certificates. In order for this to work, to validate a server a client needs a trust file containing the CA certificate. Currently I'm working on interconnectivity between a C++ application using GnuTLS and a java application using standard java ssl features. Mostly because of the latter, the easiest thing to do is use PKCS12 files. I generate the certificates in pem format first. I was curious about using certtool to do the same things as I use keytool (creating the public key infrastructure). I'm stuck on the trust file. Using keytool, this goes: keytool -importcert -file CAcertificate.pem -keystore trust.p12 -storetype PKCS12 -alias ca_cert -storepass:file pword.txt This creates "trust.p12" which works as a trust with both applications. I can get to here using certtool -- create the pem certs and keys, then the individual pkcs credential files. To then create the trust, what I think should be the near equivalent of the above: certtool --to-p12 --load[-ca]-certificate CAcertificate.pem --outder --outfile trust.p12 (The password is then entered manually.) The outcome seems the same whether I use '-ca' in the '--load-' parameter or not. Examining the file with certtool: certtool --p12-info --infile=trust.p12 --inder It looks pretty much the same as the keytool created equivalent, one certificate in BAG #0. However, examining it with keytool, for the version created with certtool, I get: Keystore type: PKCS12 Keystore provider: SUN Your keystore contains 0 entries Trying to use the trust with the java client then fails: Initialization failed: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty Searching online most people who get this error get it because the file doesn't exist (wrong path). Is there a better way to create a PKCS12 trust with certtool? Sincerely, Mark Eriksen From ueno at gnu.org Fri Jun 11 15:26:59 2021 From: ueno at gnu.org (Daiki Ueno) Date: Fri, 11 Jun 2021 15:26:59 +0200 Subject: [gnutls-help] gnutls offers rsa_pcks_sha1, but does not accept it In-Reply-To: (Philip Schaten's message of "Tue, 08 Jun 2021 10:37:07 +0200") References: <87y2bldh84.fsf-ueno@gnu.org> Message-ID: <87fsxoh6qk.fsf-ueno@gnu.org> Philip Schaten writes: >> > - Using gnutls-cli, I try to establish a connection to the mail >> > server. >> > - From wireshark, I can see that gnutls offers rsa_pcks_sha1 as a >> > signature algorithm. >> >> Do you see this behavior also with the DEFAULT policy? > > yes. > So, in brief: > DEFAULT policy is enabled. > GnuTLS proposes SHA1 as a signature algorithm during TLS Handshake. > Server chooses SHA1. > GnuTLS cancels because SHA1 is forbidden by DEFAULT crypto-policy. > In the end, this leads to evolution mailclient not working anymore. Thank you; that indeed seems like a bug in GnuTLS itself. I've filed an MR to fix it: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 Regards, -- Daiki Ueno From nicolas at babelouest.org Fri Jun 11 17:21:51 2021 From: nicolas at babelouest.org (Nicolas Mora) Date: Fri, 11 Jun 2021 11:21:51 -0400 Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode In-Reply-To: References: <87y2fggmu3.fsf-ueno@gnu.org> <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de> <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org> <87k0qwpu9q.fsf-ueno@gnu.org> <87czvv9lre.fsf-ueno@gnu.org> <1499f3b3-3235-35e4-acd8-5b571851d00a@babelouest.org> Message-ID: <69de4e7f-7e04-08ec-4fb2-40d4f0e0dc93@babelouest.org> Hello, Is it possible to continue with this patch? Le 2021-03-20 ? 20 h 23, Nicolas Mora a ?crit?: > > I'm having problems implementing ecdh-es with Curve25519/Curve448. > > - If I use an ed25519 key pair to compute, _gnutls_dh_compute_key > returns -55 > - If I use an x25519 key pair to compute, I can't import the key using > gnutls_pubkey_import/gnutls_privkey_import_x509 > > Is it possible at this time to calculate a key agreement with these curves? > > I have a working prototype in rhonabwy [1] that uses Nettle's functions > curve25519_mul/curve448_mul. In this case I expect a X25519 or X448 key > pair. > I was stuck with the implementation of ecdh-es with Curve25519/Curve448, but ecdh-es with ecdsa works fine. Thanks in advance /Nicolas From philip at noerdcampus.de Fri Jun 11 19:16:33 2021 From: philip at noerdcampus.de (Philip Schaten) Date: Fri, 11 Jun 2021 19:16:33 +0200 Subject: [gnutls-help] gnutls offers rsa_pcks_sha1, but does not accept it In-Reply-To: <87fsxoh6qk.fsf-ueno@gnu.org> References: <87y2bldh84.fsf-ueno@gnu.org> <87fsxoh6qk.fsf-ueno@gnu.org> Message-ID: > I've filed an MR to fix it:> https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 Awesome :) Thank you very much! Best, Philip From ludo at gnu.org Tue Jun 15 23:51:08 2021 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Tue, 15 Jun 2021 23:51:08 +0200 Subject: [gnutls-help] TLS downgrade at bitbucket.org In-Reply-To: <87pmwns3of.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 15 Jun 2021 14:38:56 +0200") References: <871r93v665.fsf@inria.fr> <87pmwns3of.fsf@gnu.org> Message-ID: <87eed2re43.fsf_-_@gnu.org> Hi, (+Cc: gnutls-help; this is about a TLS 1.3?1.2 downgrade at bitbucket.org, see for context.) Ludovic Court?s skribis: > And indeed, cURL 7.77 (the replacement) exhibits the bogus behavior: > > $ guix environment -CN --no-grafts --ad-hoc curl at 7.77 nss-certs -- curl https://bitbucket.org > /dev/null > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 > curl: (35) gnutls_handshake() failed: An illegal parameter has been received. > $ guix environment -CN --no-grafts --ad-hoc curl at 7.74 nss-certs -- curl https://bitbucket.org > /dev/null > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 75735 100 75735 0 0 134k 0 --:--:-- --:--:-- --:--:-- 134k So these two cURL versions use different TLS priority strings; here?s the one that cURL 7.77 uses (bad) vs. the one that 7.74 uses (good): --8<---------------cut here---------------start------------->8--- $ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-TLS1.3" -p https bitbucket.org Processed 444 CA certificate(s). Resolving 'bitbucket.org:https'... Connecting to '2406:da00:ff00::6b17:d1f5:443'... |<1>| Detected downgrade to TLS 1.2 from TLS 1.3 *** Fatal error: An illegal parameter has been received. $ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0" -p https bitbucket.org Processed 444 CA certificate(s). Resolving 'bitbucket.org:https'... Connecting to '2406:da00:ff00::6b17:d1f5:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=bitbucket.org,OU=Bitbucket,O=Atlassian\, Inc.,L=San Francisco,ST=California,C=US,serialNumber=3928449,jurisdictionOfIncorporationStateOrProvinceName=Delaware,jurisdictionOfIncorporationCountryName=US,businessCategory=Private Organization', issuer `CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x040c19f4e9ba36e333316834b8908235, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2020-03-27 00:00:00 UTC', expires `2022-05-23 12:00:00 UTC', pin-sha256="nFuN2gwclU/9rBe3vz/UUe48hIdL5wLVY8Zke9vApM0=" Public Key ID: sha1:5f7c6de5e52a6bc39dfdcd5230220f1a7957772b sha256:9c5b8dda0c1c954ffdac17b7bf3fd451ee3c84874be702d563c6647bdbc0a4cd Public Key PIN: pin-sha256:nFuN2gwclU/9rBe3vz/UUe48hIdL5wLVY8Zke9vApM0= - Certificate[1] info: - subject `CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US', issuer `CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0c79a944b08c11952092615fe26b1d83, RSA key 2048 bits, signed using RSA-SHA256, activated `2013-10-22 12:00:00 UTC', expires `2028-10-22 12:00:00 UTC', pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho=" - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-128-GCM) - Options: OCSP status request, - Handshake was completed - Simple Client Mode: C-c C-c --8<---------------cut here---------------end--------------->8--- The key thing here is ?Detected downgrade to TLS 1.2 from TLS 1.3?. Why is a downgrade detected when using the most explicit priority string and not when using the shorter string? Aren?t these two priority strings supposed to be equivalent today? (This is with GnuTLS 3.6.16.) Thanks, Ludo?. From johnbast at protonmail.com Wed Jun 16 12:15:47 2021 From: johnbast at protonmail.com (John) Date: Wed, 16 Jun 2021 10:15:47 +0000 Subject: [gnutls-help] disable renogotiation Message-ID: Hello, Is there a way in Gnutls to disable renogotiation on TLS and a way to disable client initiated secure renegotiation? This is useful to harden the server. For example Exim4+Gnutls on Debian 10. There does not seem to be a need to support renegotiation or resumption on a mail server, because STARTTLS sessions are set up in each SMTP session. Disabling renegotiation reduces the attack surface. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Wed Jun 16 13:34:14 2021 From: jgh at wizmail.org (Jeremy Harris) Date: Wed, 16 Jun 2021 12:34:14 +0100 Subject: [gnutls-help] disable renogotiation In-Reply-To: References: Message-ID: <93ac2293-0749-2c47-cc8f-4a6fa2781355@wizmail.org> On 16/06/2021 11:15, John wrote: > Is there a way in Gnutls to disable renogotiation on TLS and a way to disable client initiated secure renegotiation? https://gnutls.org/manual/html_node/Safe-renegotiation.html#Safe-renegotiation "It is possible to disable use of the extension completely, in both clients and servers, by using the %DISABLE_SAFE_RENEGOTIATION priority string however we strongly recommend you to only do this for debugging and test purposes." > > This is useful to harden the server. For example Exim4+Gnutls on Debian 10. There does not seem to be a need to support renegotiation or resumption on a mail server, because STARTTLS sessions are set up in each SMTP session. Disabling renegotiation reduces the attack surface. Resumption is a different kettle of fish, but since it wasn't enabled in the most-recent Exim release I doubt that Debian's build it up. Even if they did, the project coding has it not enabled until you do so explicitly in config. As for need, if you're repeatedly connecting the same pair of hosts, resumption saves cpu cycles. -- Cheers, Jeremy From johnbast at protonmail.com Wed Jun 16 21:32:42 2021 From: johnbast at protonmail.com (John) Date: Wed, 16 Jun 2021 19:32:42 +0000 Subject: [gnutls-help] disable renegotiation Message-ID: Hi Jeremy, Thanks for your reply! On Wednesday, June 16th, 2021 at 1:34 PM, Jeremy Harris wrote: > On 16/06/2021 11:15, John wrote: > > > Is there a way in Gnutls to disable renegotiation on TLS and a way to disable client initiated secure renegotiation? > > https://gnutls.org/manual/html_node/Safe-renegotiation.html#Safe-renegotiation > > "It is possible to disable use of the extension completely, in both clients and servers, by using the %DISABLE_SAFE_RENEGOTIATION priority string however we strongly recommend you to only do this for debugging and test purposes." I read that before, and found it somewhat unclear. I'd interpret it as disabling _safe_ renegotiation as the keyword says. I'd like to be able to disable all renegotiation and seperately all client renegotiation. This talks about disabling an unnamed extension, which could be interpreted as the "safe renegotiation" extension. The safe renegotiation extension is named as such in the same text. For now I read it as disabling "safe renegotiation". It doesn't make much sense to do disable just the safe part in 2021 while still allowing renegotiation. I that sense I understand the warning. RFC5746 (2010): "Many servers can mitigate this attack simply by refusing to renegotiate at all." Although this is about just one attack (a specific MitM attack), this does not only apply to one purpose. RFC5746: "TLS implementations SHOULD provide a mechanism to disable and enable renegotiation." I read that as: [all] TLS implementations should be able to disable [all] renegotiation. An implementation could have: %DISABLE_RENEGOTIATION %DISABLE_CLIENT_RENEGOTIATION > > This is useful to harden the server. For example Exim4+Gnutls on Debian 10. There does not seem to be a need to support renegotiation or resumption on a mail server, because STARTTLS sessions are set up in each SMTP session. Disabling renegotiation reduces > > the attack surface. > > Resumption is a different kettle of fish, but since it wasn't enabled in the most-recent Exim release I doubt that Debian's build it up. > Even if they did, the project coding has it not enabled until you do so explicitly in config. As for need, if you're repeatedly connecting the same pair of hosts, resumption saves cpu cycles. >From a security perspective, it's mainly about internet facing mail (MX) servers and defending against DoS and other threats known or unknown. Does Debian 10 Exim4+gnutls support client initiated renegotiation? Immuniweb SSL test (host:25) reports that it does. Debian 10 Apache2+openssl seems to not allow client initiated renegotiation according to the remote test by Immuniweb. Thanks, John From ueno at gnu.org Sat Jun 19 17:17:30 2021 From: ueno at gnu.org (Daiki Ueno) Date: Sat, 19 Jun 2021 17:17:30 +0200 Subject: [gnutls-help] TLS downgrade at bitbucket.org In-Reply-To: <87eed2re43.fsf_-_@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s?= =?utf-8?Q?=22's?= message of "Tue, 15 Jun 2021 23:51:08 +0200") References: <871r93v665.fsf@inria.fr> <87pmwns3of.fsf@gnu.org> <87eed2re43.fsf_-_@gnu.org> Message-ID: <87tultyjcl.fsf-ueno@gnu.org> Ludovic Court?s writes: > $ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-TLS1.3" -p https bitbucket.org > Processed 444 CA certificate(s). > Resolving 'bitbucket.org:https'... > Connecting to '2406:da00:ff00::6b17:d1f5:443'... > |<1>| Detected downgrade to TLS 1.2 from TLS 1.3 > *** Fatal error: An illegal parameter has been received. [...] > The key thing here is ?Detected downgrade to TLS 1.2 from TLS 1.3?. > > Why is a downgrade detected when using the most explicit priority > string and not when using the shorter string? I would say this is an expected behavior when the TLS downgrade protection mechanism[1] is in action. What happens is as follows: - the client advertises TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 (in this order) in the supported_versions extension - the server skips TLS 1.0 and TLS 1.1 (maybe it's disabled), sees TLS 1.2 first in supported_versions, then TLS 1.3; while it also supports TLS 1.3, as TLS 1.2 has precedence and it selects TLS 1.2 and sends the downgrade sentinel in server_random - the client sees the sentinel while TLS 1.3 is enabled, treats it as an unwanted protocol downgrade > Aren?t these two priority strings supposed to be equivalent today? No. If -VERS-TLS-ALL is used, the default priorities on TLS versions in NORMAL are ignored; the user is responsible for building the priority string so it reflects the actual preference, which in this case is: -VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0 Footnotes: [1] https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3 Regards, -- Daiki Ueno From ludo at gnu.org Sun Jun 20 23:26:13 2021 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Sun, 20 Jun 2021 23:26:13 +0200 Subject: [gnutls-help] TLS downgrade at bitbucket.org In-Reply-To: <87tultyjcl.fsf-ueno@gnu.org> (Daiki Ueno's message of "Sat, 19 Jun 2021 17:17:30 +0200") References: <871r93v665.fsf@inria.fr> <87pmwns3of.fsf@gnu.org> <87eed2re43.fsf_-_@gnu.org> <87tultyjcl.fsf-ueno@gnu.org> Message-ID: <87wnqo6xe2.fsf@gnu.org> Hi Daiki, Daiki Ueno skribis: > Ludovic Court?s writes: > >> $ gnutls-cli --priority="NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-TLS1.1:+VERS-TLS1.2:+VERS-TLS1.3" -p https bitbucket.org [...] >> Aren?t these two priority strings supposed to be equivalent today? > > No. If -VERS-TLS-ALL is used, the default priorities on TLS versions in > NORMAL are ignored; the user is responsible for building the priority > string so it reflects the actual preference, which in this case is: > > -VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0 Thanks for the explanations. As you suggest, the mistake was that cURL 7.77.0 would pass the priority string in the ?wrong order?, preferring older TLS versions. This is now fixed: https://github.com/curl/curl/issues/7277 Ludo?. From johnbast at protonmail.com Thu Jun 24 21:09:05 2021 From: johnbast at protonmail.com (John) Date: Thu, 24 Jun 2021 19:09:05 +0000 Subject: [gnutls-help] disable renegotiation Message-ID: Asking my question again to those who know: Is there currently a way in Gnutls to disable renegotiation on TLS and a way to disable client initiated secure renegotiation? The option to disabling renegotiation is mentioned in RFC5746: RFC5746: "TLS implementations SHOULD provide a mechanism to disable and enable renegotiation." RFC5746: "Many servers can mitigate this attack simply by refusing to renegotiate at all." For this to work, developers and/or users needs to be able to refuse client initiated renegotiation. An user configurable implementation could have: %DISABLE_RENEGOTIATION %DISABLE_CLIENT_RENEGOTIATION I am aware of the option to disable safe renegotiation. That seems to be limited to disabling safe renegotiation, which would likely leave the server vulnerable. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: