From sebastien.havas at ise.fr Thu Aug 3 17:52:59 2017 From: sebastien.havas at ise.fr (=?UTF-8?Q?S=c3=a9bastien_HAVAS?=) Date: Thu, 3 Aug 2017 17:52:59 +0200 Subject: [gnutls-help] certtool - generate CSR without CKM_RSA_PKCS Message-ID: <8983816a-d35b-6887-da13-1ad679245591@ise.fr> Hello, I'm trying to generate a CSR via a RSA key pair on a HSM (ATOS BULL Proteccio). Due to a law, multiple constraints have been applied to the HSM, including the deactivation of the CKM_RSA_PKCS signature algorithm. As such, when I invoke the following command with certtool (version 3.5.8), it fails at the end because it wanted to sign the CSR with the private key with the CKM_RSA_PKCS algorithm. C:\Program Files\GnuTLS\bin>certtool.exe --provider=C:\windows\System32\nethsm.dll --generate-request --load-privkey "%PRIVKEY%" --load-pubkey "%PUBKEY%" --outfile C:\Users\shavas\Desktop\extractCSR.csr Bull TrustWay Proteccio NetHSM 2.11 Configuration case 3 read from C:\Users\shavas\AppData\Roaming\Bull\Proteccio\proteccio.ini Generating a PKCS #10 certificate request... Token 'NUMERIA' with URL 'pkcs11:model=Proteccio%23EL-S1;manufacturer=BULL%20S.A.S%2c%20Les%20Clayes%2c%20France;serial=81604-0050000381;token=NUMERIA' requires user PIN Enter PIN: Common name: TEST NUMERIA Organizational unit name: NUMERIA Organization name: Locality name: State or province name: Country name (2 chars): FR Enter the subject's domain component (DC): UID: Enter a dnsName of the subject of the certificate: Enter a URI of the subject of the certificate: Enter the IP address of the subject of the certificate: Enter the e-mail of the subject of the certificate: Enter a challenge password: Does the certificate belong to an authority? (y/N): Will the certificate be used for signing (DHE ciphersuites)? (Y/n): Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): Will the certificate be used to sign code? (y/N): Will the certificate be used for time stamping? (y/N): Will the certificate be used for IPsec IKE operations? (y/N): Will the certificate be used to sign OCSP requests? (y/N): Is this a TLS web client certificate? (y/N): Is this a TLS web server certificate? (y/N): sign: PKCS #11 unsupported feature And the logs of the HSM are clear: >>> TW_CK [Thu Aug 03 16:59:58:127] [pid:5856 thid:4116] C_SignInit(0x01000002, {CKM_RSA_PKCS, NULL_PTR, 0x00000000}, 3) ...starting >>> TW_CK [Thu Aug 03 16:59:58:131] [pid:5856 thid:4116] C_SignInit hSession=0x01000002 hKey=3 ... completed(OK 0X0); >>> TW_CK [Thu Aug 03 16:59:58:133] [pid:5856 thid:4116] C_Sign(0x01000002 51 bytes data) ...starting >>> TW_CK [Thu Aug 03 16:59:58:136] [pid:5856 thid:4116] C_Sign hSession=0x01000002 ulDataLen=51 ulSignatureLen=256 ... completed(OK 0X0); >>> TW_CK [Thu Aug 03 16:59:58:138] [pid:5856 thid:4116] C_Sign(0x01000002 51 bytes data) ...starting >>> TW_CK [Thu Aug 03 16:59:58:141] [pid:5856 thid:4116] C_Sign ... failed (MECHANISM INVALID 0X70); Is there a parameter to tell certtool to instead use the CKM_RSA_PKCS_PSS (authorized) algorithm for signing the CSR, either via the command line or via a template file ? Regards, S?bastien HAVAS From nmav at gnutls.org Fri Aug 4 10:32:23 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Aug 2017 10:32:23 +0200 Subject: [gnutls-help] certtool - generate CSR without CKM_RSA_PKCS In-Reply-To: <8983816a-d35b-6887-da13-1ad679245591@ise.fr> References: <8983816a-d35b-6887-da13-1ad679245591@ise.fr> Message-ID: On Thu, Aug 3, 2017 at 5:52 PM, S?bastien HAVAS wrote: > Hello, > > I'm trying to generate a CSR via a RSA key pair on a HSM (ATOS BULL > Proteccio). > Due to a law, multiple constraints have been applied to the HSM, including > the deactivation of the CKM_RSA_PKCS signature algorithm. > As such, when I invoke the following command with certtool (version 3.5.8), > it fails at the end because it wanted to sign the CSR with the private key > with the CKM_RSA_PKCS algorithm. [...] > Is there a parameter to tell certtool to instead use the CKM_RSA_PKCS_PSS > (authorized) algorithm for signing the CSR, either via the command line or > via a template file ? There is no support for RSA-PSS in gnutls. Its inclusion in only planned for 3.6.0: https://gitlab.com/gnutls/gnutls/milestones/10 regards, Nikos From gregs at sloop.net Thu Aug 10 17:13:07 2017 From: gregs at sloop.net (Gregory Sloop) Date: Thu, 10 Aug 2017 08:13:07 -0700 Subject: [gnutls-help] CTL generation Message-ID: <1258181808.20170810081307@sloop.net> I *think* I understand how to use certtool to generate a CRL - however, trying to get explicit confirmation. In the case where you have more than one revoked cert: Will it work to concatenate all the revoked certs into a single file and include all the certs with one --load-certificate file-of-concatenated-certs.pem ? [It sure looks that way, but just double checking.] TIA -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Aug 11 13:30:17 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Aug 2017 13:30:17 +0200 Subject: [gnutls-help] CTL generation In-Reply-To: <1258181808.20170810081307@sloop.net> References: <1258181808.20170810081307@sloop.net> Message-ID: On Thu, Aug 10, 2017 at 5:13 PM, Gregory Sloop wrote: > I *think* I understand how to use certtool to generate a CRL - however, > trying to get explicit confirmation. > In the case where you have more than one revoked cert: > Will it work to concatenate all the revoked certs into a single file and > include all the certs with one --load-certificate > file-of-concatenated-certs.pem ? [It sure looks that way, but just double > checking.] That's the idea. Note however that some old versions of certtool had a cap on the file size they were reading, so they could choke on large files and generate incomplete CRLs. If you use anything later than 3.3.18 you should be fine. regards, Nikos From chengwei.clx at gmail.com Sat Aug 19 19:32:17 2017 From: chengwei.clx at gmail.com (Wei Cheng) Date: Sun, 20 Aug 2017 01:32:17 +0800 Subject: [gnutls-help] How to handle UDP disconnection and reconnection in DTLS Message-ID: DTLS and UDP are used between server and client. I know that DTLS is connectionless and does not attempt to detect peer failure. question one: if the client ends abnormally when the handshake is not over yet, how does the server know that client is gone? i guess that the server have to wait until the handshake timeout. question two: i have done two test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengwei.clx at gmail.com Sat Aug 19 20:14:49 2017 From: chengwei.clx at gmail.com (Wei Cheng) Date: Sun, 20 Aug 2017 02:14:49 +0800 Subject: [gnutls-help] How to handle UDP disconnection and reconnection in DTLS In-Reply-To: References: Message-ID: DTLS and UDP are used between server and client. I know that DTLS is connectionless and does not attempt to detect peer failure. question one: if the client ends abnormally when the handshake is not over yet, how does the server know that client is gone? i guess that the server have to wait until the handshake timeout. question two: i have done two tests; test one: i use "atxit()" to register a function(void newclient(void)) in main(); void newclient(void) { sysytem("./client"); } my push funciton as follows: int times; ssize_t push_func(gnutls_transport_ptr_t p, const void *data, size_t size) { if(times++ == 4) { exit(1); } return sendto(...); } result: ./client print "handshake timeout" ./server print "handshake timeout" test two: i use "atexit()" to register a function(void newclient(void)) in main(); i call "exit(1)" when the client successfully completed the handshake while server call "gnutls_record_recv()" result: ./client print "handshake timeout" ./server print "rev timeout" how should i correctly use dtls to handle the udp reconnection? i wonder if there are any examples i can refer to! thanks in advance! 2017-08-20 1:32 GMT+08:00 Wei Cheng : > DTLS and UDP are used between server and client. > > I know that DTLS is connectionless and does not attempt to detect peer > failure. > > question one: > if the client ends abnormally when the handshake is not over yet, how does > the server know that client is gone? > i guess that the server have to wait until the handshake timeout. > > question two: > i have done two test. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Aug 21 08:24:30 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Aug 2017 08:24:30 +0200 Subject: [gnutls-help] gnutls 3.5.15 Message-ID: <1503296670.9015.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.15. This is a bug fix release on the current stable branch. * Version 3.5.15 (released 2017-08-21) ** libgnutls: Disable hardware acceleration on aarch64/ilp32 mode. There is ???no assembler code included for this CPU mode. ** certtool: Keys with provable RSA and DSA parameters are now only exported ???in PKCS#8 form, following draft-mavrogiannopoulos-pkcs8-validated-parameters-00.txt. ???This removes the need for a non-standard key format. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.15.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.15.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Aug 21 09:00:04 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Aug 2017 09:00:04 +0200 Subject: [gnutls-help] GnuTLS 3.6.0 released Message-ID: <1503298804.9015.4.camel@gnutls.org> We are proud to announce a new GnuTLS release: Version 3.6.0. GnuTLS is a modern C library that implements the standard network security protocol Transport Layer Security (TLS), for use by network applications.??GnuTLS is developed for GNU/Linux, but works on many Unix-like systems as well as Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2 (or later). The project pages of the library are available at: http://www.gnutls.org/ What's New ========== Version 3.6.0 is the first release on the 3.6.x branch and is the result of a several months of planning and work on the git master branch. The GnuTLS 3.6.x branch is marked as stable-next, meaning it is considered of stable quality but does not yet replace the?current stable releases based on 3.5.x, which will continue to be supported until the 3.6.x branch replaces it. Note that, support for the new TLS 1.3 protocol will be added on the 3.6.x branch. An extended summary of the major changes is available at: http://nmav.gnutls.org/2017/08/gnutls-3-6-0.html The NEWS entries follow. * Version 3.6.0 (released 2017-08-21) ** libgnutls: tlsfuzzer is part of the CI testsuite. This is a TLS testing and fuzzying toolkit, allowing for corner case testing, and ensuring that the behavior of the library will not change across releases. https://github.com/tomato42/tlsfuzzer ** libgnutls: Introduced a lock-free random generator which operates per-thread and eliminates random-generator related bottlenecks in multi-threaded operation. Resolves gitlab issue #141. http://nmav.gnutls.org/2017/03/improving-by-simplifying-gnutls-prng.html ** libgnutls: Replaced the Salsa20 random generator with one based on CHACHA. The goal is to reduce code needed in cache (CHACHA is also used for TLS), and the number of primitives used by the library. That does not affect the AES-DRBG random generator used in FIPS140-2 mode. ** libgnutls: Added support for RSA-PSS key type as well as signatures in certificates, and TLS key exchange. Contributed by Daiki Ueno. RSA-PSS signatures can be generated by RSA-PSS keys and normal RSA keys, but not vice-versa. The feature includes: * RSA-PSS key generation and key handling (in PKCS#8 form) * RSA-PSS key generation and key handling from PKCS#11 (with CKM_RSA_PKCS_PSS mech) * Handling of RSA-PSS subjectPublicKeyInfo parameters, when present in either the private key or certificate. * RSA-PSS signing and verification of PKIX certificates * RSA-PSS signing and verification of TLS 1.2 handshake * RSA-PSS signing and verification of PKCS#7 structures * RSA-PSS and RSA key combinations for TLS credentials. That is, when multiple keys are supplied, RSA-PSS keys are preferred over RSA for RSA-PSS TLS signatures, to contain risks of cross-protocol attacks between the algorithms. * RSA-PSS key conversion to RSA PKCS#1 form (certtool --to-rsa) Note that RSA-PSS signatures with SHA1 are (intentionally) not supported. ** libgnutls: Added support for Ed25519 signing in certificates and TLS key exchange following draft-ietf-tls-rfc4492bis-17. The feature includes: * Ed25519 key generation and key handling (in PKCS#8 form) * Ed25519 signing and verification of PKIX certificates * Ed25519 signing and verification of TLS 1.2 handshake * Ed25519 signing and verification of PKCS#7 structures ** libgnutls: Enabled X25519 key exchange by default, following draft-ietf-tls-rfc4492bis-17. ** libgnutls: Added support for Diffie-Hellman group negotiation following RFC7919. That makes the DH parameters negotiation more robust and less prone to errors due to insecure parameters. Servers are no longer required to specific explicit DH parameters, though if they do these parameters will be used. Group selection can be done via priority strings. The introduced strings are GROUP-ALL, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096 and GROUP-FFDHE8192, as well as the corresponding to curves groups. Note that the 6144 group from RFC7919 is not supported. ** libgnutls: Introduced various sanity checks on certificate import. Refuse to import certificates which have fractional seconds in Time fields, X.509v1 certificates which have the unique identifiers set, and certificates with illegal version numbers. All of these are prohibited by RFC5280. ** libgnutls: Introduced gnutls_x509_crt_set_flags(). This function can set flags in the crt structure. The only flag supported at the moment is GNUTLS_X509_CRT_FLAG_IGNORE_SANITY which skips the certificate sanity checks on import. ** libgnutls: PKIX certificates with unknown critical extensions are rejected on verification with status GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS. This behavior can be overriden by providing the flag GNUTLS_VERIFY_IGNORE_UNKNOWN_CRIT_EXTENSIONS to verification functions. Resolves gitlab issue #177. ** libgnutls: Refuse to generate a certificate with an illegal version, or an illegal serial number. That is, gnutls_x509_crt_set_version() and gnutls_x509_crt_set_serial(), will fail on input considered to be invalid in RFC5280. ** libgnutls: Calls to gnutls_record_send() and gnutls_record_recv() prior to handshake being complete are now refused. Addresses gitlab issue #158. ** libgnutls: Added support for PKCS#12 files with no salt (zero length) in their password encoding, and PKCS#12 files using SHA384 and SHA512 as MAC. ** libgnutls: Exported functions to encode and decode DSA and ECDSA r,s values. ** libgnutls: Added new callback setting function to gnutls_privkey_t for external keys. The new function (gnutls_privkey_import_ext4), allows signing in addition to previous algorithms (RSA PKCS#1 1.5, DSA, ECDSA), with RSA-PSS and Ed25519 keys. ** libgnutls: Introduced the %VERIFY_ALLOW_BROKEN and %VERIFY_ALLOW_SIGN_WITH_SHA1 priority string options. These allows enabling all broken and SHA1-based signature algorithms in certificate verification, respectively. ** libgnutls: 3DES-CBC is no longer included in the default priorities list. It has to be explicitly enabled, e.g., with a string like "NORMAL:+3DES-CBC". ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification of certificates signed with SHA1 is now considered insecure and will fail, unless flags intended to enable broken algorithms are set. Other uses of SHA1 are still allowed. This can be reverted on compile time with the configure flag --enable-sha1-support. ** libgnutls: RIPEMD160 was marked as insecure for certificate signatures. Verification of certificates signed with RIPEMD160 hash algorithm is now considered insecure and will fail, unless flags intended to enable broken algorithms are set. ** libgnutls: No longer enable SECP192R1 and SECP224R1 by default on TLS handshakes. These curves were rarely used for that purpose, provide no advantage over x25519 and were deprecated by TLS 1.3. ** libgnutls: Removed support for DEFLATE, or any other compression method. ** libgnutls: OpenPGP authentication was removed; the resulting library is ABI compatible, with the openpgp related functions being stubs that fail on invocation. ** libgnutls: Removed support for libidn (i.e., IDNA2003); gnutls can now be compiled only with libidn2 which provides IDNA2008. ** certtool: The option '--load-ca-certificate' can now accept PKCS#11 URLs in addition to files. ** certtool: The option '--load-crl' can now be used when generating PKCS#12 files (i.e., in conjunction with '--to-p12' option). ** certtool: Keys with provable RSA and DSA parameters are now only read and exported from PKCS#8 form, following draft-mavrogiannopoulos-pkcs8-validated-parameters-00.txt. This removes support for the previous a non-standard key format. ** certtool: Added support for generating, printing and handling RSA-PSS and Ed25519 keys and certificates. ** certtool: the parameters --rsa, --dsa and --ecdsa to --generate-privkey are now deprecated, replaced by the --key-type option. ** p11tool: The --generate-rsa, --generate-ecc and --generate-dsa options were replaced by the --generate-privkey option. ** psktool: Generate 256-bit keys by default. ** gnutls-server: Increase request buffer size to 16kb, and added the --alpn and --alpn-fatal options, allowing testing of ALPN negotiation. ** API and ABI modifications: gnutls_encode_rs_value: Added gnutls_decode_rs_value: Added gnutls_base64_encode2: Added gnutls_base64_decode2: Added gnutls_x509_crt_set_flags: Added gnutls_x509_crt_check_ip: Added gnutls_x509_ext_import_inhibit_anypolicy: Added gnutls_x509_ext_export_inhibit_anypolicy: Added gnutls_x509_crt_get_inhibit_anypolicy: Added gnutls_x509_crt_set_inhibit_anypolicy: Added gnutls_pubkey_export_rsa_raw2: Added gnutls_pubkey_export_dsa_raw2: Added gnutls_pubkey_export_ecc_raw2: Added gnutls_privkey_export_rsa_raw2: Added gnutls_privkey_export_dsa_raw2: Added gnutls_privkey_export_ecc_raw2: Added gnutls_x509_spki_init: Added gnutls_x509_spki_deinit: Added gnutls_x509_spki_get_pk_algorithm: Added gnutls_x509_spki_set_pk_algorithm: Added gnutls_x509_spki_get_digest_algorithm: Added gnutls_x509_spki_set_digest_algorithm: Added gnutls_x509_spki_get_salt_size: Added gnutls_x509_spki_set_salt_size: Added gnutls_x509_crt_set_spki: Added gnutls_x509_crt_get_spki: Added gnutls_x509_privkey_get_spki: Added gnutls_x509_privkey_set_spki: Added gnutls_x509_crq_get_spki: Added gnutls_x509_crq_set_spki: Added gnutls_pubkey_set_spki: Added gnutls_pubkey_get_spki: Added gnutls_privkey_set_spki: Added gnutls_privkey_get_spki: Added gnutls_privkey_import_ext4: Added GNUTLS_EXPORT_FLAG_NO_LZ: Added GNUTLS_DT_IP_ADDRESS: Added GNUTLS_X509_CRT_FLAG_IGNORE_SANITY: Added GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS: Added GNUTLS_VERIFY_ALLOW_SIGN_WITH_SHA1: Added GNUTLS_VERIFY_DO_NOT_ALLOW_IP_MATCHES: Added GNUTLS_VERIFY_IGNORE_UNKNOWN_CRIT_EXTENSIONS: Added GNUTLS_SFLAGS_RFC7919: Added Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: ? http://lists.gnutls.org/mailman/listinfo/gnutls-help If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: ? http://lists.gnutls.org/mailman/listinfo/gnutls-dev Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Italian, Malay, Polish, Simplified Chinese, Swedish, and Vietnamese.??We welcome the addition of more translations. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.0.tar.xz ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.6/gnutls-3.6.0.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.0.tar.xz.sig ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.6/gnutls-3.6.0.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From anpassung at 163.com Fri Aug 25 13:57:29 2017 From: anpassung at 163.com (=?GBK?B?1qq69cnqy9+0psDt?=) Date: Fri, 25 Aug 2017 19:57:29 +0800 (CST) Subject: [gnutls-help] A potentially newbie question about gnutls package version in CentOS 7.x Message-ID: <612a99a8.91e5.15e19411808.Coremail.anpassung@163.com> I've been dubbing with security vulnerabilities and their fix for a while, recently I stumbled upon this CVE-2017-5335. In redhat official notice board :https://access.redhat.com/security/cve/cve-2017-5335 we can see there is a link point to advisory for CentOS7.x: https://access.redhat.com/errata/RHSA-2017:2292 . from there we can see that the fix happens at gnutls 3.3.26. But when trying to update from commandline, there is no 3.3.26 available for CentOS 7.x. this can be verified using rpm finder: https://www.rpmfind.net/linux/rpm2html/search.php?query=gnutls Only available rpm for CentOS 7.x is 3.3.24. Why is that? and is someone dealing with this problem? - p.s. this is my first mail in mailinglist, excuse me for any formating issues, if you will :) Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Sun Aug 27 15:42:46 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 27 Aug 2017 15:42:46 +0200 Subject: [gnutls-help] A potentially newbie question about gnutls package version in CentOS 7.x In-Reply-To: <612a99a8.91e5.15e19411808.Coremail.anpassung@163.com> References: <612a99a8.91e5.15e19411808.Coremail.anpassung@163.com> Message-ID: <1503841366.2059.2.camel@gmail.com> On Fri, 2017-08-25 at 19:57 +0800, ?????? wrote: > I've been dubbing with security vulnerabilities and their fix for a > while, recently I stumbled upon this CVE-2017-5335.? > > In redhat official notice board :https://access.redhat.com/security/c > ve/cve-2017-5335? we can see there is a link point to advisory for > CentOS7.x:?https://access.redhat.com/errata/RHSA-2017:2292?. from > there we can see that the fix happens at gnutls 3.3.26. ? > > But when trying to update from commandline, there is no 3.3.26 > available for CentOS 7.x. ? this can be verified using rpm finder:?ht > tps://www.rpmfind.net/linux/rpm2html/search.php?query=gnutls > Only available rpm for CentOS 7.x is 3.3.24. The RHEL advisories apply to RHEL. CentOS typically follows up, but it has its own release cycle. You'd better check with centos project on the details. regards, Nikos From 1.int32 at gmail.com Mon Aug 28 10:08:38 2017 From: 1.int32 at gmail.com (=?UTF-8?B?QmFsw6F6cyBLw6lyaQ==?=) Date: Mon, 28 Aug 2017 10:08:38 +0200 Subject: [gnutls-help] failing DTLS handshake Message-ID: Hi! I have a case when DTLS handshake is performed and GnuTLS server side seems to not send out the last messages. the observed message sequence: client->server: ClientHello (total 164 bytes) server->client: ServerHello,Certificate,CertificateRequest,ServerHelloDone (total 1159 bytes) client->server: Certificate(Fragment)(243),Certificate(Fragment)(243),Cer tificate(Fragment)(243),Certificate(Fragment)(243),Certifica te(Fragment)(13),ClientKeyExchange(142),CertificateVerify(62), CertificateVerify(92) (total 1427 bytes) client->server: ChangeCipherSpec(1),EncryptedHandshakeMessage(64) (total 133 bytes) (The last EncryptedHandshakeMessage is probably a Finished.) At this point the server should send the ChangeCipherSpec or any other message, but it does send nothing. According to the log the correct data is passed to GnuTLS by the 'pull' function, but the 'gnutls_handshake' function returns EAGAIN repeatedly without continuing the handshake sequence (the 'push' is not called). The GnuTLS log messages are in the attached log file. Following seems to be problematic (the last one is printed after the last EncryptedHandshakeMessage is received, the other after the last fragment of Certificate was received with fragment length of 1 byte): 533 [2017-Aug-24 10:13:38.768873] GnuTLS -- [level:1]: Invalid handshake packet headers. Discarding. 569 [2017-Aug-24 10:13:38.770813] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Discarded duplicate message[1.0]: Handshake The problem happens with GnuTLS 3.3.19, 3.3.28 and 3.5.15 too (logs are from version 3.3.15). What could be wrong here? Bal?zs K?ri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 399 [2017-Aug-24 10:13:38.761385] GnuTLS -- [level:3]: ASSERT: constate.c[_gnutls_epoch_get]:600 400 [2017-Aug-24 10:13:38.761413] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Allocating epoch #1 401 [2017-Aug-24 10:13:38.761439] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1163 402 [2017-Aug-24 10:13:38.761468] pull 122 bytes 403 [2017-Aug-24 10:13:38.761498] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 109 404 [2017-Aug-24 10:13:38.761521] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 405 [2017-Aug-24 10:13:38.761543] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 109 406 [2017-Aug-24 10:13:38.761627] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.3] Handshake(22) with length: 109 407 [2017-Aug-24 10:13:38.761665] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CLIENT HELLO (1) was received. Length 97[97], frag offset 0, frag length: 97, sequence: 0 408 [2017-Aug-24 10:13:38.761694] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Client's version: 254.253 409 [2017-Aug-24 10:13:38.761734] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Selected version DTLS1.0 410 [2017-Aug-24 10:13:38.761768] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Found extension 'Signature Algorithms/13' 411 [2017-Aug-24 10:13:38.761790] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Found extension 'SRTP/14' 412 [2017-Aug-24 10:13:38.761812] GnuTLS -- [level:3]: ASSERT: db.c[_gnutls_server_restore_session]:272 413 [2017-Aug-24 10:13:38.761835] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Found extension 'Signature Algorithms/13' 414 [2017-Aug-24 10:13:38.761857] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Parsing extension 'SRTP/14' (7 bytes) 415 [2017-Aug-24 10:13:38.761881] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Parsing extension 'Signature Algorithms/13' (32 bytes) 416 [2017-Aug-24 10:13:38.761909] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (6.1) RSA-SHA512 417 [2017-Aug-24 10:13:38.761932] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (6.2) DSA-SHA512 418 [2017-Aug-24 10:13:38.761953] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (6.3) ECDSA-SHA512 419 [2017-Aug-24 10:13:38.761975] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (5.1) RSA-SHA384 420 [2017-Aug-24 10:13:38.761997] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (5.2) DSA-SHA384 421 [2017-Aug-24 10:13:38.762018] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (5.3) ECDSA-SHA384 422 [2017-Aug-24 10:13:38.762040] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (4.1) RSA-SHA256 423 [2017-Aug-24 10:13:38.762061] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (4.2) DSA-SHA256 424 [2017-Aug-24 10:13:38.762082] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (4.3) ECDSA-SHA256 425 [2017-Aug-24 10:13:38.762103] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (3.1) RSA-SHA224 426 [2017-Aug-24 10:13:38.762138] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (3.2) DSA-SHA224 427 [2017-Aug-24 10:13:38.762161] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (3.3) ECDSA-SHA224 428 [2017-Aug-24 10:13:38.762182] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (2.1) RSA-SHA1 429 [2017-Aug-24 10:13:38.762203] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (2.2) DSA-SHA1 430 [2017-Aug-24 10:13:38.762224] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: rcvd signature algo (2.3) ECDSA-SHA1 431 [2017-Aug-24 10:13:38.762246] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Found extension 'SRTP/14' 432 [2017-Aug-24 10:13:38.762268] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Received safe renegotiation CS 433 [2017-Aug-24 10:13:38.762417] GnuTLS -- [level:3]: ASSERT: server_name.c[gnutls_server_name_get]:310 434 [2017-Aug-24 10:13:38.762443] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Requested server name: '' 435 [2017-Aug-24 10:13:38.762475] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1) 436 [2017-Aug-24 10:13:38.762499] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1) 437 [2017-Aug-24 10:13:38.762533] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Keeping ciphersuite: GNUTLS_RSA_AES_256_CBC_SHA1 (00.35) 438 [2017-Aug-24 10:13:38.762556] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_256_CBC_SHA1 (00.84) 439 [2017-Aug-24 10:13:38.762577] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Keeping ciphersuite: GNUTLS_RSA_AES_128_CBC_SHA1 (00.2F) 440 [2017-Aug-24 10:13:38.762599] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Keeping ciphersuite: GNUTLS_RSA_CAMELLIA_128_CBC_SHA1 (00.41) 441 [2017-Aug-24 10:13:38.762621] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Keeping ciphersuite: GNUTLS_RSA_3DES_EDE_CBC_SHA1 (00.0A) 442 [2017-Aug-24 10:13:38.762644] GnuTLS -- [level:3]: ASSERT: ciphersuites.c[check_server_params]:1300 443 [2017-Aug-24 10:13:38.762665] GnuTLS -- [level:3]: ASSERT: ciphersuites.c[check_server_params]:1300 444 [2017-Aug-24 10:13:38.762688] GnuTLS -- [level:3]: ASSERT: ciphersuites.c[check_server_params]:1300 445 [2017-Aug-24 10:13:38.762709] GnuTLS -- [level:3]: ASSERT: ciphersuites.c[check_server_params]:1300 446 [2017-Aug-24 10:13:38.762730] GnuTLS -- [level:3]: ASSERT: ciphersuites.c[check_server_params]:1300 447 [2017-Aug-24 10:13:38.762751] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Requested cipher suites[size: 8]: 448 [2017-Aug-24 10:13:38.762772] GnuTLS -- [level:4]: 0x00, 0x2f RSA_AES_128_CBC_SHA1 449 [2017-Aug-24 10:13:38.762794] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Selected cipher suite: RSA_AES_128_CBC_SHA1 450 [2017-Aug-24 10:13:38.762820] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Selected Compression Method: NULL 451 [2017-Aug-24 10:13:38.762842] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Found extension 'Signature Algorithms/13' 452 [2017-Aug-24 10:13:38.762863] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Found extension 'SRTP/14' 453 [2017-Aug-24 10:13:38.762896] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: Safe renegotiation succeeded 454 [2017-Aug-24 10:13:38.762927] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Sending extension Safe Renegotiation (1 bytes) 455 [2017-Aug-24 10:13:38.762951] GnuTLS -- [level:4]: EXT[0x7f9ce0013ea0]: Sending extension SRTP (5 bytes) 456 [2017-Aug-24 10:13:38.762987] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: SessionID: 7c34816fe1ca5d1fde2ebed4f63a19884faf0e063788e58c7fec7c61b100e146 457 [2017-Aug-24 10:13:38.763010] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: SERVER HELLO was queued [98 bytes] 458 [2017-Aug-24 10:13:38.763038] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE was queued [937 bytes] 459 [2017-Aug-24 10:13:38.763066] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE REQUEST was queued [18 bytes] 460 [2017-Aug-24 10:13:38.763088] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: SERVER HELLO DONE was queued [12 bytes] 461 [2017-Aug-24 10:13:38.763112] GnuTLS -- [level:6]: DTLS[0x7f9ce0013ea0]: Start of flight transmission. 462 [2017-Aug-24 10:13:38.763139] GnuTLS -- [level:6]: DTLS[0x7f9ce0013ea0]: Sending Packet[0] fragment SERVER HELLO(2) with length: 86, offset: 0, fragment length: 86, mtu: 1427 463 [2017-Aug-24 10:13:38.763163] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Preparing Packet Handshake(22) with length: 98 and min pad: 0 464 [2017-Aug-24 10:13:38.763186] GnuTLS -- [level:9]: ENC[0x7f9ce0013ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 465 [2017-Aug-24 10:13:38.763210] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 111 466 [2017-Aug-24 10:13:38.763234] GnuTLS -- [level:6]: DTLS[0x7f9ce0013ea0]: Sending Packet[1] fragment CERTIFICATE(11) with length: 925, offset: 0, fragment length: 925, mtu: 1427 467 [2017-Aug-24 10:13:38.763258] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Preparing Packet Handshake(22) with length: 937 and min pad: 0 468 [2017-Aug-24 10:13:38.763280] GnuTLS -- [level:9]: ENC[0x7f9ce0013ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 469 [2017-Aug-24 10:13:38.763303] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Sent Packet[2] Handshake(22) in epoch 0 and length: 950 470 [2017-Aug-24 10:13:38.763326] GnuTLS -- [level:6]: DTLS[0x7f9ce0013ea0]: Sending Packet[2] fragment CERTIFICATE REQUEST(13) with length: 6, offset: 0, fragment length: 6, mtu: 1427 471 [2017-Aug-24 10:13:38.763349] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Preparing Packet Handshake(22) with length: 18 and min pad: 0 472 [2017-Aug-24 10:13:38.763371] GnuTLS -- [level:9]: ENC[0x7f9ce0013ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 473 [2017-Aug-24 10:13:38.763393] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Sent Packet[3] Handshake(22) in epoch 0 and length: 31 474 [2017-Aug-24 10:13:38.763416] GnuTLS -- [level:6]: DTLS[0x7f9ce0013ea0]: Sending Packet[3] fragment SERVER HELLO DONE(14) with length: 0, offset: 0, fragment length: 0, mtu: 1427 475 [2017-Aug-24 10:13:38.763439] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Preparing Packet Handshake(22) with length: 12 and min pad: 0 476 [2017-Aug-24 10:13:38.763460] GnuTLS -- [level:9]: ENC[0x7f9ce0013ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 477 [2017-Aug-24 10:13:38.763482] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Sent Packet[4] Handshake(22) in epoch 0 and length: 25 478 [2017-Aug-24 10:13:38.763552] push_vec 1117 480 [2017-Aug-24 10:13:38.763616] GnuTLS -- [level:3]: ASSERT: dtls.c[_dtls_transmit]:420 481 [2017-Aug-24 10:13:38.763636] handshake - after 485 [2017-Aug-24 10:13:38.764741] handshake - before 486 [2017-Aug-24 10:13:38.764802] GnuTLS -- [level:3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 488 [2017-Aug-24 10:13:38.764847] GnuTLS -- [level:3]: ASSERT: dtls.c[_dtls_transmit]:263 489 [2017-Aug-24 10:13:38.764867] GnuTLS -- [level:3]: ASSERT: dtls.c[_dtls_transmit]:420 490 [2017-Aug-24 10:13:38.764885] handshake - after 497 [2017-Aug-24 10:13:38.767992] handshake - before 498 [2017-Aug-24 10:13:38.768053] GnuTLS -- [level:3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694 500 [2017-Aug-24 10:13:38.768101] pull 1385 bytes 501 [2017-Aug-24 10:13:38.768127] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 243 502 [2017-Aug-24 10:13:38.768150] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 503 [2017-Aug-24 10:13:38.768172] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 243 504 [2017-Aug-24 10:13:38.768198] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.4] Handshake(22) with length: 243 505 [2017-Aug-24 10:13:38.768224] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE (11) was received. Length 925[231], frag offset 0, frag length: 231, sequence: 1 506 [2017-Aug-24 10:13:38.768250] GnuTLS -- [level:6]: DTLS[0x7f9ce0013ea0]: End of flight transmission. 507 [2017-Aug-24 10:13:38.768275] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 508 [2017-Aug-24 10:13:38.768298] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 243 509 [2017-Aug-24 10:13:38.768335] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 510 [2017-Aug-24 10:13:38.768358] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 243 511 [2017-Aug-24 10:13:38.768384] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.5] Handshake(22) with length: 243 512 [2017-Aug-24 10:13:38.768408] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE (11) was received. Length 925[231], frag offset 231, frag length: 231, sequence: 1 513 [2017-Aug-24 10:13:38.768432] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 514 [2017-Aug-24 10:13:38.768455] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 243 515 [2017-Aug-24 10:13:38.768476] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 516 [2017-Aug-24 10:13:38.768497] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 243 517 [2017-Aug-24 10:13:38.768520] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.6] Handshake(22) with length: 243 518 [2017-Aug-24 10:13:38.768544] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE (11) was received. Length 925[231], frag offset 462, frag length: 231, sequence: 1 519 [2017-Aug-24 10:13:38.768567] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 520 [2017-Aug-24 10:13:38.768589] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 243 521 [2017-Aug-24 10:13:38.768610] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 522 [2017-Aug-24 10:13:38.768631] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 243 523 [2017-Aug-24 10:13:38.768654] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.7] Handshake(22) with length: 243 524 [2017-Aug-24 10:13:38.768677] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE (11) was received. Length 925[231], frag offset 693, frag length: 231, sequence: 1 525 [2017-Aug-24 10:13:38.768700] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 526 [2017-Aug-24 10:13:38.768722] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 13 527 [2017-Aug-24 10:13:38.768744] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 528 [2017-Aug-24 10:13:38.768764] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 13 529 [2017-Aug-24 10:13:38.768787] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.8] Handshake(22) with length: 13 530 [2017-Aug-24 10:13:38.768811] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE (11) was received. Length 925[1], frag offset 924, frag length: 1, sequence: 1 531 [2017-Aug-24 10:13:38.768832] GnuTLS -- [level:3]: ASSERT: buffers.c[parse_handshake_header]:961 532 [2017-Aug-24 10:13:38.768852] GnuTLS -- [level:3]: ASSERT: buffers.c[_gnutls_parse_record_buffered_msgs]:1292 533 [2017-Aug-24 10:13:38.768873] GnuTLS -- [level:1]: Invalid handshake packet headers. Discarding. 534 [2017-Aug-24 10:13:38.768893] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 535 [2017-Aug-24 10:13:38.768926] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 142 536 [2017-Aug-24 10:13:38.768949] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 537 [2017-Aug-24 10:13:38.768970] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 142 538 [2017-Aug-24 10:13:38.768995] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.9] Handshake(22) with length: 142 539 [2017-Aug-24 10:13:38.769019] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CLIENT KEY EXCHANGE (16) was received. Length 130[130], frag offset 0, frag length: 130, sequence: 2 540 [2017-Aug-24 10:13:38.769055] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 541 [2017-Aug-24 10:13:38.769080] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 62 542 [2017-Aug-24 10:13:38.769101] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 543 [2017-Aug-24 10:13:38.769121] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 62 544 [2017-Aug-24 10:13:38.769144] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.10] Handshake(22) with length: 62 545 [2017-Aug-24 10:13:38.769168] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE VERIFY (15) was received. Length 130[50], frag offset 0, frag length: 50, sequence: 3 546 [2017-Aug-24 10:13:38.769192] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 547 [2017-Aug-24 10:13:38.769214] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 0, length: 92 548 [2017-Aug-24 10:13:38.769235] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 549 [2017-Aug-24 10:13:38.769255] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 92 550 [2017-Aug-24 10:13:38.769279] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.11] Handshake(22) with length: 92 551 [2017-Aug-24 10:13:38.769302] GnuTLS -- [level:4]: HSK[0x7f9ce0013ea0]: CERTIFICATE VERIFY (15) was received. Length 130[80], frag offset 50, frag length: 80, sequence: 3 552 [2017-Aug-24 10:13:38.769326] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1163 553 [2017-Aug-24 10:13:38.769346] handshake - after 556 [2017-Aug-24 10:13:38.770447] handshake - before 557 [2017-Aug-24 10:13:38.770510] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1163 558 [2017-Aug-24 10:13:38.770539] pull 91 bytes 559 [2017-Aug-24 10:13:38.770565] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 ChangeCipherSpec packet received. Epoch 0, length: 1 560 [2017-Aug-24 10:13:38.770588] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 561 [2017-Aug-24 10:13:38.770609] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet ChangeCipherSpec(20) with length: 1 562 [2017-Aug-24 10:13:38.770651] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Decrypted Packet[0.12] ChangeCipherSpec(20) with length: 1 563 [2017-Aug-24 10:13:38.770677] GnuTLS -- [level:3]: ASSERT: buffers.c[_gnutls_parse_record_buffered_msgs]:1282 564 [2017-Aug-24 10:13:38.770701] GnuTLS -- [level:3]: ASSERT: buffers.c[get_last_packet]:1139 565 [2017-Aug-24 10:13:38.770724] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: SSL 254.255 Handshake packet received. Epoch 1, length: 64 566 [2017-Aug-24 10:13:38.770746] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Expected Packet Handshake(22) 567 [2017-Aug-24 10:13:38.770767] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Received Packet Handshake(22) with length: 64 568 [2017-Aug-24 10:13:38.770791] GnuTLS -- [level:3]: ASSERT: dtls-sw.c[_dtls_record_check]:73 569 [2017-Aug-24 10:13:38.770813] GnuTLS -- [level:5]: REC[0x7f9ce0013ea0]: Discarded duplicate message[1.0]: Handshake 570 [2017-Aug-24 10:13:38.770834] GnuTLS -- [level:3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1345 571 [2017-Aug-24 10:13:38.770853] handshake - after From gregs at sloop.net Mon Aug 28 21:11:36 2017 From: gregs at sloop.net (Gregory Sloop) Date: Mon, 28 Aug 2017 12:11:36 -0700 Subject: [gnutls-help] Windows binaries security/checksum Message-ID: <1633727949.20170828121136@sloop.net> Nikos... Is it possible to generate checksums for the Windows binaries so we can verify downloads have not been tampered with? [This seems like the easiest/least-hassle option I can think of.] SHA-256 I suppose? I'd probably want checksums anyway - but with a non secure FTP it worries me quite a lot more... Sorry for all the questions/queries/wants... Most importantly: Thanks for a nice tool! TIA -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Tue Aug 29 11:06:49 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 29 Aug 2017 11:06:49 +0200 Subject: [gnutls-help] failing DTLS handshake In-Reply-To: References: Message-ID: <1503997609.6018.2.camel@gmail.com> On Mon, 2017-08-28 at 10:08 +0200, Bal?zs K?ri wrote: > Hi! > 533 [2017-Aug-24 10:13:38.768873] ?GnuTLS -- [level:1]: Invalid > handshake packet headers. Discarding. > 569 [2017-Aug-24 10:13:38.770813] ?GnuTLS -- [level:5]: > REC[0x7f9ce0013ea0]: Discarded duplicate message[1.0]: Handshake Check what the sent client record numbers are. That message was detected as duplicate. regards, Nikos From nmav at gnutls.org Tue Aug 29 11:35:39 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 29 Aug 2017 11:35:39 +0200 Subject: [gnutls-help] Windows binaries security/checksum In-Reply-To: <1633727949.20170828121136@sloop.net> References: <1633727949.20170828121136@sloop.net> Message-ID: <1503999339.6018.4.camel@gnutls.org> On Mon, 2017-08-28 at 12:11 -0700, Gregory Sloop wrote: > Nikos... > > Is it possible to generate checksums for the Windows binaries so we > can verify downloads have not been tampered with? > [This seems like the easiest/least-hassle option I can think of.] > SHA-256 I suppose? > I'd probably want checksums anyway - but with a non secure FTP it > worries me quite a lot more... Hi, I'd like to stop distributing these binaries on ftp and switch to linking directly to the binaries generated during the CI run. For example: https://gitlab.com/gnutls/gnutls/builds/artifacts/gnutls_3_6_0_1/download?job=MinGW64/DLLs https://gitlab.com/gnutls/gnutls/builds/artifacts/gnutls_3_6_0_1/download?job=MinGW32/DLLs That would not address signing the binaries (couldn't really do as gitlab runners are not under our full control), but would provide the binaries over https, and would automate the process allowing to access the binaries of a release without delay, and without requiring manual generation. regards, Nikos From 1.int32 at gmail.com Tue Aug 29 11:40:13 2017 From: 1.int32 at gmail.com (=?UTF-8?B?QmFsw6F6cyBLw6lyaQ==?=) Date: Tue, 29 Aug 2017 11:40:13 +0200 Subject: [gnutls-help] failing DTLS handshake In-Reply-To: <1503997609.6018.2.camel@gmail.com> References: <1503997609.6018.2.camel@gmail.com> Message-ID: Hi, Here is more data included: sequence numbers in format [epoch.sequence] The client sends more ClientHello (these are discarded) before the server is connected and ready to receive messages. The client and server are started cleanly (no message exchange happens before). The message with epoch 1 is detected as duplicate but I do not see messages with epoch 1 before it. Fragment offsets and fragment lengths looks OK. client->server: ClientHello[0.0] (total 164 bytes) client->server: ClientHello[0.1] (total 164 bytes) client->server: ClientHello[0.2] (total 164 bytes) client->server: ClientHello[0.3] (total 164 bytes) server->client: ServerHello[0.0],Certificate[0.1],Certif icateRequest[0.2],ServerHelloDone[0.3] (total 1159 bytes) client->server: Certificate(Fragment)(243)[0.4],Certificate(Fragment)(243)[0.5],Certif icate(Fragment)(243)[0.6],Certificate(Fragment)(243)[0.7],Certificate( Fragment)(13)[0.8],ClientKeyExchange(142)[0.9],CertificateVerify(62)[0.10],C ertificateVerify(92)[0.11] (total 1427 bytes) client->server: ChangeCipherSpec(1)[0.12],EncryptedHandshakeMessage(64)[1.0] (total 133 bytes) Bal?zs K?ri 2017-08-29 11:06 GMT+02:00 Nikos Mavrogiannopoulos < n.mavrogiannopoulos at gmail.com>: > On Mon, 2017-08-28 at 10:08 +0200, Bal?zs K?ri wrote: > > Hi! > > > 533 [2017-Aug-24 10:13:38.768873] GnuTLS -- [level:1]: Invalid > > handshake packet headers. Discarding. > > 569 [2017-Aug-24 10:13:38.770813] GnuTLS -- [level:5]: > > REC[0x7f9ce0013ea0]: Discarded duplicate message[1.0]: Handshake > > Check what the sent client record numbers are. That message was > detected as duplicate. > > regards, > Nikos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.hoffmann at cartelsol.com Tue Aug 29 12:39:35 2017 From: m.hoffmann at cartelsol.com (Marcus Hoffmann) Date: Tue, 29 Aug 2017 12:39:35 +0200 Subject: [gnutls-help] Windows binaries security/checksum In-Reply-To: <1503999339.6018.4.camel@gnutls.org> References: <1633727949.20170828121136@sloop.net> <1503999339.6018.4.camel@gnutls.org> Message-ID: <4643a800-ba56-0a93-893e-42569909565e@cartelsol.com> Hey Nikos, On 29.08.2017 11:35, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-08-28 at 12:11 -0700, Gregory Sloop wrote: >> Nikos... >> >> Is it possible to generate checksums for the Windows binaries so we >> can verify downloads have not been tampered with? >> [This seems like the easiest/least-hassle option I can think of.] >> SHA-256 I suppose? >> I'd probably want checksums anyway - but with a non secure FTP it >> worries me quite a lot more... > > Hi, > I'd like to stop distributing these binaries on ftp and switch to > linking directly to the binaries generated during the CI run. For > example: > > https://gitlab.com/gnutls/gnutls/builds/artifacts/gnutls_3_6_0_1/download?job=MinGW64/DLLs > https://gitlab.com/gnutls/gnutls/builds/artifacts/gnutls_3_6_0_1/download?job=MinGW32/DLLs You can use a name: entry in the .gitlab-ci.yml to have a more specific name for the archive than artifacts.zip Here is a list of variables which are useful for specifying the name: https://docs.gitlab.com/ee/ci/variables/ We use name: "${CI_PROJECT_NAME}_${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_SHA}" but that might be a bit verbose. [...] > > regards, > Nikos Best wishes, Marcus From nmav at gnutls.org Tue Aug 29 14:17:46 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 29 Aug 2017 14:17:46 +0200 Subject: [gnutls-help] Windows binaries security/checksum In-Reply-To: <4643a800-ba56-0a93-893e-42569909565e@cartelsol.com> References: <1633727949.20170828121136@sloop.net> <1503999339.6018.4.camel@gnutls.org> <4643a800-ba56-0a93-893e-42569909565e@cartelsol.com> Message-ID: <1504009066.8488.1.camel@gnutls.org> On Tue, 2017-08-29 at 12:39 +0200, Marcus Hoffmann wrote: > > You can use a name: entry in the .gitlab-ci.yml to have a more > specific > name for the archive than artifacts.zip > > Here is a list of variables which are useful for specifying the name: > https://docs.gitlab.com/ee/ci/variables/ > > We use > name: > "${CI_PROJECT_NAME}_${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}_${CI_COMMIT_ > SHA}" > Nice hint, thanks.