From martin at martin.st Thu Nov 1 00:34:55 2012 From: martin at martin.st (Martin Storsjo) Date: Thu, 1 Nov 2012 01:34:55 +0200 Subject: [PATCH v2 2/2] Support SRTP profile negotiation in the client and server tools In-Reply-To: <1351726495-55549-1-git-send-email-martin@martin.st> References: <1351726495-55549-1-git-send-email-martin@martin.st> Message-ID: <1351726495-55549-2-git-send-email-martin@martin.st> The cli/serv-args files haven't been regenerated in the patch, to avoid the extra stray changes due to differing autogen versions. --- src/cli-args.def | 7 +++++++ src/cli.c | 3 +++ src/common.c | 7 ++++++- src/serv-args.def | 7 +++++++ src/serv.c | 3 +++ 5 files changed, 26 insertions(+), 1 deletion(-) diff --git a/src/cli-args.def b/src/cli-args.def index 85952d7..8fafbf4 100644 --- a/src/cli-args.def +++ b/src/cli-args.def @@ -113,6 +113,13 @@ flag = { }; flag = { + name = srtp_profiles; + arg-type = string; + descrip = "Offer SRTP profiles"; + doc = ""; +}; + +flag = { name = crlf; descrip = "Send CR LF instead of LF"; doc = ""; diff --git a/src/cli.c b/src/cli.c index a454606..d60a563 100644 --- a/src/cli.c +++ b/src/cli.c @@ -675,6 +675,9 @@ init_tls_session (const char *hostname) if (HAVE_OPT(HEARTBEAT)) gnutls_heartbeat_enable (session, GNUTLS_HB_PEER_ALLOWED_TO_SEND); + if (HAVE_OPT(SRTP_PROFILES)) + gnutls_srtp_set_profile_direct (session, OPT_ARG(SRTP_PROFILES), NULL); + return session; } diff --git a/src/common.c b/src/common.c index 3e8932a..4705c86 100644 --- a/src/common.c +++ b/src/common.c @@ -456,6 +456,8 @@ print_info (gnutls_session_t session, int verbose, int print_cert) gnutls_kx_algorithm_t kx; unsigned char session_id[33]; size_t session_id_size = sizeof (session_id); + gnutls_srtp_profile_t srtp_profile; + int rc; /* print session ID */ gnutls_session_get_id (session, session_id, &session_id_size); @@ -551,10 +553,13 @@ print_info (gnutls_session_t session, int verbose, int print_cert) (gnutls_compression_get (session))); printf ("- Compression: %s\n", tmp); + rc = gnutls_srtp_get_selected_profile (session, &srtp_profile); + if (rc == 0) + printf ("- SRTP profile: %s\n", gnutls_srtp_get_profile_name (srtp_profile)); + if (verbose) { gnutls_datum_t cb; - int rc; rc = gnutls_session_channel_binding (session, GNUTLS_CB_TLS_UNIQUE, &cb); diff --git a/src/serv-args.def b/src/serv-args.def index df196ba..2132ca8 100644 --- a/src/serv-args.def +++ b/src/serv-args.def @@ -62,6 +62,13 @@ flag = { }; flag = { + name = srtp_profiles; + arg-type = string; + descrip = "Offer SRTP profiles"; + doc = ""; +}; + +flag = { name = disable-client-cert; value = a; descrip = "Do not request a client certificate"; diff --git a/src/serv.c b/src/serv.c index 6be7a6d..7bf349b 100644 --- a/src/serv.c +++ b/src/serv.c @@ -393,6 +393,9 @@ gnutls_session_t initialize_session (int dtls) if (HAVE_OPT (HEARTBEAT)) gnutls_heartbeat_enable(session, GNUTLS_HB_PEER_ALLOWED_TO_SEND); + if (HAVE_OPT (SRTP_PROFILES)) + gnutls_srtp_set_profile_direct (session, OPT_ARG(SRTP_PROFILES), NULL); + return session; } -- 1.7.9.4 From martin at martin.st Thu Nov 1 00:34:54 2012 From: martin at martin.st (Martin Storsjo) Date: Thu, 1 Nov 2012 01:34:54 +0200 Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) Message-ID: <1351726495-55549-1-git-send-email-martin@martin.st> --- Implemented what was suggested before, and moved some hunks that I accidentally had placed in patch 2/2 in the previous patchset. --- NEWS | 6 + doc/Makefile.am | 10 + doc/protocol/rfc5764.txt | 1459 +++++++++++++++++++++++++++++++++++++++ lib/ext/Makefile.am | 2 +- lib/ext/srtp.c | 465 +++++++++++++ lib/ext/srtp.h | 38 + lib/gnutls_extensions.c | 5 + lib/gnutls_int.h | 1 + lib/includes/gnutls/gnutls.h.in | 30 + lib/libgnutls.map | 5 + 10 files changed, 2020 insertions(+), 1 deletion(-) create mode 100644 doc/protocol/rfc5764.txt create mode 100644 lib/ext/srtp.c create mode 100644 lib/ext/srtp.h diff --git a/NEWS b/NEWS index 20eb366..b89d6e0 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,12 @@ gnutls_certificate_verification_status_print: Added GNUTLS_CERT_REVOCATION_DATA_TOO_OLD: Added GNUTLS_CERT_REVOCATION_DATA_INVALID: Added GNUTLS_CERT_UNEXPECTED_OWNER: Added +gnutls_srtp_profile_t: Added +gnutls_srtp_set_profile: Added +gnutls_srtp_set_profile_direct: Added +gnutls_srtp_get_selected_profile: Added +gnutls_srtp_get_profile_name: Added +gnutls_srtp_get_profile_by_name: Added * Version 3.1.3 (released 2012-10-12) diff --git a/doc/Makefile.am b/doc/Makefile.am index 13e4454..400c183 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1616,6 +1616,16 @@ FUNCS += functions/gnutls_srp_set_server_credentials_function FUNCS += functions/gnutls_srp_set_server_credentials_function.short FUNCS += functions/gnutls_srp_verifier FUNCS += functions/gnutls_srp_verifier.short +FUNCS += functions/gnutls_srtp_get_profile_by_name +FUNCS += functions/gnutls_srtp_get_profile_by_name.short +FUNCS += functions/gnutls_srtp_get_profile_name +FUNCS += functions/gnutls_srtp_get_profile_name.short +FUNCS += functions/gnutls_srtp_get_selected_profile +FUNCS += functions/gnutls_srtp_get_selected_profile.short +FUNCS += functions/gnutls_srtp_set_profile +FUNCS += functions/gnutls_srtp_set_profile.short +FUNCS += functions/gnutls_srtp_set_profile_direct +FUNCS += functions/gnutls_srtp_set_profiles_direct.short FUNCS += functions/gnutls_store_commitment FUNCS += functions/gnutls_store_commitment.short FUNCS += functions/gnutls_store_pubkey diff --git a/doc/protocol/rfc5764.txt b/doc/protocol/rfc5764.txt new file mode 100644 index 0000000..6633f00 --- /dev/null +++ b/doc/protocol/rfc5764.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Engineering Task Force (IETF) D. McGrew +Request for Comments: 5764 Cisco Systems +Category: Standards Track E. Rescorla +ISSN: 2070-1721 RTFM, Inc. + May 2010 + + + Datagram Transport Layer Security (DTLS) Extension to Establish Keys + for the Secure Real-time Transport Protocol (SRTP) + +Abstract + + This document describes a Datagram Transport Layer Security (DTLS) + extension to establish keys for Secure RTP (SRTP) and Secure RTP + Control Protocol (SRTCP) flows. DTLS keying happens on the media + path, independent of any out-of-band signalling channel present. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5764. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +McGrew & Rescorla Standards Track [Page 1] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 + 3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4 + 4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5 + 4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5 + 4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7 + 4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8 + 4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12 + 5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13 + 5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13 + 5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16 + 6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17 + 7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17 + 7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18 + 7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18 + 7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19 + 8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23 + Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24 + + + + + +McGrew & Rescorla Standards Track [Page 2] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +1. Introduction + + The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality, + message authentication, and replay protection to RTP data and RTP + Control (RTCP) traffic. SRTP does not provide key management + functionality, but instead depends on external key management to + exchange secret master keys, and to negotiate the algorithms and + parameters for use with those keys. + + Datagram Transport Layer Security (DTLS) [RFC4347] is a channel + security protocol that offers integrated key management, parameter + negotiation, and secure data transfer. Because DTLS data transfer + protocol is generic, it is less highly optimized for use with RTP + than is SRTP, which has been specifically tuned for that purpose. + + This document describes DTLS-SRTP, a SRTP extension for DTLS that + combines the performance and encryption flexibility benefits of SRTP + with the flexibility and convenience of DTLS-integrated key and + association management. DTLS-SRTP can be viewed in two equivalent + ways: as a new key management method for SRTP, and a new RTP-specific + data format for DTLS. + + The key points of DTLS-SRTP are that: + + o application data is protected using SRTP, + + o the DTLS handshake is used to establish keying material, + algorithms, and parameters for SRTP, + + o a DTLS extension is used to negotiate SRTP algorithms, and + + o other DTLS record-layer content types are protected using the + ordinary DTLS record format. + + The remainder of this memo is structured as follows. Section 2 + describes conventions used to indicate normative requirements. + Section 3 provides an overview of DTLS-SRTP operation. Section 4 + specifies the DTLS extensions, while Section 5 discusses how RTP and + RTCP are transported over a DTLS-SRTP channel. Section 6 describes + use with multi-party sessions. Section 7 and Section 9 describe + Security and IANA considerations. + +2. Conventions Used In This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + +McGrew & Rescorla Standards Track [Page 3] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +3. Overview of DTLS-SRTP Operation + + DTLS-SRTP is defined for point-to-point media sessions, in which + there are exactly two participants. Each DTLS-SRTP session contains + a single DTLS association (called a "connection" in TLS jargon), and + either two SRTP contexts (if media traffic is flowing in both + directions on the same host/port quartet) or one SRTP context (if + media traffic is only flowing in one direction). All SRTP traffic + flowing over that pair in a given direction uses a single SRTP + context. A single DTLS-SRTP session only protects data carried over + a single UDP source and destination port pair. + + The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP + flow the peers do a DTLS handshake on the same source and destination + port pair to establish a DTLS association. Which side is the DTLS + client and which side is the DTLS server must be established via some + out-of-band mechanism such as SDP. The keying material from that + handshake is fed into the SRTP stack. Once that association is + established, RTP packets are protected (becoming SRTP) using that + keying material. + + RTP and RTCP traffic is usually sent on two separate UDP ports. When + symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions + are needed, one for the RTP port, one for the RTCP port. When RTP + flows are not symmetric, four unidirectional DTLS-SRTP sessions are + needed (for inbound and outbound RTP, and inbound and outbound RTCP). + + Symmetric RTP [RFC4961] is the case in which there are two RTP + sessions that have their source and destination ports and addresses + reversed, in a manner similar to the way that a TCP connection uses + its ports. Each participant has an inbound RTP session and an + outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP + session can protect both of the RTP sessions. It is RECOMMENDED that + symmetric RTP be used with DTLS-SRTP. + + RTP and RTCP traffic MAY be multiplexed on a single UDP port + [RFC5761]. In this case, both RTP and RTCP packets may be sent over + the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions + needed. This improves the cryptographic performance of DTLS, but may + cause problems when RTCP and RTP are subject to different network + treatment (e.g., for bandwidth reservation or scheduling reasons). + + Between a single pair of participants, there may be multiple media + sessions. There MUST be a separate DTLS-SRTP session for each + distinct pair of source and destination ports used by a media session + (though the sessions can share a single DTLS session and hence + amortize the initial public key handshake!). + + + + +McGrew & Rescorla Standards Track [Page 4] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + A DTLS-SRTP session may be indicated by an external signaling + protocol like SIP. When the signaling exchange is integrity- + protected (e.g., when SIP Identity protection via digital signatures + is used), DTLS-SRTP can leverage this integrity guarantee to provide + complete security of the media stream. A description of how to + indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to + authenticate the endpoints using fingerprints can be found in + [RFC5763]. + + In a naive implementation, when there are multiple media sessions, + there is a new DTLS session establishment (complete with public key + cryptography) for each media channel. For example, a videophone may + be sending both an audio stream and a video stream, each of which + would use a separate DTLS session establishment exchange, which would + proceed in parallel. As an optimization, the DTLS-SRTP + implementation SHOULD use the following strategy: a single DTLS + association is established, and all other DTLS associations wait + until that connection is established before proceeding with their + handshakes. This strategy allows the later sessions to use DTLS + session resumption, which allows the amortization of the expensive + public key cryptography operations over multiple DTLS handshakes. + + The SRTP keys used to protect packets originated by the client are + distinct from the SRTP keys used to protect packets originated by the + server. All of the RTP sources originating on the client for the + same channel use the same SRTP keys, and similarly, all of the RTP + sources originating on the server for the same channel use the same + SRTP keys. The SRTP implementation MUST ensure that all of the + synchronization source (SSRC) values for all of the RTP sources + originating from the same device over the same channel are distinct, + in order to avoid the "two-time pad" problem (as described in Section + 9.1 of RFC 3711). Note that this is not an issue for separate media + streams (on different host/port quartets) that use independent keying + material even if an SSRC collision occurs. + +4. DTLS Extensions for SRTP Key Establishment + +4.1. The use_srtp Extension + + In order to negotiate the use of SRTP data protection, clients + include an extension of type "use_srtp" in the DTLS extended client + hello. This extension MUST only be used when the data being + transported is RTP or RTCP [RFC3550]. The "extension_data" field of + this extension contains the list of acceptable SRTP protection + profiles, as indicated below. + + + + + + +McGrew & Rescorla Standards Track [Page 5] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Servers that receive an extended hello containing a "use_srtp" + extension can agree to use SRTP by including an extension of type + "use_srtp", with the chosen protection profile in the extended server + hello. This process is shown below. + + Client Server + + ClientHello + use_srtp --------> + ServerHello + use_srtp + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + SRTP packets <-------> SRTP packets + + Note that '*' indicates messages that are not always sent in DTLS. + The CertificateRequest, client and server Certificates, and + CertificateVerify will be sent in DTLS-SRTP. + + Once the "use_srtp" extension is negotiated, the RTP or RTCP + application data is protected solely using SRTP. Application data is + never sent in DTLS record-layer "application_data" packets. Rather, + complete RTP or RTCP packets are passed to the DTLS stack, which + passes them to the SRTP stack, which protects them appropriately. + Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means + that RTP and RTCP packets may both be passed to the DTLS stack. + Because the DTLS layer does not process the packets, it does not need + to distinguish them. The SRTP stack can use the procedures of + [RFC5761] to distinguish RTP from RTCP. + + When the "use_srtp" extension is in effect, implementations must not + place more than one application data "record" per datagram. (This is + only meaningful from the perspective of DTLS because SRTP is + inherently oriented towards one payload per packet, but this is + stated purely for clarification.) + + Data other than RTP/RTCP (i.e., TLS control messages) MUST use + ordinary DTLS framing and MUST be placed in separate datagrams from + SRTP data. + + + + + +McGrew & Rescorla Standards Track [Page 6] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + A DTLS-SRTP handshake establishes one or more SRTP crypto contexts; + however, they all have the same SRTP Protection Profile and Master + Key Identifier (MKI), if any. MKIs are used solely to distinguish + the keying material and protection profiles between distinct + handshakes, for instance, due to rekeying. When an MKI is + established in a DTLS-SRTP session, it MUST apply for all of the + SSRCs within that session -- though a single endpoint may negotiate + multiple DTLS-SRTP sessions due, for instance, to forking. (Note + that RFC 3711 allows packets within the same session but with + different SSRCs to use MKIs differently; in contrast, DTLS-SRTP + requires that MKIs and the keys that they are associated with have + the same meaning and are uniform across the entire SRTP session.) + +4.1.1. use_srtp Extension Definition + + The client MUST fill the extension_data field of the "use_srtp" + extension with an UseSRTPData value (see Section 9 for the + registration): + + uint8 SRTPProtectionProfile[2]; + + struct { + SRTPProtectionProfiles SRTPProtectionProfiles; + opaque srtp_mki<0..255>; + } UseSRTPData; + + SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>; + + The SRTPProtectionProfiles list indicates the SRTP protection + profiles that the client is willing to support, listed in descending + order of preference. The srtp_mki value contains the SRTP Master Key + Identifier (MKI) value (if any) that the client will use for his SRTP + packets. If this field is of zero length, then no MKI will be used. + + Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" + indicates a variable-length value with a length between 0 and 255 + (inclusive). Thus, the MKI may be up to 255 bytes long. + + If the server is willing to accept the use_srtp extension, it MUST + respond with its own "use_srtp" extension in the ExtendedServerHello. + The extension_data field MUST contain a UseSRTPData value with a + single SRTPProtectionProfile value that the server has chosen for use + with this connection. The server MUST NOT select a value that the + client has not offered. If there is no shared profile, the server + SHOULD NOT return the use_srtp extension at which point the + connection falls back to the negotiated DTLS cipher suite. If that + is not acceptable, the server SHOULD return an appropriate DTLS + alert. + + + +McGrew & Rescorla Standards Track [Page 7] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +4.1.2. SRTP Protection Profiles + + A DTLS-SRTP SRTP Protection Profile defines the parameters and + options that are in effect for the SRTP processing. This document + defines the following SRTP protection profiles. + + SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01}; + SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02}; + SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05}; + SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06}; + + The following list indicates the SRTP transform parameters for each + protection profile. The parameters cipher_key_length, + cipher_salt_length, auth_key_length, and auth_tag_length express the + number of bits in the values to which they refer. The + maximum_lifetime parameter indicates the maximum number of packets + that can be protected with each single set of keys when the parameter + profile is in use. All of these parameters apply to both RTP and + RTCP, unless the RTCP parameters are separately specified. + + All of the crypto algorithms in these profiles are from [RFC3711]. + + SRTP_AES128_CM_HMAC_SHA1_80 + cipher: AES_128_CM + cipher_key_length: 128 + cipher_salt_length: 112 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 80 + SRTP_AES128_CM_HMAC_SHA1_32 + cipher: AES_128_CM + cipher_key_length: 128 + cipher_salt_length: 112 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 32 + RTCP auth_tag_length: 80 + SRTP_NULL_HMAC_SHA1_80 + cipher: NULL + cipher_key_length: 0 + cipher_salt_length: 0 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 80 + + + + +McGrew & Rescorla Standards Track [Page 8] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + SRTP_NULL_HMAC_SHA1_32 + cipher: NULL + cipher_key_length: 0 + cipher_salt_length: 0 + maximum_lifetime: 2^31 + auth_function: HMAC-SHA1 + auth_key_length: 160 + auth_tag_length: 32 + RTCP auth_tag_length: 80 + + With all of these SRTP Parameter profiles, the following SRTP options + are in effect: + + o The TLS PseudoRandom Function (PRF) is used to generate keys to + feed into the SRTP Key Derivation Function (KDF). When DTLS 1.2 + [DTLS1.2] is in use, the PRF is the one associated with the cipher + suite. Note that this specification is compatible with DTLS 1.0 + or DTLS 1.2 + + o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are + not re-derived based on the SRTP sequence number. + + o The key derivation procedures from Section 4.3 with the AES-CM PRF + from RFC 3711 are used. + + o For all other parameters (in particular, SRTP replay window size + and FEC order), the default values are used. + + If values other than the defaults for these parameters are required, + they can be enabled by writing a separate specification specifying + SDP syntax to signal them. + + Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection + Profiles between the DTLS-SRTP session that protects an RTP flow and + the DTLS-SRTP session that protects the associated RTCP flow (in + those cases in which the RTP and RTCP are not multiplexed over a + common port). In particular, identical ciphers SHOULD be used. + + New SRTPProtectionProfile values must be defined according to the + "Specification Required" policy as defined by RFC 5226 [RFC5226]. + See Section 9 for IANA Considerations. + +4.1.3. srtp_mki value + + The srtp_mki value MAY be used to indicate the capability and desire + to use the SRTP Master Key Identifier (MKI) field in the SRTP and + SRTCP packets. The MKI field indicates to an SRTP receiver which key + was used to protect the packet that contains that field. The + + + +McGrew & Rescorla Standards Track [Page 9] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + srtp_mki field contains the value of the SRTP MKI which is associated + with the SRTP master keys derived from this handshake. Each SRTP + session MUST have exactly one master key that is used to protect + packets at any given time. The client MUST choose the MKI value so + that it is distinct from the last MKI value that was used, and it + SHOULD make these values unique for the duration of the TLS session. + + Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, + the server MUST either (assuming it accepts the extension at all): + + 1. include a matching "srtp_mki" value in its "use_srtp" extension + to indicate that it will make use of the MKI, or + 2. return an empty "srtp_mki" value to indicate that it cannot make + use of the MKI. + + If the client detects a nonzero-length MKI in the server's response + that is different than the one the client offered, then the client + MUST abort the handshake and SHOULD send an invalid_parameter alert. + If the client and server agree on an MKI, all SRTP packets protected + under the new security parameters MUST contain that MKI. + + Note that any given DTLS-SRTP session only has a single active MKI + (if any). Thus, at any given time, a set of endpoints will generally + only be using one MKI (the major exception is during rehandshakes). + +4.2. Key Derivation + + When SRTP mode is in effect, different keys are used for ordinary + DTLS record protection and SRTP packet protection. These keys are + generated using a TLS exporter [RFC5705] to generate + + 2 * (SRTPSecurityParams.master_key_len + + SRTPSecurityParams.master_salt_len) bytes of data + + which are assigned as shown below. The per-association context value + is empty. + + client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; + server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; + client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; + server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; + + The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The + "EXTRACTOR" prefix is for historical compatibility.) + + The four keying material values (the master key and master salt for + each direction) are provided as inputs to the SRTP key derivation + mechanism, as shown in Figure 1 and detailed below. By default, the + + + +McGrew & Rescorla Standards Track [Page 10] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + mechanism defined in Section 4.3 of [RFC3711] is used, unless another + key derivation mechanism is specified as part of an SRTP Protection + Profile. + + The client_write_SRTP_master_key and client_write_SRTP_master_salt + are provided to one invocation of the SRTP key derivation function, + to generate the SRTP keys used to encrypt and authenticate packets + sent by the client. The server MUST only use these keys to decrypt + and to check the authenticity of inbound packets. + + The server_write_SRTP_master_key and server_write_SRTP_master_salt + are provided to one invocation of the SRTP key derivation function, + to generate the SRTP keys used to encrypt and authenticate packets + sent by the server. The client MUST only use these keys to decrypt + and to check the authenticity of inbound packets. + + TLS master + secret label + | | + v v + +---------------+ + | TLS extractor | + +---------------+ + | +------+ SRTP + +-> client_write_SRTP_master_key ----+--->| SRTP |-> client + | | +->| KDF | write + | | | +------+ keys + | | | + +-> server_write_SRTP_master_key -- | | +------+ SRTCP + | \ \--->|SRTCP |-> client + | \ +->| KDF | write + | | | +------+ keys + +-> client_write_SRTP_master_salt ---|-+ + | | + | | +------+ SRTP + | +--->| SRTP |-> server + +-> server_write_SRTP_master_salt -+-|--->| KDF | write + | | +------+ keys + | | + | | +------+ SRTCP + | +--->|SRTCP |-> server + +----->| KDF | write + +------+ keys + + Figure 1: The derivation of the SRTP keys. + + + + + + +McGrew & Rescorla Standards Track [Page 11] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + When both RTCP and RTP use the same source and destination ports, + then both the SRTP and SRTCP keys are needed. Otherwise, there are + two DTLS-SRTP sessions, one of which protects the RTP packets and one + of which protects the RTCP packets; each DTLS-SRTP session protects + the part of an SRTP session that passes over a single source/ + destination transport address pair, as shown in Figure 2, independent + of which SSRCs are used on that pair. When a DTLS-SRTP session is + protecting RTP, the SRTCP keys derived from the DTLS handshake are + not needed and are discarded. When a DTLS-SRTP session is protecting + RTCP, the SRTP keys derived from the DTLS handshake are not needed + and are discarded. + + Client Server + (Sender) (Receiver) + (1) <----- DTLS ------> src/dst = a/b and b/a + ------ SRTP ------> src/dst = a/b, uses client write keys + + (2) <----- DTLS ------> src/dst = c/d and d/c + ------ SRTCP -----> src/dst = c/d, uses client write keys + <----- SRTCP ------ src/dst = d/c, uses server write keys + + Figure 2: A DTLS-SRTP session protecting RTP (1) and another one + protecting RTCP (2), showing the transport addresses and keys used. + +4.3. Key Scope + + Because of the possibility of packet reordering, DTLS-SRTP + implementations SHOULD store multiple SRTP keys sets during a rekey + in order to avoid the need for receivers to drop packets for which + they lack a key. + +4.4. Key Usage Limitations + + The maximum_lifetime parameter in the SRTP protection profile + indicates the maximum number of packets that can be protected with + each single encryption and authentication key. (Note that, since RTP + and RTCP are protected with independent keys, those protocols are + counted separately for the purposes of determining when a key has + reached the end of its lifetime.) Each profile defines its own + limit. When this limit is reached, a new DTLS session SHOULD be used + to establish replacement keys, and SRTP implementations MUST NOT use + the existing keys for the processing of either outbound or inbound + traffic. + + + + + + + + +McGrew & Rescorla Standards Track [Page 12] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +5. Use of RTP and RTCP over a DTLS-SRTP Channel + +5.1. Data Protection + + Once the DTLS handshake has completed, the peers can send RTP or RTCP + over the newly created channel. We describe the transmission process + first followed by the reception process. + + Within each RTP session, SRTP processing MUST NOT take place before + the DTLS handshake completes. + +5.1.1. Transmission + + DTLS and TLS define a number of record content types. In ordinary + TLS/DTLS, all data is protected using the same record encoding and + mechanisms. When the mechanism described in this document is in + effect, this is modified so that data written by upper-level protocol + clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP + rather than the standard TLS record encoding. + + When a user of DTLS wishes to send an RTP packet in SRTP mode, it + delivers it to the DTLS implementation as an ordinary application + data write (e.g., SSL_write()). The DTLS implementation then invokes + the processing described in RFC 3711, Sections 3 and 4. The + resulting SRTP packet is then sent directly on the wire as a single + datagram with no DTLS framing. This provides an encapsulation of the + data that conforms to and interoperates with SRTP. Note that the RTP + sequence number rather than the DTLS sequence number is used for + these packets. + +5.1.2. Reception + + When DTLS-SRTP is used to protect an RTP session, the RTP receiver + needs to demultiplex packets that are arriving on the RTP port. + Arriving packets may be of types RTP, DTLS, or STUN [RFC5389]. If + these are the only types of packets present, the type of a packet can + be determined by looking at its first byte. + + The process for demultiplexing a packet is as follows. The receiver + looks at the first byte of the packet. If the value of this byte is + 0 or 1, then the packet is STUN. If the value is in between 128 and + 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and + RTP are being multiplexed over the same destination port). If the + value is between 20 and 63 (inclusive), the packet is DTLS. This + process is summarized in Figure 3. + + + + + + +McGrew & Rescorla Standards Track [Page 13] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + +----------------+ + | 127 < B < 192 -+--> forward to RTP + | | + packet --> | 19 < B < 64 -+--> forward to DTLS + | | + | B < 2 -+--> forward to STUN + +----------------+ + + Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. + Here the field B denotes the leading byte of the packet. + + If other packet types are to be multiplexed as well, implementors + and/or designers SHOULD ensure that they can be demultiplexed from + these three packet types. + + In some cases, there will be multiple DTLS-SRTP associations for a + given SRTP endpoint. For instance, if Alice makes a call that is SIP + forked to both Bob and Charlie, she will use the same local host/port + pair for both of them, as shown in Figure 4, where XXX and YYY + represent different DTLS-SRTP associations. (The SSRCs shown are the + ones for data flowing to Alice.) + + Bob (192.0.2.1:6666) + / + / + / SSRC=1 + / DTLS-SRTP=XXX + / + v + Alice (192.0.2.0:5555) + ^ + \ + \ SSRC=2 + \ DTLS-SRTP=YYY + \ + \ + Charlie (192.0.2.2:6666) + + Figure 4: RTP sessions with SIP forking. + + Because DTLS operates on the host/port quartet, the DTLS association + will still complete correctly, with the foreign host/port pair being + used, to distinguish the associations. However, in RTP the source + host/port is not used and sessions are identified by the destination + host/port and the SSRC. Thus, some mechanism is needed to determine + which SSRCs correspond to which DTLS associations. The following + method SHOULD be used. + + + + +McGrew & Rescorla Standards Track [Page 14] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + For each local host/port pair, the DTLS-SRTP implementation maintains + a table listing all the SSRCs it knows about and the DTLS-SRTP + associations they correspond to. Initially, this table is empty. + When an SRTP packet is received for a given RTP endpoint (destination + IP/port pair), the following procedure is used: + + 1. If the SSRC is already known for that endpoint, then the + corresponding DTLS-SRTP association and its keying material is + used to decrypt and verify the packet. + 2. If the SSRC is not known, then the receiver tries to decrypt it + with the keying material corresponding to each DTLS-SRTP + association for that endpoint. + 3. If the decryption and verification succeeds (the authentication + tag verifies), then an entry is placed in the table mapping the + SSRC to that association. + 4. If the decryption and verification fails, then the packet is + silently discarded. + 5. When a DTLS-SRTP association is closed (for instance, because the + fork is abandoned), its entries MUST be removed from the mapping + table. + + The average cost of this algorithm for a single SSRC is the + decryption and verification time of a single packet times the number + of valid DTLS-SRTP associations corresponding to a single receiving + port on the host. In practice, this means the number of forks; so in + the case shown in Figure 4, that would be two. This cost is only + incurred once for any given SSRC, since afterwards that SSRC is + placed in the map table and looked up immediately. As with normal + RTP, this algorithm allows new SSRCs to be introduced by the source + at any time. They will automatically be mapped to the correct DTLS + association. + + Note that this algorithm explicitly allows multiple SSRCs to be sent + from the same address/port pair. One way in which this can happen is + an RTP translator. This algorithm will automatically assign the + SSRCs to the correct associations. Note that because the SRTP + packets are cryptographically protected, such a translator must + either share keying material with one endpoint or refrain from + modifying the packets in a way which would cause the integrity check + to fail. This is a general property of SRTP and is not specific to + DTLS-SRTP. + + There are two error cases that should be considered. First, if an + SSRC collision occurs, then only the packets from the first source + will be processed. When the packets from the second source arrive, + the DTLS association with the first source will be used for + decryption and verification, which will fail, and the packet will be + discarded. This is consistent with [RFC3550], which permits the + + + +McGrew & Rescorla Standards Track [Page 15] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + receiver to keep the packets from one source and discard those from + the other. Of course the RFC 3550 SSRC collision detection and + handling procedures MUST also be followed. + + Second, there may be cases where a malfunctioning source is sending + corrupt packets that cannot be decrypted and verified. In this case, + the SSRC will never be entered into the mapping table because the + decryption and verification always fails. Receivers MAY keep records + of unmapped SSRCs that consistently fail decryption and verification + and abandon attempts to process them once they reach some limit. + That limit MUST be large enough to account for the effects of + transmission errors. Entries MUST be pruned from this table when the + relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD + time out faster than that (we do not offer a hard recommendation but + 10 to 30 seconds seems appropriate) in order to allow for the + possibility that the peer implementation has been corrected. + +5.2. Rehandshake and Rekey + + Rekeying in DTLS is accomplished by performing a new handshake over + the existing DTLS channel. That is, the handshake messages are + protected by the existing DTLS cipher suite. This handshake can be + performed in parallel with data transport, so no interruption of the + data flow is required. Once the handshake is finished, the newly + derived set of keys is used to protect all outbound packets, both + DTLS and SRTP. + + Because of packet reordering, packets protected by the previous set + of keys can appear on the wire after the handshake has completed. To + compensate for this fact, receivers SHOULD maintain both sets of keys + for some time in order to be able to decrypt and verify older + packets. The keys should be maintained for the duration of the + maximum segment lifetime (MSL). + + If an MKI is used, then the receiver should use the corresponding set + of keys to process an incoming packet. If no matching MKI is + present, the packet MUST be rejected. Otherwise, when a packet + arrives after the handshake completed, a receiver SHOULD use the + newly derived set of keys to process that packet unless there is an + MKI. (If the packet was protected with the older set of keys, this + fact will become apparent to the receiver as an authentication + failure will occur.) If the authentication check on the packet fails + and no MKI is being used, then the receiver MAY process the packet + with the older set of keys. If that authentication check indicates + that the packet is valid, the packet should be accepted; otherwise, + the packet MUST be discarded and rejected. + + + + + +McGrew & Rescorla Standards Track [Page 16] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Receivers MAY use the SRTP packet sequence number to aid in the + selection of keys. After a packet has been received and + authenticated with the new key set, any packets with sequence numbers + that are greater will also have been protected with the new key set. + +6. Multi-Party RTP Sessions + + Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only + to protect unicast RTP sessions. This does not preclude its use with + RTP mixers. For example, a conference bridge may use DTLS-SRTP to + secure the communication to and from each of the participants in a + conference. However, because each flow between an endpoint and a + mixer has its own key, the mixer has to decrypt and then reencrypt + the traffic for each recipient. + + A future specification may describe methods for sharing a single key + between multiple DTLS-SRTP associations thus allowing conferencing + systems to avoid the decrypt/reencrypt stage. However, any system in + which the media is modified (e.g., for level balancing or + transcoding) will generally need to be performed on the plaintext and + will certainly break the authentication tag, and therefore will + require a decrypt/reencrypt stage. + +7. Security Considerations + + The use of multiple data protection framings negotiated in the same + handshake creates some complexities, which are discussed here. + +7.1. Security of Negotiation + + One concern here is that attackers might be able to implement a bid- + down attack forcing the peers to use ordinary DTLS rather than SRTP. + However, because the negotiation of this extension is performed in + the DTLS handshake, it is protected by the Finished messages. + Therefore, any bid-down attack is automatically detected, which + reduces this to a denial-of-service attack -- which can be mounted by + any attacker who can control the channel. + +7.2. Framing Confusion + + Because two different framing formats are used, there is concern that + an attacker could convince the receiver to treat an SRTP-framed RTP + packet as a DTLS record (e.g., a handshake message) or vice versa. + This attack is prevented by using different keys for Message + Authentication Code (MAC) verification for each type of data. + Therefore, this type of attack reduces to being able to forge a + packet with a valid MAC, which violates a basic security invariant of + both DTLS and SRTP. + + + +McGrew & Rescorla Standards Track [Page 17] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + As an additional defense against injection into the DTLS handshake + channel, the DTLS record type is included in the MAC. Therefore, an + SRTP record would be treated as an unknown type and ignored. (See + Section 6 of [RFC5246].) + +7.3. Sequence Number Interactions + + As described in Section 5.1.1, the SRTP and DTLS sequence number + spaces are distinct. This means that it is not possible to + unambiguously order a given DTLS control record with respect to an + SRTP packet. In general, this is relevant in two situations: alerts + and rehandshake. + +7.3.1. Alerts + + Because DTLS handshake and change_cipher_spec messages share the same + sequence number space as alerts, they can be ordered correctly. + Because DTLS alerts are inherently unreliable and SHOULD NOT be + generated as a response to data packets, reliable sequencing between + SRTP packets and DTLS alerts is not an important feature. However, + implementations that wish to use DTLS alerts to signal problems with + the SRTP encoding SHOULD simply act on alerts as soon as they are + received and assume that they refer to the temporally contiguous + stream. Such implementations MUST check for alert retransmission and + discard retransmitted alerts to avoid overreacting to replay attacks. + +7.3.2. Renegotiation + + Because the rehandshake transition algorithm specified in Section 5.2 + requires trying multiple sets of keys if no MKI is used, it slightly + weakens the authentication. For instance, if an n-bit MAC is used + and k different sets of keys are present, then the MAC is weakened by + log_2(k) bits to n - log_2(k). In practice, since the number of keys + used will be very small and the MACs in use are typically strong (the + default for SRTP is 80 bits), the decrease in security involved here + is minimal. + + Another concern here is that this algorithm slightly increases the + work factor on the receiver because it needs to attempt multiple + validations. However, again, the number of potential keys will be + very small (and the attacker cannot force it to be larger) and this + technique is already used for rollover counter management, so the + authors do not consider this to be a serious flaw. + + + + + + + + +McGrew & Rescorla Standards Track [Page 18] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +7.4. Decryption Cost + + An attacker can impose computational costs on the receiver by sending + superficially valid SRTP packets that do not decrypt correctly. In + general, encryption algorithms are so fast that this cost is + extremely small compared to the bandwidth consumed. The SSRC-DTLS + mapping algorithm described in Section 5.1.2 gives the attacker a + slight advantage here because he can force the receiver to do more + then one decryption per packet. However, this advantage is modest + because the number of decryptions that the receiver does is limited + by the number of associations he has corresponding to a given + destination host/port, which is typically quite small. For + comparison, a single 1024-bit RSA private key operation (the typical + minimum cost to establish a DTLS-SRTP association) is hundreds of + times as expensive as decrypting an SRTP packet. + + Implementations can detect this form of attack by keeping track of + the number of SRTP packets that are observed with unknown SSRCs and + that fail the authentication tag check. If under such attack, + implementations SHOULD prioritize decryption and verification of + packets that either have known SSRCs or come from source addresses + that match those of peers with which it has DTLS-SRTP associations. + +8. Session Description for RTP/SAVP over DTLS + + This specification defines new tokens to describe the protocol used + in SDP media descriptions ("m=" lines and their associated + parameters). The new values defined for the proto field are: + + o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over + DTLS with the Datagram Congestion Control Protocol (DCCP), then + the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF + respectively. + + o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with + UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF + respectively. + + The "fmt" parameter SHALL be as defined for RTP/SAVP. + + See [RFC5763] for how to use offer/answer with DTLS-SRTP. + + This document does not specify how to protect RTP data transported + over TCP. Potential approaches include carrying the RTP over TLS + over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that + in this document over TCP, either via TLS or DTLS, with DTLS being + used for consistency between reliable and unreliable transports. In + + + + +McGrew & Rescorla Standards Track [Page 19] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + the latter case, it would be necessary to profile DTLS so that + fragmentation and retransmissions no longer occurred. In either + case, a new document would be required. + +9. IANA Considerations + + This document adds a new extension for DTLS, in accordance with + [RFC5246]: + enum { use_srtp (14) } ExtensionType; + + This extension MUST only be used with DTLS, and not with TLS + [RFC4572], which specifies that TLS can be used over TCP but does not + address TCP for RTP/SAVP. + + Section 4.1.2 requires that all SRTPProtectionProfile values be + defined by RFC 5226 "Specification Required". IANA has created a + DTLS SRTPProtectionProfile registry initially populated with values + from Section 4.1.2 of this document. Future values MUST be allocated + via the "Specification Required" profile of [RFC5226]. + + This specification updates the "Session Description Protocol (SDP) + Parameters" registry as defined in Section 8.2.2 of [RFC4566]. + Specifically, it adds the following values to the table for the + "proto" field. + + Type SDP Name Reference + ---- ------------------ --------- + proto UDP/TLS/RTP/SAVP [RFC5764] + proto DCCP/TLS/RTP/SAVP [RFC5764] + + proto UDP/TLS/RTP/SAVPF [RFC5764] + proto DCCP/TLS/RTP/SAVPF [RFC5764] + + IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS + Extractor Label Registry to correspond to this specification. + +10. Acknowledgments + + Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, + Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, + and Ben Campbell for input, discussions, and guidance. Pasi Eronen + provided Figure 1. + + + + + + + + + +McGrew & Rescorla Standards Track [Page 20] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., + and K. Norrman, "The Secure Real-time Transport + Protocol (SRTP)", RFC 3711, March 2004. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security", RFC 4347, April 2006. + + [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol + (RTCP)", BCP 131, RFC 4961, July 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5705] Rescorla, E., "Keying Material Exporters for + Transport Layer Security (TLS)", RFC 5705, + March 2010. + + [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP + Data and Control Packets on a Single Port", + RFC 5761, April 2010. + +11.2. Informative References + + [DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security version 1.2", Work in Progress, + October 2009. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + [RFC4572] Lennox, J., "Connection-Oriented Media Transport + over the Transport Layer Security (TLS) Protocol in + the Session Description Protocol (SDP)", RFC 4572, + July 2006. + + + + + +McGrew & Rescorla Standards Track [Page 21] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile + for Real-time Transport Control Protocol (RTCP)- + Based Feedback (RTP/SAVPF)", RFC 5124, + February 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 5226, May 2008. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", + RFC 5389, October 2008. + + [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, + "Framework for Establishing a Secure Real-time + Transport Protocol (SRTP) Security Context Using + Datagram Transport Layer Security (DTLS)", RFC 5763, + May 2010. + + [SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not + Mandate a Single Security Mechanism", Work in + Progress, January 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGrew & Rescorla Standards Track [Page 22] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +Appendix A. Overview of DTLS + + This section provides a brief overview of Datagram TLS (DTLS) for + those who are not familiar with it. DTLS is a channel security + protocol based on the well-known Transport Layer Security (TLS) + [RFC5246] protocol. Where TLS depends on a reliable transport + channel (typically TCP), DTLS has been adapted to support unreliable + transports such as UDP. Otherwise, DTLS is nearly identical to TLS + and generally supports the same cryptographic mechanisms. + + Each DTLS association begins with a handshake exchange (shown below) + during which the peers authenticate each other and negotiate + algorithms, modes, and other parameters and establish shared keying + material, as shown below. In order to support unreliable transport, + each side maintains retransmission timers to provide reliable + delivery of these messages. Once the handshake is completed, + encrypted data may be sent. + + Client Server + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + '*' indicates messages that are not always sent. + + Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]). + + Application data is protected by being sent as a series of DTLS + "records". These records are independent and can be processed + correctly even in the face of loss or reordering. In DTLS-SRTP, this + record protocol is replaced with SRTP [RFC3711] + + + + + + + + +McGrew & Rescorla Standards Track [Page 23] + +RFC 5764 SRTP Extension for DTLS May 2010 + + +Appendix B. Performance of Multiple DTLS Handshakes + + Standard practice for security protocols such as TLS, DTLS, and SSH, + which do inline key management, is to create a separate security + association for each underlying network channel (TCP connection, UDP + host/port quartet, etc.). This has dual advantages of simplicity and + independence of the security contexts for each channel. + + Three concerns have been raised about the overhead of this strategy + in the context of RTP security. The first concern is the additional + performance overhead of doing a separate public key operation for + each channel. The conventional procedure here (used in TLS and DTLS) + is to establish a master context that can then be used to derive + fresh traffic keys for new associations. In TLS/DTLS, this is called + "session resumption" and can be transparently negotiated between the + peers. + + The second concern is network bandwidth overhead for the + establishment of subsequent connections and for rehandshake (for + rekeying) for existing connections. In particular, there is a + concern that the channels will have very narrow capacity requirements + allocated entirely to media that will be overflowed by the + rehandshake. Measurements of the size of the rehandshake (with + resumption) in TLS indicate that it is about 300-400 bytes if a full + selection of cipher suites is offered. (The size of a full handshake + is approximately 1-2 kilobytes larger because of the certificate and + keying material exchange.) + + The third concern is the additional round-trips associated with + establishing the second, third, ... channels. In TLS/DTLS, these can + all be done in parallel, but in order to take advantage of session + resumption they should be done after the first channel is + established. For two channels, this provides a ladder diagram + something like this (parenthetical numbers are media channel numbers) + + + + + + + + + + + + + + + + + +McGrew & Rescorla Standards Track [Page 24] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Alice Bob + ------------------------------------------- + <- ClientHello (1) + ServerHello (1) -> + Certificate (1) + ServerHelloDone (1) + <- ClientKeyExchange (1) + ChangeCipherSpec (1) + Finished (1) + ChangeCipherSpec (1)-> + Finished (1)-> + <--- Channel 1 ready + + <- ClientHello (2) + ServerHello (2) -> + ChangeCipherSpec(2)-> + Finished(2) -> + <- ChangeCipherSpec (2) + Finished (2) + <--- Channel 2 ready + + Figure 6: Parallel DTLS-SRTP negotiations. + + So, there is an additional 1 RTT (round-trip time) after Channel 1 is + ready before Channel 2 is ready. If the peers are potentially + willing to forego resumption, they can interlace the handshakes, like + so: + + + + + + + + + + + + + + + + + + + + + + + + +McGrew & Rescorla Standards Track [Page 25] + +RFC 5764 SRTP Extension for DTLS May 2010 + + + Alice Bob + ------------------------------------------- + <- ClientHello (1) + ServerHello (1) -> + Certificate (1) + ServerHelloDone (1) + <- ClientKeyExchange (1) + ChangeCipherSpec (1) + Finished (1) + <- ClientHello (2) + ChangeCipherSpec (1)-> + Finished (1)-> + <--- Channel 1 ready + ServerHello (2) -> + ChangeCipherSpec(2)-> + Finished(2) -> + <- ChangeCipherSpec (2) + Finished (2) + <--- Channel 2 ready + + Figure 7: Interlaced DTLS-SRTP negotiations. + + In this case, the channels are ready contemporaneously, but if a + message in handshake (1) is lost, then handshake (2) requires either + a full rehandshake or that Alice be clever and queue the resumption + attempt until the first handshake completes. Note that just dropping + the packet works as well, since Bob will retransmit. + +Authors' Addresses + + David McGrew + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95305 + USA + + EMail: mcgrew at cisco.com + + + Eric Rescorla + RTFM, Inc. + 2064 Edgewood Drive + Palo Alto, CA 94303 + USA + + EMail: ekr at rtfm.com + + + + + +McGrew & Rescorla Standards Track [Page 26] + diff --git a/lib/ext/Makefile.am b/lib/ext/Makefile.am index ca6628e..0d97132 100644 --- a/lib/ext/Makefile.am +++ b/lib/ext/Makefile.am @@ -39,5 +39,5 @@ libgnutls_ext_la_SOURCES = max_record.c cert_type.c \ max_record.h cert_type.h server_name.h srp.h \ session_ticket.h signature.h safe_renegotiation.h \ session_ticket.c srp.c ecc.c ecc.h heartbeat.c heartbeat.h \ - status_request.h status_request.c + status_request.h status_request.c srtp.c srtp.h diff --git a/lib/ext/srtp.c b/lib/ext/srtp.c new file mode 100644 index 0000000..884470c --- /dev/null +++ b/lib/ext/srtp.c @@ -0,0 +1,465 @@ +/* + * Copyright (C) 2012 Free Software Foundation, Inc. + * + * Author: Martin Storsjo + * + * This file is part of GnuTLS. + * + * The GnuTLS is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 3 of + * the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program. If not, see + * + */ + +#include "gnutls_int.h" +#include "gnutls_auth.h" +#include "gnutls_errors.h" +#include "gnutls_num.h" +#include + +static int _gnutls_srtp_recv_params (gnutls_session_t session, + const uint8_t * data, + size_t data_size); +static int _gnutls_srtp_send_params (gnutls_session_t session, + gnutls_buffer_st* extdata); + +static int _gnutls_srtp_unpack (gnutls_buffer_st * ps, + extension_priv_data_t * _priv); +static int _gnutls_srtp_pack (extension_priv_data_t _priv, + gnutls_buffer_st * ps); +static void _gnutls_srtp_deinit_data (extension_priv_data_t priv); + + +extension_entry_st ext_mod_srtp = { + .name = "SRTP", + .type = GNUTLS_EXTENSION_SRTP, + .parse_type = GNUTLS_EXT_APPLICATION, + + .recv_func = _gnutls_srtp_recv_params, + .send_func = _gnutls_srtp_send_params, + .pack_func = _gnutls_srtp_pack, + .unpack_func = _gnutls_srtp_unpack, + .deinit_func = _gnutls_srtp_deinit_data, +}; + +typedef struct +{ + const char *name; + gnutls_srtp_profile_t id; +} srtp_profile_st; + +static const srtp_profile_st profile_names[] = { + { + "SRTP_AES128_CM_SHA1_80", + GNUTLS_SRTP_AES128_CM_SHA1_80, + }, + { + "SRTP_AES128_CM_SHA1_32", + GNUTLS_SRTP_AES128_CM_SHA1_32, + }, + { + "SRTP_NULL_SHA1_80", + GNUTLS_SRTP_NULL_SHA1_80, + }, + { + "SRTP_NULL_SHA1_32", + GNUTLS_SRTP_NULL_SHA1_32, + }, + { + NULL, + 0 + } +}; + +static gnutls_srtp_profile_t find_profile (const char *str, const char *end) +{ + const srtp_profile_st *prof = profile_names; + int len; + if (end != NULL) + { + len = end - str; + } + else + { + len = strlen (str); + } + + while (prof->name != NULL) + { + if (strlen (prof->name) == len && !strncmp (str, prof->name, len)) + { + return prof->id; + } + prof++; + } + return 0; +} + +/** + * gnutls_srtp_get_profile_by_name + * @name: The name of the profile to look up + * @profile: Will hold the profile id + * + * This function allows you to look up a profile based on a string. + * + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, + * otherwise a negative error code is returned. + **/ +int gnutls_srtp_get_profile_by_name (const char *name, + gnutls_srtp_profile_t *profile) +{ + *profile = find_profile (name, NULL); + if (*profile == 0) + { + return GNUTLS_E_ILLEGAL_PARAMETER; + } + return 0; +} + +/** + * gnutls_srtp_get_profile_name + * @profile: The profile to look up a string for + * + * This function allows you to get the corresponding name for a + * SRTP protection profile. + * + * Returns: On success, the name of a SRTP profile as a string, + * otherwise NULL. + **/ +const char *gnutls_srtp_get_profile_name (gnutls_srtp_profile_t profile) +{ + const srtp_profile_st *p = profile_names; + while (p->name != NULL) + { + if (p->id == profile) + return p->name; + p++; + } + return NULL; +} + +static int +_gnutls_srtp_recv_params (gnutls_session_t session, + const uint8_t *data, size_t _data_size) +{ + int i, j, ret; + const uint8_t *p = data; + int len; + ssize_t data_size = _data_size; + srtp_ext_st *priv; + extension_priv_data_t epriv; + uint16_t profiles[MAX_SRTP_PROFILES]; + unsigned int profiles_size = 0; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + return 0; + + priv = epriv.ptr; + + DECR_LENGTH_RET (data_size, 2, 0); + len = _gnutls_read_uint16 (p); + p += 2; + + while (len > 0) + { + DECR_LENGTH_RET (data_size, 2, 0); + if (profiles_size < MAX_SRTP_PROFILES) + profiles_size++; + profiles[profiles_size - 1] = _gnutls_read_uint16 (p); + p += 2; + len -= 2; + } + + for (i = 0; i < priv->profiles_size && priv->selected_profile == 0; i++) + { + for (j = 0; j < profiles_size; j++) + { + if (priv->profiles[i] == profiles[j]) + { + priv->selected_profile = profiles[j]; + break; + } + } + } + + return 0; +} + +static int +_gnutls_srtp_send_params (gnutls_session_t session, + gnutls_buffer_st* extdata) +{ + uint16_t len; + unsigned i; + int total_size = 0, ret; + srtp_ext_st *priv; + extension_priv_data_t epriv; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + return 0; + + priv = epriv.ptr; + + if (priv->profiles_size == 0) + return 0; + + if (session->security_parameters.entity == GNUTLS_SERVER) + { + /* Don't send anything if no matching profile was found */ + if (priv->selected_profile == 0) + return 0; + + ret = _gnutls_buffer_append_prefix(extdata, 16, 2); + if (ret < 0) + return gnutls_assert_val(ret); + ret = _gnutls_buffer_append_prefix(extdata, 16, priv->selected_profile); + if (ret < 0) + return gnutls_assert_val(ret); + total_size = 4; + } + else + { + ret = _gnutls_buffer_append_prefix(extdata, 16, 2 * priv->profiles_size); + if (ret < 0) + return gnutls_assert_val(ret); + + for (i = 0; i < priv->profiles_size; i++) + { + ret = _gnutls_buffer_append_prefix(extdata, 16, priv->profiles[i]); + if (ret < 0) + return gnutls_assert_val(ret); + } + total_size = 2 + 2 * priv->profiles_size; + } + + /* use_mki, not supported yet */ + ret = _gnutls_buffer_append_prefix(extdata, 8, 0); + if (ret < 0) + return gnutls_assert_val(ret); + + return total_size + 1; +} + +/** + * gnutls_srtp_get_selected_profile: + * @session: is a #gnutls_session_t structure. + * @profile: will hold the profile + * + * This function allows you to get the negotiated SRTP profile. + * + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, + * otherwise a negative error code is returned. + **/ +int +gnutls_srtp_get_selected_profile (gnutls_session_t session, + gnutls_srtp_profile_t *profile) +{ + srtp_ext_st *priv; + int ret; + extension_priv_data_t epriv; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + { + gnutls_assert (); + return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE; + } + + priv = epriv.ptr; + + if (priv->selected_profile == 0) + { + return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE; + } + + *profile = priv->selected_profile; + + return 0; +} + +/** + * gnutls_srtp_set_profile: + * @session: is a #gnutls_session_t structure. + * @profile: is the profile id to add. + * + * This function is to be used by both clients and servers, to declare + * what SRTP profiles they support, to negotiate with the peer. + * + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, + * otherwise a negative error code is returned. + **/ +int +gnutls_srtp_set_profile (gnutls_session_t session, + gnutls_srtp_profile_t profile) +{ + int ret; + srtp_ext_st *priv; + extension_priv_data_t epriv; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + { + priv = gnutls_calloc (1, sizeof (*priv)); + if (priv == NULL) + { + gnutls_assert (); + return GNUTLS_E_MEMORY_ERROR; + } + epriv.ptr = priv; + _gnutls_ext_set_session_data (session, GNUTLS_EXTENSION_SRTP, + epriv); + } + else + priv = epriv.ptr; + + if (priv->profiles_size < MAX_SRTP_PROFILES) + priv->profiles_size++; + priv->profiles[priv->profiles_size - 1] = profile; + + return 0; +} + +/** + * gnutls_srtp_set_profile_direct: + * @session: is a #gnutls_session_t structure. + * @profiles: is a string that contains the supported SRTP profiles, + * separated by colons. + * @err_pos: In case of an error this will have the position in the string the error occured, may be NULL. + * + * This function is to be used by both clients and servers, to declare + * what SRTP profiles they support, to negotiate with the peer. + * + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, + * otherwise a negative error code is returned. + **/ +int +gnutls_srtp_set_profile_direct (gnutls_session_t session, + const char *profiles, const char **err_pos) +{ + int ret; + srtp_ext_st *priv; + extension_priv_data_t epriv; + int set = 0; + const char *col; + gnutls_srtp_profile_t id; + + ret = + _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_SRTP, + &epriv); + if (ret < 0) + { + set = 1; + priv = gnutls_calloc (1, sizeof (*priv)); + if (priv == NULL) + { + if (err_pos != NULL) + *err_pos = profiles; + gnutls_assert (); + return GNUTLS_E_MEMORY_ERROR; + } + epriv.ptr = priv; + } + else + priv = epriv.ptr; + + do + { + col = strchr (profiles, ':'); + id = find_profile (profiles, col); + if (id == 0) + { + if (set != 0) + gnutls_free (priv); + if (err_pos != NULL) + *err_pos = profiles; + return GNUTLS_E_ILLEGAL_PARAMETER; + } + + if (priv->profiles_size < MAX_SRTP_PROFILES) + { + priv->profiles_size++; + } + priv->profiles[priv->profiles_size - 1] = id; + profiles = col + 1; + } while (col != NULL); + + if (set != 0) + _gnutls_ext_set_session_data (session, GNUTLS_EXTENSION_SRTP, + epriv); + + return 0; +} + +static void +_gnutls_srtp_deinit_data (extension_priv_data_t priv) +{ + gnutls_free (priv.ptr); +} + +static int +_gnutls_srtp_pack (extension_priv_data_t epriv, gnutls_buffer_st * ps) +{ + srtp_ext_st *priv = epriv.ptr; + unsigned int i; + int ret; + + BUFFER_APPEND_NUM (ps, priv->profiles_size); + for (i = 0; i < priv->profiles_size; i++) + { + BUFFER_APPEND_NUM (ps, priv->profiles[i]); + } + BUFFER_APPEND_NUM (ps, priv->selected_profile); + return 0; +} + +static int +_gnutls_srtp_unpack (gnutls_buffer_st * ps, + extension_priv_data_t * _priv) +{ + srtp_ext_st *priv; + unsigned int i; + int ret; + extension_priv_data_t epriv; + + priv = gnutls_calloc (1, sizeof (*priv)); + if (priv == NULL) + { + gnutls_assert (); + return GNUTLS_E_MEMORY_ERROR; + } + + BUFFER_POP_NUM (ps, priv->profiles_size); + for (i = 0; i < priv->profiles_size; i++) + { + BUFFER_POP_NUM (ps, priv->profiles[i]); + } + BUFFER_POP_NUM (ps, priv->selected_profile); + + epriv.ptr = priv; + *_priv = epriv; + + return 0; + +error: + gnutls_free (priv); + return ret; +} diff --git a/lib/ext/srtp.h b/lib/ext/srtp.h new file mode 100644 index 0000000..4a8dc81 --- /dev/null +++ b/lib/ext/srtp.h @@ -0,0 +1,38 @@ +/* + * Copyright (C) 2012 Free Software Foundation, Inc. + * + * Author: Martin Storsjo + * + * This file is part of GnuTLS. + * + * The GnuTLS is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 3 of + * the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program. If not, see + * + */ +#ifndef EXT_SRTP_H +#define EXT_SRTP_H + +#include + +#define MAX_SRTP_PROFILES 4 + +typedef struct +{ + gnutls_srtp_profile_t profiles[MAX_SRTP_PROFILES]; + unsigned profiles_size; + gnutls_srtp_profile_t selected_profile; +} srtp_ext_st; + +extern extension_entry_st ext_mod_srtp; + +#endif diff --git a/lib/gnutls_extensions.c b/lib/gnutls_extensions.c index aab0a67..28a852b 100644 --- a/lib/gnutls_extensions.c +++ b/lib/gnutls_extensions.c @@ -39,6 +39,7 @@ #include #include #include +#include #include @@ -354,6 +355,10 @@ _gnutls_ext_init (void) if (ret != GNUTLS_E_SUCCESS) return ret; + ret = _gnutls_ext_register (&ext_mod_srtp); + if (ret != GNUTLS_E_SUCCESS) + return ret; + return GNUTLS_E_SUCCESS; } diff --git a/lib/gnutls_int.h b/lib/gnutls_int.h index 1f103cb..68a176e 100644 --- a/lib/gnutls_int.h +++ b/lib/gnutls_int.h @@ -261,6 +261,7 @@ typedef enum extensions_t GNUTLS_EXTENSION_SUPPORTED_ECC_PF = 11, GNUTLS_EXTENSION_SRP = 12, GNUTLS_EXTENSION_SIGNATURE_ALGORITHMS = 13, + GNUTLS_EXTENSION_SRTP = 14, GNUTLS_EXTENSION_HEARTBEAT = 15, GNUTLS_EXTENSION_SESSION_TICKET = 35, GNUTLS_EXTENSION_SAFE_RENEGOTIATION = 65281 /* aka: 0xff01 */ diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in index 98a86fb..16cc962 100644 --- a/lib/includes/gnutls/gnutls.h.in +++ b/lib/includes/gnutls/gnutls.h.in @@ -962,6 +962,36 @@ gnutls_ecc_curve_t gnutls_ecc_curve_get(gnutls_session_t session); int gnutls_session_ticket_enable_server (gnutls_session_t session, const gnutls_datum_t * key); + /* SRTP, RFC 5764 */ + +/** + * gnutls_srtp_profile_t: + * @GNUTLS_SRTP_AES128_CM_SHA1_80: 128 bit AES with a 80 bit HMAC-SHA1 + * @GNUTLS_SRTP_AES128_CM_SHA1_32: 128 bit AES with a 32 bit HMAC-SHA1 + * @GNUTLS_SRTP_NULL_SHA1_80: NULL cipher with a 80 bit HMAC-SHA1 + * @GNUTLS_SRTP_NULL_SHA1_32: NULL cipher with a 32 bit HMAC-SHA1 + * + * Enumeration of different SRTP protection profiles. + */ + typedef enum + { + GNUTLS_SRTP_AES128_CM_SHA1_80 = 0x0001, + GNUTLS_SRTP_AES128_CM_SHA1_32 = 0x0002, + GNUTLS_SRTP_NULL_SHA1_80 = 0x0005, + GNUTLS_SRTP_NULL_SHA1_32 = 0x0006 + } gnutls_srtp_profile_t; + + int gnutls_srtp_set_profile (gnutls_session_t session, + gnutls_srtp_profile_t profile); + int gnutls_srtp_set_profile_direct (gnutls_session_t session, + const char *profiles, const char **err_pos); + int gnutls_srtp_get_selected_profile (gnutls_session_t session, + gnutls_srtp_profile_t *profile); + + const char *gnutls_srtp_get_profile_name (gnutls_srtp_profile_t profile); + int gnutls_srtp_get_profile_by_name (const char *name, + gnutls_srtp_profile_t *profile); + int gnutls_key_generate (gnutls_datum_t * key, unsigned int key_size); /* if you just want some defaults, use the following. diff --git a/lib/libgnutls.map b/lib/libgnutls.map index e20597c..b1f5b91 100644 --- a/lib/libgnutls.map +++ b/lib/libgnutls.map @@ -354,6 +354,11 @@ GNUTLS_1_4 gnutls_srp_set_server_credentials_file; gnutls_srp_set_server_credentials_function; gnutls_srp_verifier; + gnutls_srtp_get_profile_by_name; + gnutls_srtp_get_profile_name; + gnutls_srtp_get_selected_profile; + gnutls_srtp_set_profile; + gnutls_srtp_set_profile_direct; gnutls_strdup; gnutls_strerror; gnutls_strerror_name; -- 1.7.9.4 From adys.wh at gmail.com Thu Nov 1 04:25:05 2012 From: adys.wh at gmail.com (Jerome Leclanche) Date: Thu, 1 Nov 2012 03:25:05 +0000 Subject: conftest against -lgnutls fails with libtasn1 3.0 Message-ID: Morning Arch Linux updated to libtasn1 3.0 yesterday. Wine no longer passes configure --with-gnutls. Adding -ltasn1 to /usr/lib/pkgconfig/gnutls.pc fixes the issue. #archlinux suggested reporting it upstream, so I wanted to ping it on the ML. Attached is the relevant config.log bit, if anyone is curious. Suggestions? J. Leclanche -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 8134 bytes Desc: not available URL: From ametzler at downhill.at.eu.org Thu Nov 1 08:26:53 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 1 Nov 2012 08:26:53 +0100 Subject: conftest against -lgnutls fails with libtasn1 3.0 In-Reply-To: References: Message-ID: <20121101072653.GA3140@downhill.g.la> On 2012-11-01 Jerome Leclanche wrote: > Morning > Arch Linux updated to libtasn1 3.0 yesterday. Wine no longer passes > configure --with-gnutls. > Adding -ltasn1 to /usr/lib/pkgconfig/gnutls.pc fixes the issue. #archlinux > suggested reporting it upstream, so I wanted to ping it on the ML. > Attached is the relevant config.log bit, if anyone is curious. Suggestions? [...] | /usr/bin/ld: warning: libtasn1.so.3, needed by | /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib32/libgnutls.so, | not found This looks like you were trying to link against a version of gnutls which was built against libtasn1 2.x but did not install libtasn 2.x. libtasn 3.x and 2.x are not binary compatible (which is why the soname was changed), depending software including gnutls needs to be rebuilt to use the newer tasn version. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ametzler at downhill.at.eu.org Thu Nov 1 10:26:38 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 1 Nov 2012 10:26:38 +0100 Subject: GNU Libtasn1 3.0 released In-Reply-To: <508D396E.2030804@gnutls.org> References: <508D396E.2030804@gnutls.org> Message-ID: <20121101092638.GB3140@downhill.g.la> On 2012-10-28 Nikos Mavrogiannopoulos wrote: [...] > * Noteworthy changes in release 3.0 (2012-10-28) [stable] [...] > ASN1_ARRAY_TYPE -> asn1_static_node [...] Hello, afaict this is slightly incorrect, the new label is asn1_static_node_t. cu Andreas From nmav at gnutls.org Thu Nov 1 15:24:07 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 Nov 2012 15:24:07 +0100 Subject: GNU Libtasn1 3.0 released In-Reply-To: <20121101092638.GB3140@downhill.g.la> References: <508D396E.2030804@gnutls.org> <20121101092638.GB3140@downhill.g.la> Message-ID: <50928607.3080403@gnutls.org> On 11/01/2012 10:26 AM, Andreas Metzler wrote: > Hello, > > afaict this is slightly incorrect, the new label is > asn1_static_node_t. Thanks for pointing out. I've fixed it. regards, Nikos From nmav at gnutls.org Thu Nov 1 16:08:02 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 Nov 2012 16:08:02 +0100 Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: <1351726495-55549-1-git-send-email-martin@martin.st> References: <1351726495-55549-1-git-send-email-martin@martin.st> Message-ID: <50929052.7030102@gnutls.org> On 11/01/2012 12:34 AM, Martin Storsjo wrote: > --- > Implemented what was suggested before, and moved some hunks that I > accidentally had placed in patch 2/2 in the previous patchset. > --- > NEWS | 6 + > doc/Makefile.am | 10 + > doc/protocol/rfc5764.txt | 1459 +++++++++++++++++++++++++++++++++++++++ > lib/ext/Makefile.am | 2 +- > lib/ext/srtp.c | 465 +++++++++++++ > lib/ext/srtp.h | 38 + > lib/gnutls_extensions.c | 5 + > lib/gnutls_int.h | 1 + > lib/includes/gnutls/gnutls.h.in | 30 + > lib/libgnutls.map | 5 + > 10 files changed, 2020 insertions(+), 1 deletion(-) > create mode 100644 doc/protocol/rfc5764.txt > create mode 100644 lib/ext/srtp.c > create mode 100644 lib/ext/srtp.h Hello Martin, I've applied it. Thank you. I've done the following changes: * gnutls_srtp_set_profile_direct returns GNUTLS_E_INVALID_REQUEST on parsing error * changed the copyright to you until the formal paperwork is finished (so we can roll a release with it). I've also added a test program in tests/mini-dtls-srtp.c. Could you help there with the correct extractor parameters so that this is also checked? Is the key size fixed for each profile? If yes, then wouldn't be easier to have a helper function to extract the key, based on the negotiated profile? regards, Nikos From martin at martin.st Thu Nov 1 16:31:26 2012 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Thu, 1 Nov 2012 17:31:26 +0200 (EET) Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: <50929052.7030102@gnutls.org> References: <1351726495-55549-1-git-send-email-martin@martin.st> <50929052.7030102@gnutls.org> Message-ID: Hi, On Thu, 1 Nov 2012, Nikos Mavrogiannopoulos wrote: > On 11/01/2012 12:34 AM, Martin Storsjo wrote: > >> --- >> Implemented what was suggested before, and moved some hunks that I >> accidentally had placed in patch 2/2 in the previous patchset. >> --- >> NEWS | 6 + >> doc/Makefile.am | 10 + >> doc/protocol/rfc5764.txt | 1459 +++++++++++++++++++++++++++++++++++++++ >> lib/ext/Makefile.am | 2 +- >> lib/ext/srtp.c | 465 +++++++++++++ >> lib/ext/srtp.h | 38 + >> lib/gnutls_extensions.c | 5 + >> lib/gnutls_int.h | 1 + >> lib/includes/gnutls/gnutls.h.in | 30 + >> lib/libgnutls.map | 5 + >> 10 files changed, 2020 insertions(+), 1 deletion(-) >> create mode 100644 doc/protocol/rfc5764.txt >> create mode 100644 lib/ext/srtp.c >> create mode 100644 lib/ext/srtp.h > > Hello Martin, > I've applied it. Thank you. I've done the following changes: > * gnutls_srtp_set_profile_direct returns GNUTLS_E_INVALID_REQUEST on > parsing error Great, thanks! > * changed the copyright to you until the formal paperwork is finished > (so we can roll a release with it). Ok, I got the FSF registration mail a little while ago and I'll post the snailmail papers back to FSF soon. > I've also added a test program in tests/mini-dtls-srtp.c. Could you help > there with the correct extractor parameters so that this is also checked? Based on my reading of RFC 5764, one doesn't set any extra context data for the extractor, only the label. Or this is at least my interpretation of "The per-association context value is empty." in section 4.2 in RFC 5764 - the one only extracts one single blob of data using the PRF of the length given in that section (2 master keys and 2 master salts). The other interpretation would be using the names "client_write_SRTP_master_key" and such as context, but I don't think that's the case. I don't have access to any full setup with DTLS-SRTP yet to test this against - I've only tested it against OpenSSL for compatibility with the SRTP options one can set there, but I'l still lacking a full setup with this integrated into a SRTP stack to test against. I'm hoping to get such a test env soon, though. > Is the key size fixed for each profile? If yes, then wouldn't be easier > to have a helper function to extract the key, based on the negotiated > profile? Yes, the master key size should be 128 bit and the master salt size 112 bit, so having a function extract all of it at once would be useful. But it might be better to hold back on this until I've actually got those parts tested against some other reference. // Martin From martin at martin.st Thu Nov 1 16:34:44 2012 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Thu, 1 Nov 2012 17:34:44 +0200 (EET) Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: References: <1351726495-55549-1-git-send-email-martin@martin.st> <50929052.7030102@gnutls.org> Message-ID: On Thu, 1 Nov 2012, Martin Storsj? wrote: > On Thu, 1 Nov 2012, Nikos Mavrogiannopoulos wrote: > >> Is the key size fixed for each profile? If yes, then wouldn't be easier >> to have a helper function to extract the key, based on the negotiated >> profile? > > Yes, the master key size should be 128 bit and the master salt size 112 bit, To clarify, this is the case for both the AES128_CM and NULL modes - in the NULL cipher mode, the packets still have HMAC-SHA1 authentication, and the master key and salt are required for deriving the key to the HMAC. // Martin From martin at martin.st Thu Nov 1 21:49:00 2012 From: martin at martin.st (Martin Storsjo) Date: Thu, 1 Nov 2012 22:49:00 +0200 Subject: [PATCH] Fix typos in error messages Message-ID: <1351802940-297-1-git-send-email-martin@martin.st> --- src/cli.c | 2 +- src/serv.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/cli.c b/src/cli.c index 6064ad4..8c1df65 100644 --- a/src/cli.c +++ b/src/cli.c @@ -680,7 +680,7 @@ init_tls_session (const char *hostname) ret = gnutls_srtp_set_profile_direct (session, OPT_ARG(SRTP_PROFILES), &err); if (ret == GNUTLS_E_INVALID_REQUEST) fprintf (stderr, "Syntax error at: %s\n", err); else - fprintf(stderr, "Error in priorities: %s\n", gnutls_strerror(ret)); + fprintf(stderr, "Error in profiles: %s\n", gnutls_strerror(ret)); exit (1); } diff --git a/src/serv.c b/src/serv.c index db6b9e4..3541fbd 100644 --- a/src/serv.c +++ b/src/serv.c @@ -399,7 +399,7 @@ gnutls_session_t initialize_session (int dtls) ret = gnutls_srtp_set_profile_direct (session, OPT_ARG(SRTP_PROFILES), &err); if (ret == GNUTLS_E_INVALID_REQUEST) fprintf (stderr, "Syntax error at: %s\n", err); else - fprintf(stderr, "Error in priorities: %s\n", gnutls_strerror(ret)); + fprintf(stderr, "Error in profiles: %s\n", gnutls_strerror(ret)); exit (1); } -- 1.7.9.4 From nmav at gnutls.org Fri Nov 2 00:01:46 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 02 Nov 2012 00:01:46 +0100 Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: References: <1351726495-55549-1-git-send-email-martin@martin.st> <50929052.7030102@gnutls.org> Message-ID: <5092FF5A.5070803@gnutls.org> On 11/01/2012 04:31 PM, Martin Storsj? wrote: > Based on my reading of RFC 5764, one doesn't set any extra context data > for the extractor, only the label. Or this is at least my interpretation > of "The per-association context value is empty." in section 4.2 in RFC > 5764 - the one only extracts one single blob of data using the PRF of > the length given in that section (2 master keys and 2 master salts). Hello, I'm confused on what is a master key. For example the RFC lists: SRTP_NULL_HMAC_SHA1_80 cipher: NULL cipher_key_length: 0 cipher_salt_length: 0 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80 but there is no master key size there. Is the master key size negotiated through other means? regards, Nikos From nmav at gnutls.org Fri Nov 2 00:06:47 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 02 Nov 2012 00:06:47 +0100 Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: References: <1351726495-55549-1-git-send-email-martin@martin.st> <50929052.7030102@gnutls.org> Message-ID: <50930087.7050701@gnutls.org> On 11/01/2012 04:31 PM, Martin Storsj? wrote: >> Is the key size fixed for each profile? If yes, then wouldn't be easier >> to have a helper function to extract the key, based on the negotiated >> profile? > Yes, the master key size should be 128 bit and the master salt size 112 > bit, so having a function extract all of it at once would be useful. But > it might be better to hold back on this until I've actually got those > parts tested against some other reference. I've hacked a helper function (gnutls_srtp_get_keys) with these values. It would be nice if you can verify its correctness, and if it is not, we fix it. regards, Nikos From martin at martin.st Fri Nov 2 00:22:19 2012 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Fri, 2 Nov 2012 01:22:19 +0200 (EET) Subject: [PATCH v2 1/2] Add support for DTLS-SRTP profile negotiation (RFC 5764) In-Reply-To: <5092FF5A.5070803@gnutls.org> References: <1351726495-55549-1-git-send-email-martin@martin.st> <50929052.7030102@gnutls.org> <5092FF5A.5070803@gnutls.org> Message-ID: On Fri, 2 Nov 2012, Nikos Mavrogiannopoulos wrote: > On 11/01/2012 04:31 PM, Martin Storsj? wrote: > > >> Based on my reading of RFC 5764, one doesn't set any extra context data >> for the extractor, only the label. Or this is at least my interpretation >> of "The per-association context value is empty." in section 4.2 in RFC >> 5764 - the one only extracts one single blob of data using the PRF of >> the length given in that section (2 master keys and 2 master salts). > > Hello, > I'm confused on what is a master key. For example the RFC lists: > SRTP_NULL_HMAC_SHA1_80 > cipher: NULL > cipher_key_length: 0 > cipher_salt_length: 0 > maximum_lifetime: 2^31 > auth_function: HMAC-SHA1 > auth_key_length: 160 > auth_tag_length: 80 > > but there is no master key size there. Is the master key size negotiated > through other means? No, the master key size isn't negotiated through other means, it's specified in RFC 3711 section 8.2. The gnutls_srtp_get_keys function you implemented looks correct to me, I'll verify it against an existing implementation of DTLS-SRTP as soon as I get my hands on one. // Martin From ametzler at downhill.at.eu.org Sat Nov 3 13:42:39 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 3 Nov 2012 13:42:39 +0100 Subject: libtasn1 3.0 + gnutls2.12.x Message-ID: <20121103124239.GB3104@downhill.g.la> Hello, do you plan to also apply f558716ec2fe876b8ba85b9c3093aedfd6800243 to the gnutls2.x branch, allowing compilation against libtasn1 3.0? cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sat Nov 3 19:16:53 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 03 Nov 2012 19:16:53 +0100 Subject: libtasn1 3.0 + gnutls2.12.x In-Reply-To: <20121103124239.GB3104@downhill.g.la> References: <20121103124239.GB3104@downhill.g.la> Message-ID: <50955F95.9010507@gnutls.org> On 11/03/2012 01:42 PM, Andreas Metzler wrote: > Hello, > do you plan to also apply f558716ec2fe876b8ba85b9c3093aedfd6800243 to the > gnutls2.x branch, allowing compilation against libtasn1 3.0? Hi, I applied it. However I don't really plan to actively maintain 2.12.x. It is quite some different from the 3 series and is too much work. regards, Nikos From nmav at gnutls.org Sat Nov 3 20:26:33 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 03 Nov 2012 20:26:33 +0100 Subject: gnutls + openpgp Message-ID: <50956FE9.60203@gnutls.org> Hello, It seem that the IETF TLS working group is defining a new certificate type extension, which in short makes the openpgp certificate type extension obsolete. The authors of the new draft are not very keen into adding the openpgp key type into the new certificate type extension, based on the fact that this is not widely used. So my question is does it really make sense to pursue that? Are there applications using gnutls with openpgp keys? And even more, if it is shown they are not widely used, does it make sense to support openpgp keys in gnutls at all? regards, Nikos From home_pw at msn.com Sat Nov 3 21:55:19 2012 From: home_pw at msn.com (Peter Williams) Date: Sat, 3 Nov 2012 13:55:19 -0700 Subject: gnutls + openpgp In-Reply-To: <50956FE9.60203@gnutls.org> References: <50956FE9.60203@gnutls.org> Message-ID: So what are they doing ... That cannot be done within the existing type definer? If folks need an extension, there are two reasons: 1) the concept needs replacing (eg define life do pgp Certs are undefinable) 2) one needs the tcp or http stack to be doing interpretation, before connect establish. I can guess this is related to dnssec, preventing connection establish if the tcp engine cannot confirm the new-cert is registered by DNs All part of the militarization of the web, I suspect. Sent from my iPhone On Nov 3, 2012, at 12:26 PM, "Nikos Mavrogiannopoulos" wrote: > Hello, > It seem that the IETF TLS working group is defining a new certificate > type extension, which in short makes the openpgp certificate type > extension obsolete. The authors of the new draft are not very keen into > adding the openpgp key type into the new certificate type extension, > based on the fact that this is not widely used. So my question is does > it really make sense to pursue that? Are there applications using gnutls > with openpgp keys? > > And even more, if it is shown they are not widely used, does it make > sense to support openpgp keys in gnutls at all? > > regards, > Nikos > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel From n.mavrogiannopoulos at gmail.com Sun Nov 4 12:05:04 2012 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 04 Nov 2012 12:05:04 +0100 Subject: gnutls + openpgp In-Reply-To: References: <50956FE9.60203@gnutls.org> Message-ID: <50964BE0.1030306@gmail.com> On 11/03/2012 10:01 PM, Richard Moore wrote: > On 3 November 2012 19:26, Nikos Mavrogiannopoulos wrote: >> And even more, if it is shown they are not widely used, does it make >> sense to support openpgp keys in gnutls at all? > If they're not used, then supporting them simply means gnutls has a > bigger attack surface for no benefit. This is not really true. One needs to specifically enable the openpgp. That codebase doesn't affect an application which is only using the X.509 part of gnutls. The main concern IMO, is the maintenance cost, and it'd be better not to have it if there are no users of the subsystem. regards, Nikos From ott at mirix.org Sun Nov 4 19:44:43 2012 From: ott at mirix.org (Matthias-Christian Ott) Date: Sun, 04 Nov 2012 19:44:43 +0100 Subject: gnutls + openpgp In-Reply-To: <50956FE9.60203@gnutls.org> References: <50956FE9.60203@gnutls.org> Message-ID: <5096B79B.1080809@mirix.org> On 2012-11-03 20:26, Nikos Mavrogiannopoulos wrote: > And even more, if it is shown they are not widely used, does it make > sense to support openpgp keys in gnutls at all? Despite of mod_gnutls I'm not aware of any software that supports it. I tried to make Mozilla aware of TLS with OpenPGP [1], but (I think) there seems to be no interest and getting support for this into NSS didn't seem "politically" easy. So it's a chicken and egg problem. I wouldn't remove it, because otherwise X.509 is the only means of authentication in TLS (I think everything in the X.509 vs. OpenPGP debate has been said and both have their practical reasons for existence). Perhaps draft-ietf-tls-oob-pubkey is a compromise. Regards, Matthias-Christian [1] https://bugzilla.mozilla.org/show_bug.cgi?id=290029 From wk at gnupg.org Mon Nov 5 09:32:29 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Nov 2012 09:32:29 +0100 Subject: gnutls + openpgp In-Reply-To: <5096B79B.1080809@mirix.org> (Matthias-Christian Ott's message of "Sun, 04 Nov 2012 19:44:43 +0100") References: <50956FE9.60203@gnutls.org> <5096B79B.1080809@mirix.org> Message-ID: <87objc1mci.fsf@vigenere.g10code.de> On Sun, 4 Nov 2012 19:44, ott at mirix.org said: > Despite of mod_gnutls I'm not aware of any software that supports it. I > tried to make Mozilla aware of TLS with OpenPGP [1], but (I think) there > seems to be no interest and getting support for this into NSS didn't > seem "politically" easy. So it's a chicken and egg problem. It is even not possible to get OpenPGP into Thunderbird, proper. We tried this since about 2000 without any success. It is a pity that you need the Enigmail extension instead of having proper support included in Thunderbird. Almost all other mail clients support OpenPGP - with the exception of Outlook and Thunderbird. Thus why should they support a TLS option in Firefox if they don't even support the de-facto mail encryption standard in Thunderbird. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Nov 6 05:32:24 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Nov 2012 23:32:24 -0500 Subject: gnutls + openpgp In-Reply-To: <50956FE9.60203@gnutls.org> References: <50956FE9.60203@gnutls.org> Message-ID: <509892D8.9040003@fifthhorseman.net> On 11/03/2012 03:26 PM, Nikos Mavrogiannopoulos wrote: > It seem that the IETF TLS working group is defining a new certificate > type extension, which in short makes the openpgp certificate type > extension obsolete. The authors of the new draft are not very keen into > adding the openpgp key type into the new certificate type extension, > based on the fact that this is not widely used. So my question is does > it really make sense to pursue that? Are there applications using gnutls > with openpgp keys? > > And even more, if it is shown they are not widely used, does it make > sense to support openpgp keys in gnutls at all? given the hassle involved in convincing other major TLS implementations to adopt TLS extensions, and the lack of adoption of OpenPGP certificates in TLS in general, i've been thinking recently that the simpler approach is just to propose and implement new "standards" within the X.509 space and allow the verifiers to transform the weird certificates on either side. The worst thing that happens there is something akin to a browser warning; and if you can propose an X.509 verification routine or plugin for the peers, it's possibly narrower in scope than asking for a TLS extension. The downside of this approach, of course, is that there's no clear way to signal that a non-standard X.509 certificate would be acceptable for the remote peer :( Oh, and the other major downside of course is that the X.509 format is a really ungainly one, if you had to choose a generic container. I'm pretty disheartened by the TLS WG's rationales for discarding RFC 6091 when working on oob-key, though. If the main concern is that there isn't a mechanism for indicating the difference between what kinds of certificates you're prepared to offer, and what kind of certificates you're prepared to accept, then it seems to me that should be fixed as a revision of 6091, rather than maintain two separate registries of certificate types. I'd reply with something like this on the IETF list, but i'm not sure how useful that would be, given the back-and-forth you've already had. Any thoughts on what sort of feedback i might give that would be useful? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From code at funwithsoftware.org Wed Nov 7 03:32:24 2012 From: code at funwithsoftware.org (Patrick Pelletier) Date: Tue, 06 Nov 2012 18:32:24 -0800 Subject: gnutls + openpgp In-Reply-To: <50956FE9.60203@gnutls.org> References: <50956FE9.60203@gnutls.org> Message-ID: <5099C838.2050108@funwithsoftware.org> On 11/3/12 12:26 PM, Nikos Mavrogiannopoulos wrote: > And even more, if it is shown they are not widely used, does it make > sense to support openpgp keys in gnutls at all? FWIW, I noticed that the hs-tls folks have expressed some interest in OpenPGP, although admittedly there's been no further activity in 7 months: https://github.com/vincenthz/hs-tls/issues/10 But still, it might be worthwhile to touch base with those guys. It would be somewhat ironic if GnuTLS dropped support for OpenPGP at the same time hs-tls was adding support. --Patrick From nmav at gnutls.org Thu Nov 8 22:57:25 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Nov 2012 22:57:25 +0100 Subject: gnutls + openpgp In-Reply-To: <5099C838.2050108@funwithsoftware.org> References: <50956FE9.60203@gnutls.org> <5099C838.2050108@funwithsoftware.org> Message-ID: <509C2AC5.1050904@gnutls.org> On 11/07/2012 03:32 AM, Patrick Pelletier wrote: > On 11/3/12 12:26 PM, Nikos Mavrogiannopoulos wrote: > >> And even more, if it is shown they are not widely used, does it make >> sense to support openpgp keys in gnutls at all? > > FWIW, I noticed that the hs-tls folks have expressed some interest in > OpenPGP, although admittedly there's been no further activity in 7 months: > > https://github.com/vincenthz/hs-tls/issues/10 > > But still, it might be worthwhile to touch base with those guys. It > would be somewhat ironic if GnuTLS dropped support for OpenPGP at the > same time hs-tls was adding support. Hello Patrick, Even if this code will be removed at some point this will not be anytime soon. If it proves that there no users at all then it will be marked as deprecated and stay in the code as a second class citizen (no new features being added) until the next ABI break. regards, Nikos From nmav at gnutls.org Thu Nov 8 23:56:30 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Nov 2012 23:56:30 +0100 Subject: gnutls 2.12.21 Message-ID: <509C389E.8000901@gnutls.org> Hello, I've just released gnutls 2.12.21. It includes few bug fixes in the old stable branch. Version 2.12.21 (released 2012-11-08) ** libgnutls: Backported patch to compile with libtasn1 3.0. Minimum libtasn1 dependency is now 2.14. ** libgnutls: Always tolerate key usage violation errors from the side of the peer, but also notify via an audit message. ** minitasn1: Upgraded to libtasn1 version 3.0. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.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 Fri Nov 9 00:41:30 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 09 Nov 2012 00:41:30 +0100 Subject: gnutls 3.0.26 Message-ID: <509C432A.7080008@gnutls.org> Hello, I've just released gnutls 3.0.26. This is a bug-fix release on the previous stable branch. * Version 3.0.26 (released 2012-11-09) ** libgnutls: Always tolerate key usage violation errors from the side of the peer, but also notify via an audit message. ** libgnutls: gnutls_x509_crl_verify() includes time checks. ** libgnutls: Increased maximum password length in the PKCS #12 functions. ** API and ABI modifications: GNUTLS_CERT_REVOCATION_DATA_TOO_OLD: Added GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz.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 Sat Nov 10 01:05:58 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Nov 2012 01:05:58 +0100 Subject: gnutls 3.1.4 Message-ID: <509D9A66.3010404@gnutls.org> Hello, I've just released gnutls 3.1.4. This release includes initial support for the DTLS-SRTP protocol contributed by martin Storsjo updated on the new DANE library, and several simplifications on the existing API. * Version 3.1.4 (released 2012-11-10) ** libgnutls: gnutls_certificate_verify_peers2() will set flags depending on the available revocation data validity. ** libgnutls: Added gnutls_certificate_verification_status_print(), a function to print the verification status code in human readable text. ** libgnutls: Added priority string %VERIFY_DISABLE_CRL_CHECKS. ** libgnutls: Simplified certificate verification by adding gnutls_certificate_verify_peers3(). ** libgnutls: Added support for extension to establish keys for SRTP. Contributed by Martin Storsjo. ** libgnutls: The X.509 verification functions check the key usage bits and pathlen constraints and on failure output GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE. ** libgnutls: gnutls_x509_crl_verify() includes the time checks. ** libgnutls: Added verification flag GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN and made GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN the default. ** libgnutls: Always tolerate key usage violation errors from the side of the peer, but also notify via an audit message. ** gnutls-cli: Added --local-dns option. ** danetool: Corrected bug that prevented loading PEM files. ** danetool: Added --check option to allow querying and verifying a site's DANE data. ** libgnutls-dane: Added pkg-config file for the library. ** API and ABI modifications: gnutls_session_get_id2: Added gnutls_sign_is_secure: Added gnutls_certificate_verify_peers3: Added gnutls_ocsp_status_request_is_checked: Added gnutls_certificate_verification_status_print: Added gnutls_srtp_set_profile: Added gnutls_srtp_set_profile_direct: Added gnutls_srtp_get_selected_profile: Added gnutls_srtp_get_profile_name: Added gnutls_srtp_get_profile_id: Added gnutls_srtp_get_keys: Added gnutls_srtp_get_mki: Added gnutls_srtp_set_mki: Added gnutls_srtp_profile_t: Added dane_cert_type_name: Added dane_match_type_name: Added dane_cert_usage_name: Added dane_verification_status_print: Added GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED: Added GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE: Added GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE: Added GNUTLS_CERT_UNEXPECTED_OWNER: Added GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz.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 flameeyes at flameeyes.eu Sat Nov 10 02:41:45 2012 From: flameeyes at flameeyes.eu (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Fri, 9 Nov 2012 17:41:45 -0800 Subject: [PATCH] build: only run the dane cert test if dane is enabled. Message-ID: <1352511705-442823-1-git-send-email-flameeyes@flameeyes.eu> This fixes a test failure when disabling dane support. Signed-off-by: Diego Elio Petten? --- tests/cert-tests/Makefile.am | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tests/cert-tests/Makefile.am b/tests/cert-tests/Makefile.am index 367ab59..15ac543 100644 --- a/tests/cert-tests/Makefile.am +++ b/tests/cert-tests/Makefile.am @@ -25,6 +25,10 @@ EXTRA_DIST = ca-no-pathlen.pem no-ca-or-pathlen.pem aki-cert.pem \ dist_check_SCRIPTS = pathlen aki template-test pem-decoding dane -TESTS = pathlen aki template-test pem-decoding dane +TESTS = pathlen aki template-test pem-decoding + +if ENABLE_DANE +TESTS += dane +endif TESTS_ENVIRONMENT = EXEEXT=$(EXEEXT) -- 1.7.12.4 From nmav at gnutls.org Sat Nov 10 10:49:17 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Nov 2012 10:49:17 +0100 Subject: [PATCH] build: only run the dane cert test if dane is enabled. In-Reply-To: <1352511705-442823-1-git-send-email-flameeyes@flameeyes.eu> References: <1352511705-442823-1-git-send-email-flameeyes@flameeyes.eu> Message-ID: <509E231D.4070600@gnutls.org> On 11/10/2012 02:41 AM, Diego Elio Petten? wrote: > This fixes a test failure when disabling dane support. > > Signed-off-by: Diego Elio Petten? > --- > tests/cert-tests/Makefile.am | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/tests/cert-tests/Makefile.am b/tests/cert-tests/Makefile.am > index 367ab59..15ac543 100644 > --- a/tests/cert-tests/Makefile.am > +++ b/tests/cert-tests/Makefile.am > @@ -25,6 +25,10 @@ EXTRA_DIST = ca-no-pathlen.pem no-ca-or-pathlen.pem aki-cert.pem \ > > dist_check_SCRIPTS = pathlen aki template-test pem-decoding dane > > -TESTS = pathlen aki template-test pem-decoding dane > +TESTS = pathlen aki template-test pem-decoding > + > +if ENABLE_DANE > +TESTS += dane > +endif Thanks. Applied. regards, Nikos From nmav at gnutls.org Sat Nov 10 11:23:56 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Nov 2012 11:23:56 +0100 Subject: gnutls 3.0.26 In-Reply-To: <84fw4iqs08.fsf@aol.com> References: <509C432A.7080008@gnutls.org> <84fw4iqs08.fsf@aol.com> Message-ID: <509E2B3C.6060608@gnutls.org> On 11/10/2012 12:24 AM, nyc4bos at aol.com wrote: >> Hello, >> I've just released gnutls 3.0.26. This is a bug-fix release on the >> previous stable branch. > > Is there a precompiled binary Windows version of GnuTLS 3.0.26 available? No but you can use 3.1.4. They are binary and source compatible. regards, Nikos From a.radke at arcor.de Sat Nov 10 20:12:22 2012 From: a.radke at arcor.de (Andreas Radke) Date: Sat, 10 Nov 2012 20:12:22 +0100 Subject: gnutls 3.1.4 In-Reply-To: <509D9A66.3010404@gnutls.org> References: <509D9A66.3010404@gnutls.org> Message-ID: <20121110201222.7d7491f3@laptop64.home> With this new release the test suite fails here in ArchLinux: make check-TESTS make[3]: Entering directory `/build/src/gnutls-3.1.4/tests/cert-tests' PASS: pathlen PASS: aki ./template-test: line 27: datefudge: command not found You need datefudge to run this test SKIP: template-test PASS: pem-decoding FAIL: dane =================================== 1 of 4 tests failed (1 test was not run) Please report to bug-gnutls at gnu.org =================================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/build/src/gnutls-3.1.4/tests/cert-tests' make[2]: *** [check-am] Error 2 make[2]: Target `check' not remade because of errors. -Andy From flameeyes at flameeyes.eu Sat Nov 10 20:22:56 2012 From: flameeyes at flameeyes.eu (=?UTF-8?Q?Diego_Elio_Petten=C3=B2?=) Date: Sat, 10 Nov 2012 11:22:56 -0800 Subject: gnutls 3.1.4 In-Reply-To: <20121110201222.7d7491f3@laptop64.home> References: <509D9A66.3010404@gnutls.org> <20121110201222.7d7491f3@laptop64.home> Message-ID: I've sent a patch for that yesterday if you look at the archives. Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ On Sat, Nov 10, 2012 at 11:12 AM, Andreas Radke wrote: > With this new release the test suite fails here in ArchLinux: > > make check-TESTS > make[3]: Entering directory `/build/src/gnutls-3.1.4/tests/cert-tests' > PASS: pathlen > PASS: aki > ./template-test: line 27: datefudge: command not found > You need datefudge to run this test > SKIP: template-test > PASS: pem-decoding > FAIL: dane > =================================== > 1 of 4 tests failed > (1 test was not run) > Please report to bug-gnutls at gnu.org > =================================== > make[3]: *** [check-TESTS] Error 1 > make[3]: Leaving directory `/build/src/gnutls-3.1.4/tests/cert-tests' > make[2]: *** [check-am] Error 2 > make[2]: Target `check' not remade because of errors. > > > -Andy > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel From ml at smtp.fakessh.eu Sat Nov 10 21:33:47 2012 From: ml at smtp.fakessh.eu (ml) Date: Sat, 10 Nov 2012 21:33:47 +0100 Subject: gnutls 2.12.21 In-Reply-To: <509C389E.8000901@gnutls.org> References: <509C389E.8000901@gnutls.org> Message-ID: <1352579627.8253.7.camel@localhost> hello Nikos nice day after an attempt to build an rpm for centos 5 build fails with a weird error and I've verifies the signature gpg make[4]: Entering directory `/usr/src/redhat/BUILD/gnutls-2.12.21/lib/minitasn1' CC decoding.lo CC gstr.lo CC errors.lo CC parser_aux.lo parser_aux.c:23:27: error: hash-pjw-bare.h: No such file or directory parser_aux.c: In function 'asn1_find_node': parser_aux.c:122: warning: implicit declaration of function 'hash_pjw_bare' make[4]: *** [parser_aux.lo] Error 1 make[4]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21/lib/minitasn1' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21' make: *** [all] Error 2 erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.10950 (%build) Erreur de construction de RPM: Mauvais status de sortie pour /var/tmp/rpm-tmp.10950 (%build) any idee are welcome I'm missing a header file sincerely your Le jeudi 08 novembre 2012 ? 23:56 +0100, Nikos Mavrogiannopoulos a ?crit : > Hello, > I've just released gnutls 2.12.21. It includes few bug fixes in the old > stable branch. > > Version 2.12.21 (released 2012-11-08) > > ** libgnutls: Backported patch to compile with libtasn1 3.0. > Minimum libtasn1 dependency is now 2.14. > > ** libgnutls: Always tolerate key usage violation errors from the side > of the peer, but also notify via an audit message. > > ** minitasn1: Upgraded to libtasn1 version 3.0. > > ** API and ABI modifications: > No changes since last version. > > > Getting the Software > ==================== > > GnuTLS may be downloaded from one of the GNU mirror sites or directly > From found at and a list of GnuTLS mirrors > can be found at . > > Here are the BZIP2 compressed sources: > > ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2 > http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2 > > Here are OpenPGP detached signatures signed using key 0x96865171: > > ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.sig > http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.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 > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel -- gpg --keyserver pgp.mit.edu --recv-key C2626742 http://about.me/fakessh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ml at smtp.fakessh.eu Sun Nov 11 00:36:28 2012 From: ml at smtp.fakessh.eu (ml) Date: Sun, 11 Nov 2012 00:36:28 +0100 Subject: gnutls 2.12.21 In-Reply-To: <1352579627.8253.7.camel@localhost> References: <509C389E.8000901@gnutls.org> <1352579627.8253.7.camel@localhost> Message-ID: <95fa2e8523fa962981344d9c5a799c72@roundcube.fakessh.eu> hi guys it seems that this header just missing feature backported from superior versions. This error must be corrected easily I guess Le 2012-11-10 21:33, ml a ?crit?: > hello Nikos > nice day > > after an attempt to build an rpm for centos 5 > build fails with a weird error and I've verifies the signature gpg > > make[4]: Entering directory > `/usr/src/redhat/BUILD/gnutls-2.12.21/lib/minitasn1' > CC decoding.lo > CC gstr.lo > CC errors.lo > CC parser_aux.lo > parser_aux.c:23:27: error: hash-pjw-bare.h: No such file or directory > parser_aux.c: In function 'asn1_find_node': > parser_aux.c:122: warning: implicit declaration of function > 'hash_pjw_bare' > make[4]: *** [parser_aux.lo] Error 1 > make[4]: Leaving directory > `/usr/src/redhat/BUILD/gnutls-2.12.21/lib/minitasn1' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/src/redhat/BUILD/gnutls-2.12.21' > make: *** [all] Error 2 > erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.10950 (%build) > > > Erreur de construction de RPM: > Mauvais status de sortie pour /var/tmp/rpm-tmp.10950 (%build) > > > any idee are welcome > > I'm missing a header file > > > sincerely your > > > Le jeudi 08 novembre 2012 ? 23:56 +0100, Nikos Mavrogiannopoulos a > ?crit : >> Hello, >> I've just released gnutls 2.12.21. It includes few bug fixes in the >> old >> stable branch. >> >> Version 2.12.21 (released 2012-11-08) >> >> ** libgnutls: Backported patch to compile with libtasn1 3.0. >> Minimum libtasn1 dependency is now 2.14. >> >> ** libgnutls: Always tolerate key usage violation errors from the >> side >> of the peer, but also notify via an audit message. >> >> ** minitasn1: Upgraded to libtasn1 version 3.0. >> >> ** API and ABI modifications: >> No changes since last version. >> >> >> Getting the Software >> ==================== >> >> GnuTLS may be downloaded from one of the GNU mirror sites or >> directly >> From > be >> found at and a list of GnuTLS >> mirrors >> can be found at . >> >> Here are the BZIP2 compressed sources: >> >> ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2 >> http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2 >> >> Here are OpenPGP detached signatures signed using key 0x96865171: >> >> ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.sig >> http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.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 >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> https://lists.gnu.org/mailman/listinfo/gnutls-devel -- gpg --keyserver pgp.mit.edu --recv-key C2626742 http://about.me/fakessh From nmav at gnutls.org Sun Nov 11 04:18:15 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 11 Nov 2012 04:18:15 +0100 Subject: gnutls 2.12.21 In-Reply-To: <95fa2e8523fa962981344d9c5a799c72@roundcube.fakessh.eu> References: <509C389E.8000901@gnutls.org> <1352579627.8253.7.camel@localhost> <95fa2e8523fa962981344d9c5a799c72@roundcube.fakessh.eu> Message-ID: <509F18F7.9020908@gnutls.org> On 11/11/2012 12:36 AM, ml wrote: > hi guys > > it seems that this header just missing feature backported from superior > versions. > This error must be corrected easily Hello, You're right. It is caused from backporting the new minitasn1. You'll need to either install libtasn1 2.14 or later, or add the hash-pjw-bare.c/h into the source. regards, Nikos From ml at smtp.fakessh.eu Sun Nov 11 18:16:51 2012 From: ml at smtp.fakessh.eu (ml) Date: Sun, 11 Nov 2012 18:16:51 +0100 Subject: gnutls 2.12.21 In-Reply-To: <509F18F7.9020908@gnutls.org> References: <509C389E.8000901@gnutls.org> <1352579627.8253.7.camel@localhost> <95fa2e8523fa962981344d9c5a799c72@roundcube.fakessh.eu> <509F18F7.9020908@gnutls.org> Message-ID: Le 2012-11-11 04:18, Nikos Mavrogiannopoulos a ?crit?: > On 11/11/2012 12:36 AM, ml wrote: > >> hi guys >> >> it seems that this header just missing feature backported from >> superior >> versions. >> This error must be corrected easily > > > Hello, > You're right. It is caused from backporting the new minitasn1. > You'll > need to either install libtasn1 2.14 or later, or add the > hash-pjw-bare.c/h into the source. > > regards, > Nikos > > Scanned and tagged as non-SPAM with DSPAM 3.10.2 by Your ISP.com i am surprised compile into el5 gnutls 2.12.20 it is easy and compile 2.12.21 leads to a dependency error -- gpg --keyserver pgp.mit.edu --recv-key C2626742 http://about.me/fakessh From Alexander.Klauer at itwm.fraunhofer.de Wed Nov 14 12:51:52 2012 From: Alexander.Klauer at itwm.fraunhofer.de (Alexander Klauer) Date: Wed, 14 Nov 2012 12:51:52 +0100 Subject: Error in gnutls_certificate_set_x509_crl() documentation Message-ID: <50A385D8.6060605@itwm.fraunhofer.de> Hi, in http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gnutls_x509.c;h=b650ce7f546eb02d9dc31f1a6c236e0676c86e2c;hb=HEAD#l1849 it says "Returns: %GNUTLS_E_SUCCESS (0) on success, or a negative error code" when actually on success the return value of the call to gnutls_x509_trust_list_add_crls() in line 1878 is returned, i.e., the number of added items. I therefore suggest to change line 1849 to read "Returns: number of CRLs processed or a negative error code on error." Best regards, Alexander -- Dr. Alexander Klauer Competence Centre for High Performance Computing Fraunhofer-Institut f?r Techno- und Wirtschaftsmathematik ITWM Fraunhofer-Platz 1 67663 Kaiserslautern Tel.: +49 631 31600-4335 Fax : +49 631 31600-5335 Email: Alexander.Klauer at itwm.fraunhofer.de From nmav at gnutls.org Wed Nov 14 18:14:03 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 14 Nov 2012 18:14:03 +0100 Subject: Error in gnutls_certificate_set_x509_crl() documentation In-Reply-To: <50A385D8.6060605@itwm.fraunhofer.de> References: <50A385D8.6060605@itwm.fraunhofer.de> Message-ID: <50A3D15B.9000902@gnutls.org> On 11/14/2012 12:51 PM, Alexander Klauer wrote: > it says "Returns: %GNUTLS_E_SUCCESS (0) on success, or a negative error > code" when actually on success the return value of the call to > gnutls_x509_trust_list_add_crls() in line 1878 is returned, i.e., the > number of added items. I therefore suggest to change line 1849 to read > > "Returns: number of CRLs processed or a negative error code on error." Thanks. Updated. regards, Nikos From tim.kosse at filezilla-project.org Thu Nov 15 19:57:02 2012 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Thu, 15 Nov 2012 19:57:02 +0100 Subject: [PATCH 2/2] print-ciphersuites was a very useful too for debugging this. Now it is even built. In-Reply-To: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> References: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> Message-ID: <1353005822-4937-3-git-send-email-tim.kosse@filezilla-project.org> --- doc/examples/Makefile.am | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/examples/Makefile.am b/doc/examples/Makefile.am index a42b449..671ef31 100644 --- a/doc/examples/Makefile.am +++ b/doc/examples/Makefile.am @@ -43,6 +43,7 @@ CXX_LDADD = ../../lib/libgnutlsxx.la \ noinst_PROGRAMS = ex-client-resume ex-client-dtls noinst_PROGRAMS += ex-cert-select ex-client-x509 noinst_PROGRAMS += ex-serv-dtls +noinst_PROGRAMS += print-ciphersuites if ENABLE_CXX ex_cxx_SOURCES = ex-cxx.cpp @@ -79,5 +80,4 @@ endif libexamples_la_SOURCES = examples.h ex-alert.c ex-pkcs12.c \ ex-session-info.c ex-x509-info.c ex-verify.c \ - tcp.c udp.c ex-pkcs11-list.c verify.c ex-verify-ssh.c \ - print-ciphersuites.c + tcp.c udp.c ex-pkcs11-list.c verify.c ex-verify-ssh.c -- 1.7.2.5 From tim.kosse at filezilla-project.org Thu Nov 15 19:57:00 2012 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Thu, 15 Nov 2012 19:57:00 +0100 Subject: Bug in _add_priority adds duplicates and unwanted algorithms. Message-ID: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> Hi, when setting a priority string of SECURE256:+SECURE128, I noticed that on some platforms, 3DES was included in the list of ciphers, but is lacking on most platforms. Notably, MinGW cross-compiles with -O2 are affected. The problem is in _add_priority in gnutls_priority.c, where the continue statement in the inner loop should have instead returned to the beginning of the outer loop. The result is that ciphers are added multiple times and depending what$ These two patches fix the problem and also enable the print-ciphersuites example to be built by default. Regards, Tim Kosse From tim.kosse at filezilla-project.org Thu Nov 15 19:57:01 2012 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Thu, 15 Nov 2012 19:57:01 +0100 Subject: [PATCH 1/2] Don't read past the last list entry in _add_priority, doing so adds algorithms that shouldn't be added and can even lead to a segfault. In-Reply-To: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> References: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> Message-ID: <1353005822-4937-2-git-send-email-tim.kosse@filezilla-project.org> --- lib/gnutls_priority.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/lib/gnutls_priority.c b/lib/gnutls_priority.c index b6649ca..03ef83b 100644 --- a/lib/gnutls_priority.c +++ b/lib/gnutls_priority.c @@ -89,11 +89,11 @@ _set_priority (priority_st * st, const int *list) inline static void _add_priority (priority_st * st, const int *list) { - int num = 0, i, j, init; + int num, i, j, init; init = i = st->algorithms; - while (list[num] != 0) + for (num=0;list[num]!=0;++num) { if (i+1 > MAX_ALGOS) { @@ -104,14 +104,15 @@ _add_priority (priority_st * st, const int *list) { if (st->priority[j] == (unsigned)list[num]) { - num++; - continue; + break; } } - st->priority[i++] = list[num]; - st->algorithms++; - num++; + if (j == init) + { + st->priority[i++] = list[num]; + st->algorithms++; + } } return; -- 1.7.2.5 From nmav at gnutls.org Thu Nov 15 23:51:42 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 Nov 2012 23:51:42 +0100 Subject: Bug in _add_priority adds duplicates and unwanted algorithms. In-Reply-To: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> References: <1353005822-4937-1-git-send-email-tim.kosse@filezilla-project.org> Message-ID: <50A571FE.6020404@gnutls.org> On 11/15/2012 07:57 PM, Tim Kosse wrote: > Hi, > > when setting a priority string of SECURE256:+SECURE128, I noticed that on some platforms, 3DES was included in the list of ciphers, but is lacking on most platforms. Notably, MinGW cross-compiles with -O2 are affected. > The problem is in _add_priority in gnutls_priority.c, where the continue statement in the inner loop should have instead returned to the beginning of the outer loop. The result is that ciphers are added multiple times and depending what$ > These two patches fix the problem and also enable the print-ciphersuites example to be built by default. Thanks, both are applied. For the print-ciphersuites, you could do the same using gnutls-cli. (and the options -l and --priority XXX). regards, Nikos From donald.v.sullivan at nasa.gov Tue Nov 20 02:44:41 2012 From: donald.v.sullivan at nasa.gov (Don Sullivan) Date: Mon, 19 Nov 2012 17:44:41 -0800 Subject: DTLS Server In-Reply-To: <508C8D5F.8090302@gnutls.org> References: <50874912.1040108@nasa.gov> <508C8D5F.8090302@gnutls.org> Message-ID: <50AAE089.1020409@nasa.gov> On 10/27/12 6:41 PM, Nikos Mavrogiannopoulos wrote: > On 10/24/2012 03:49 AM, Don Sullivan wrote: > > >> Build of the DTLS server is disabled in both gnutls-3.0.25 and gnutls-3.1.3. >> Why ? > > > Hello, > I do not understand what do you mean by disabled. As it is currently > DTLS cannot be disabled. Could you be more specific? > >> When I try to build it, ex-client-dtls segfaults on the handshake (both versions) >> Suggestions ? > > > Could you try valgrind on this example? > > regards, > Nikos > My apologies. Building of doc/examples/ex-serv-dtls is NOT enabled by default. When I build it, and test it with ex-client-dtls, ex-client-dtls segfaults on the handshake. Output with valgrind attached. (gnutls-3.0.25, OS X, Darwin Kernel Version 10.8.0) Thank You ! Don -- --------------------------------------------- Don Sullivan NASA Ames Research Center Bldg N245, Rm 131a/MS 245-4 P.O. Box 1 Moffett Field, CA 94035-0001 Office: +1 650 604 0526 Mobile: +1 650 714 9742 Line2: +1 831 621 5023 email: donald.v.sullivan at nasa.gov OR: yes_its_don at mac.com --------------------------------------------- - Sic gorgiamus allos subjectatos nunc "Scientists seek to understand what is, engineers seek to create what never was." - Theodore Karman -------------- next part -------------- valgrind --leak-check=yes ./ex-client-dtls ==98398== Memcheck, a memory error detector ==98398== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==98398== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==98398== Command: ./ex-client-dtls ==98398== --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); ==98401== ==98401== HEAP SUMMARY: ==98401== in use at exit: 114,453 bytes in 503 blocks ==98401== total heap usage: 720 allocs, 217 frees, 142,728 bytes allocated ==98401== ==98401== 24 bytes in 1 blocks are definitely lost in loss record 132 of 300 ==98401== at 0x52C6: malloc (vg_replace_malloc.c:274) ==98401== by 0x10003D1C4: ??? (in /bin/sh) ==98401== by 0x10000FC31: ??? (in /bin/sh) ==98401== by 0x1000413A2: ??? (in /bin/sh) ==98401== by 0x1000254E4: ??? (in /bin/sh) ==98401== by 0x1000292D1: ??? (in /bin/sh) ==98401== by 0x10002A71D: ??? (in /bin/sh) ==98401== by 0x10002A7AA: ??? (in /bin/sh) ==98401== by 0x1000103E3: ??? (in /bin/sh) ==98401== by 0x100012A2A: ??? (in /bin/sh) ==98401== by 0x10001069E: ??? (in /bin/sh) ==98401== by 0x100012A2A: ??? (in /bin/sh) ==98401== ==98401== LEAK SUMMARY: ==98401== definitely lost: 24 bytes in 1 blocks ==98401== indirectly lost: 0 bytes in 0 blocks ==98401== possibly lost: 0 bytes in 0 blocks ==98401== still reachable: 114,341 bytes in 501 blocks ==98401== suppressed: 88 bytes in 1 blocks ==98401== Reachable blocks (those to which a pointer was found) are not shown. ==98401== To see them, rerun with: --leak-check=full --show-reachable=yes ==98401== ==98401== For counts of detected and suppressed errors, rerun with: -v ==98401== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==98400== ==98400== HEAP SUMMARY: ==98400== in use at exit: 113,743 bytes in 482 blocks ==98400== total heap usage: 687 allocs, 205 frees, 140,935 bytes allocated ==98400== ==98400== LEAK SUMMARY: ==98400== definitely lost: 0 bytes in 0 blocks ==98400== indirectly lost: 0 bytes in 0 blocks ==98400== possibly lost: 0 bytes in 0 blocks ==98400== still reachable: 113,655 bytes in 481 blocks ==98400== suppressed: 88 bytes in 1 blocks ==98400== Reachable blocks (those to which a pointer was found) are not shown. ==98400== To see them, rerun with: --leak-check=full --show-reachable=yes ==98400== ==98400== For counts of detected and suppressed errors, rerun with: -v ==98400== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==98402== ==98402== HEAP SUMMARY: ==98402== in use at exit: 113,075 bytes in 459 blocks ==98402== total heap usage: 945 allocs, 486 frees, 209,295 bytes allocated ==98402== ==98402== 34 bytes in 1 blocks are definitely lost in loss record 199 of 272 ==98402== at 0x52C6: malloc (vg_replace_malloc.c:274) ==98402== by 0x10003D1C4: ??? (in /bin/sh) ==98402== by 0x10000FC31: ??? (in /bin/sh) ==98402== by 0x100012A2A: ??? (in /bin/sh) ==98402== by 0x100013990: ??? (in /bin/sh) ==98402== by 0x100010723: ??? (in /bin/sh) ==98402== by 0x100012A2A: ??? (in /bin/sh) ==98402== by 0x100003336: ??? (in /bin/sh) ==98402== by 0x100002EF0: ??? (in /bin/sh) ==98402== by 0x100000D57: ??? (in /bin/sh) ==98402== by 0x1: ??? ==98402== by 0x7FFF5FBFFB2A: ??? ==98402== ==98402== LEAK SUMMARY: ==98402== definitely lost: 34 bytes in 1 blocks ==98402== indirectly lost: 0 bytes in 0 blocks ==98402== possibly lost: 0 bytes in 0 blocks ==98402== still reachable: 112,953 bytes in 457 blocks ==98402== suppressed: 88 bytes in 1 blocks ==98402== Reachable blocks (those to which a pointer was found) are not shown. ==98402== To see them, rerun with: --leak-check=full --show-reachable=yes ==98402== ==98402== For counts of detected and suppressed errors, rerun with: -v ==98402== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); ==98404== ==98404== HEAP SUMMARY: ==98404== in use at exit: 144,379 bytes in 1,700 blocks ==98404== total heap usage: 4,073 allocs, 2,373 frees, 318,516 bytes allocated ==98404== ==98404== 14 bytes in 1 blocks are definitely lost in loss record 105 of 575 ==98404== at 0x52C6: malloc (vg_replace_malloc.c:274) ==98404== by 0x10003D1C4: ??? (in /bin/sh) ==98404== by 0x1000114D7: ??? (in /bin/sh) ==98404== by 0x10000FFC6: ??? (in /bin/sh) ==98404== by 0x1000138C2: ??? (in /bin/sh) ==98404== by 0x100010723: ??? (in /bin/sh) ==98404== by 0x1000413A2: ??? (in /bin/sh) ==98404== by 0x1000254E4: ??? (in /bin/sh) ==98404== by 0x1000292D1: ??? (in /bin/sh) ==98404== by 0x10002A71D: ??? (in /bin/sh) ==98404== by 0x10002AAB0: ??? (in /bin/sh) ==98404== by 0x100025903: ??? (in /bin/sh) ==98404== ==98404== LEAK SUMMARY: ==98404== definitely lost: 14 bytes in 1 blocks ==98404== indirectly lost: 0 bytes in 0 blocks ==98404== possibly lost: 0 bytes in 0 blocks ==98404== still reachable: 144,277 bytes in 1,698 blocks ==98404== suppressed: 88 bytes in 1 blocks ==98404== Reachable blocks (those to which a pointer was found) are not shown. ==98404== To see them, rerun with: --leak-check=full --show-reachable=yes ==98404== ==98404== For counts of detected and suppressed errors, rerun with: -v ==98404== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==98403== ==98403== HEAP SUMMARY: ==98403== in use at exit: 143,307 bytes in 1,666 blocks ==98403== total heap usage: 4,061 allocs, 2,395 frees, 317,987 bytes allocated ==98403== ==98403== LEAK SUMMARY: ==98403== definitely lost: 0 bytes in 0 blocks ==98403== indirectly lost: 0 bytes in 0 blocks ==98403== possibly lost: 0 bytes in 0 blocks ==98403== still reachable: 143,219 bytes in 1,665 blocks ==98403== suppressed: 88 bytes in 1 blocks ==98403== Reachable blocks (those to which a pointer was found) are not shown. ==98403== To see them, rerun with: --leak-check=full --show-reachable=yes ==98403== ==98403== For counts of detected and suppressed errors, rerun with: -v ==98403== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); ==98406== ==98406== HEAP SUMMARY: ==98406== in use at exit: 143,221 bytes in 1,665 blocks ==98406== total heap usage: 4,131 allocs, 2,466 frees, 319,950 bytes allocated ==98406== ==98406== LEAK SUMMARY: ==98406== definitely lost: 0 bytes in 0 blocks ==98406== indirectly lost: 0 bytes in 0 blocks ==98406== possibly lost: 0 bytes in 0 blocks ==98406== still reachable: 143,133 bytes in 1,664 blocks ==98406== suppressed: 88 bytes in 1 blocks ==98406== Reachable blocks (those to which a pointer was found) are not shown. ==98406== To see them, rerun with: --leak-check=full --show-reachable=yes ==98406== ==98406== For counts of detected and suppressed errors, rerun with: -v ==98406== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); ==98409== ==98409== HEAP SUMMARY: ==98409== in use at exit: 142,718 bytes in 1,648 blocks ==98409== total heap usage: 4,257 allocs, 2,609 frees, 323,093 bytes allocated ==98409== ==98409== LEAK SUMMARY: ==98409== definitely lost: 0 bytes in 0 blocks ==98409== indirectly lost: 0 bytes in 0 blocks ==98409== possibly lost: 0 bytes in 0 blocks ==98409== still reachable: 142,630 bytes in 1,647 blocks ==98409== suppressed: 88 bytes in 1 blocks ==98409== Reachable blocks (those to which a pointer was found) are not shown. ==98409== To see them, rerun with: --leak-check=full --show-reachable=yes ==98409== ==98409== For counts of detected and suppressed errors, rerun with: -v ==98409== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); ==98411== ==98411== HEAP SUMMARY: ==98411== in use at exit: 144,631 bytes in 1,702 blocks ==98411== total heap usage: 4,506 allocs, 2,804 frees, 335,125 bytes allocated ==98411== ==98411== 27 bytes in 1 blocks are definitely lost in loss record 221 of 578 ==98411== at 0x52C6: malloc (vg_replace_malloc.c:274) ==98411== by 0x10003D1C4: ??? (in /bin/sh) ==98411== by 0x1000114D7: ??? (in /bin/sh) ==98411== by 0x10000FFC6: ??? (in /bin/sh) ==98411== by 0x1000138C2: ??? (in /bin/sh) ==98411== by 0x100010723: ??? (in /bin/sh) ==98411== by 0x1000413A2: ??? (in /bin/sh) ==98411== by 0x1000254E4: ??? (in /bin/sh) ==98411== by 0x1000292D1: ??? (in /bin/sh) ==98411== by 0x10002A71D: ??? (in /bin/sh) ==98411== by 0x10002AAB0: ??? (in /bin/sh) ==98411== by 0x100025903: ??? (in /bin/sh) ==98411== ==98411== LEAK SUMMARY: ==98411== definitely lost: 27 bytes in 1 blocks ==98411== indirectly lost: 0 bytes in 0 blocks ==98411== possibly lost: 0 bytes in 0 blocks ==98411== still reachable: 144,516 bytes in 1,700 blocks ==98411== suppressed: 88 bytes in 1 blocks ==98411== Reachable blocks (those to which a pointer was found) are not shown. ==98411== To see them, rerun with: --leak-check=full --show-reachable=yes ==98411== ==98411== For counts of detected and suppressed errors, rerun with: -v ==98411== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==98410== ==98410== HEAP SUMMARY: ==98410== in use at exit: 143,466 bytes in 1,668 blocks ==98410== total heap usage: 4,492 allocs, 2,824 frees, 333,775 bytes allocated ==98410== ==98410== LEAK SUMMARY: ==98410== definitely lost: 0 bytes in 0 blocks ==98410== indirectly lost: 0 bytes in 0 blocks ==98410== possibly lost: 0 bytes in 0 blocks ==98410== still reachable: 143,378 bytes in 1,667 blocks ==98410== suppressed: 88 bytes in 1 blocks ==98410== Reachable blocks (those to which a pointer was found) are not shown. ==98410== To see them, rerun with: --leak-check=full --show-reachable=yes ==98410== ==98410== For counts of detected and suppressed errors, rerun with: -v ==98410== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); --98398:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK ); zsh: segmentation fault valgrind --leak-check=yes ./ex-client-dtls -------------- next part -------------- A non-text attachment was scrubbed... Name: donald_v_sullivan.vcf Type: text/x-vcard Size: 325 bytes Desc: not available URL: From nmav at gnutls.org Sat Nov 24 18:53:28 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 24 Nov 2012 18:53:28 +0100 Subject: gnutls 3.1.5 Message-ID: <50B10998.8090402@gnutls.org> Hello, I've just released gnutls 3.1.5. This release adds support for UCS2 encoded DNs, improvements in smart card key generation and few bug-fixes. * Version 3.1.5 (released 2012-11-24) ** libgnutls: Added functions to parse the certificates policies extension. ** libgnutls: Handle BMPString (UCS-2) encoding in the Distinguished Name by translating it to UTF-8 (works on windows or systems with iconv). ** libgnutls: Added PKCS #11 key generation function that returns the public key on generation. ** libgnutls: Corrected bug in priority string parsing, that mostly affected combined levels. Patch by Tim Kosse. ** certtool: The --pubkey-info option can be combined with the --load-privkey or --load-request to print the corresponding public keys. ** certtool: It is able to set certificate policies via a template. ** certtool: Added --hex-numbers option which prints big numbers in an easier to parse format. ** p11tool: After key generation, outputs the public key (useful in tokens that do not store the public key). ** danetool: It is being built even without libgnutls-dane (the --check functionality is disabled though). ** API and ABI modifications: gnutls_pkcs11_privkey_generate2: Added gnutls_x509_crt_get_policy: Added gnutls_x509_crt_set_policy: Added gnutls_x509_policy_release: Added gnutls_pubkey_import_x509_crq: Added gnutls_pubkey_print: Added GNUTLS_CRT_PRINT_FULL_NUMBERS: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz.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 grawity at gmail.com Sat Nov 24 22:54:42 2012 From: grawity at gmail.com (Mantas =?utf-8?Q?Mikul=C4=97nas?=) Date: Sat, 24 Nov 2012 23:54:42 +0200 Subject: gnutls-cli should handle network errors more gracefully Message-ID: <20121124215431.GA444608@rain> I often use `gnutls-cli` to connect to dualstack hosts (having both IPv4 and IPv6 addresses). At times, when the client computer has an IPv6 default route, but the server is temporarily unreachable over IPv6, `gnutls-cli` exits immediately after failing to connect to the first address. Because of this, it is impossible to connect to such servers until I disable IPv6 entirely on my computer. The lack of -4/-6 options to force IPv4 (or IPv6) makes things only worse. For example: $ gnutls-cli virgule.cluenet.org -p 636 Processed 162 CA certificate(s). Resolving 'virgule.cluenet.org'... Connecting to '2a01:7e00::f03c:91ff:fe96:5efd:636'... Cannot connect to virgule.cluenet.org:636: No route to host $ The expected result here is that `gnutls-cli` would keep trying other addresses returned from getaddrinfo(), until at least one succeeds. -- Mantas Mikul?nas From nmav at gnutls.org Sun Nov 25 21:52:01 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 25 Nov 2012 21:52:01 +0100 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: <20121124215431.GA444608@rain> References: <20121124215431.GA444608@rain> Message-ID: <50B284F1.5020402@gnutls.org> On 11/24/2012 10:54 PM, Mantas Mikul?nas wrote: > I often use `gnutls-cli` to connect to dualstack hosts (having both IPv4 > and IPv6 addresses). > > At times, when the client computer has an IPv6 default route, but the > server is temporarily unreachable over IPv6, `gnutls-cli` exits > immediately after failing to connect to the first address. Because of > this, it is impossible to connect to such servers until I disable IPv6 > entirely on my computer. The lack of -4/-6 options to force IPv4 (or > IPv6) makes things only worse. ... > The expected result here is that `gnutls-cli` would keep trying other > addresses returned from getaddrinfo(), until at least one succeeds. I'm curious, how do other networking programs avoid this issue? Do they keep trying or do they provide an option to force IPv4 or 6? regards, Nikos From grawity at gmail.com Sun Nov 25 22:10:41 2012 From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=) Date: Sun, 25 Nov 2012 23:10:41 +0200 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: <50B284F1.5020402@gnutls.org> References: <20121124215431.GA444608@rain> <50B284F1.5020402@gnutls.org> Message-ID: On Sun, Nov 25, 2012 at 10:52 PM, Nikos Mavrogiannopoulos wrote: > On 11/24/2012 10:54 PM, Mantas Mikul?nas wrote: > >> I often use `gnutls-cli` to connect to dualstack hosts (having both IPv4 >> and IPv6 addresses). >> >> At times, when the client computer has an IPv6 default route, but the >> server is temporarily unreachable over IPv6, `gnutls-cli` exits >> immediately after failing to connect to the first address. Because of >> this, it is impossible to connect to such servers until I disable IPv6 >> entirely on my computer. The lack of -4/-6 options to force IPv4 (or >> IPv6) makes things only worse. > > ... >> The expected result here is that `gnutls-cli` would keep trying other >> addresses returned from getaddrinfo(), until at least one succeeds. > > > I'm curious, how do other networking programs avoid this issue? Do they > keep trying or do they provide an option to force IPv4 or 6? The ones I just tested ? `lftp`, `curl`, `nc-openbsd`, `mutt`, `ncat`, `wget`, inetutils `telnet` and `ssh` ? keep trying addresses until one succeeds, or until the program runs out of addresses to try. Almost all programs (all that I've listed, excluding `lftp` and `mutt`) also support options "-4" and "-6" to limit to just a particular address family. (The major web browsers implement an "Happy Eyeballs" algorithm and try both protocols in parallel, but it's probably not the right choice for such tools as `gnutls-cli`.) -- Mantas Mikul?nas From INVALID.NOREPLY at gnu.org Mon Nov 26 17:19:22 2012 From: INVALID.NOREPLY at gnu.org (Misio) Date: Mon, 26 Nov 2012 16:19:22 +0000 Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and Debian squeeze In-Reply-To: <20110830-114719.sv0.59352@savannah.gnu.org> References: <20110412-122623.sv82434.96453@savannah.gnu.org> <20110412-153438.sv707.56854@savannah.gnu.org> <20110412-125848.sv82434.87468@savannah.gnu.org> <20110412-163853.sv707.39141@savannah.gnu.org> <20110412-134516.sv82434.5097@savannah.gnu.org> <20110412-164715.sv707.89667@savannah.gnu.org> <20110412-164945.sv707.39713@savannah.gnu.org> <20110425-175208.sv73763.11918@savannah.gnu.org> <20110425-220116.sv707.16419@savannah.gnu.org> <20110830-085252.sv13613.55462@savannah.gnu.org> <20110830-101818.sv707.37555@savannah.gnu.org> <20110830-111849.sv13613.84838@savannah.gnu.org> <20110830-114719.sv0.59352@savannah.gnu.org> Message-ID: <20121126-161922.sv89855.16091@savannah.gnu.org> Follow-up Comment #13, sr #107660 (project gnutls): gnutls_record_check_pending() will return non-zero when there are data that have not been read by the application. It might be less than a complete record (i.e. 1 byte). If it is non-zero any access to gnutls_record_recv() will not involve the network so it will never return GNUTLS_E_AGAIN. http://www.misiasty.pl http://www.e-zawady.pl http://www.e-zwd.pl _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Mon Nov 26 19:44:06 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Nov 2012 19:44:06 +0100 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: References: <20121124215431.GA444608@rain> <50B284F1.5020402@gnutls.org> Message-ID: On Sun, Nov 25, 2012 at 10:10 PM, Mantas Mikul?nas wrote: >>> The expected result here is that `gnutls-cli` would keep trying other >>> addresses returned from getaddrinfo(), until at least one succeeds. >> >> >> I'm curious, how do other networking programs avoid this issue? Do they >> keep trying or do they provide an option to force IPv4 or 6? > > The ones I just tested ? `lftp`, `curl`, `nc-openbsd`, `mutt`, `ncat`, > `wget`, inetutils `telnet` and `ssh` ? keep trying addresses until one > succeeds, or until the program runs out of addresses to try. Hello, Could you try this patch and verify that it works in your use case? http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=5da62fb671474b1ffaad5dd3062895ca109c47bf regards, Nikos From grawity at gmail.com Mon Nov 26 20:54:12 2012 From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=) Date: Mon, 26 Nov 2012 21:54:12 +0200 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: References: <20121124215431.GA444608@rain> <50B284F1.5020402@gnutls.org> Message-ID: On Mon, Nov 26, 2012 at 8:44 PM, Nikos Mavrogiannopoulos wrote: > On Sun, Nov 25, 2012 at 10:10 PM, Mantas Mikul?nas wrote: > >>>> The expected result here is that `gnutls-cli` would keep trying other >>>> addresses returned from getaddrinfo(), until at least one succeeds. >>> >>> >>> I'm curious, how do other networking programs avoid this issue? Do they >>> keep trying or do they provide an option to force IPv4 or 6? >> >> The ones I just tested ? `lftp`, `curl`, `nc-openbsd`, `mutt`, `ncat`, >> `wget`, inetutils `telnet` and `ssh` ? keep trying addresses until one >> succeeds, or until the program runs out of addresses to try. > > Hello, > Could you try this patch and verify that it works in your use case? > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=5da62fb671474b1ffaad5dd3062895ca109c47bf > > regards, > Nikos The patch doesn't change anything; `gnutls-cli` still exit(1)'s after the first error and does not attempt other addresses. (Also, `gnutls-cli` now only shows the hostname, while previously it used to show the actual IP address it tried.) -- Mantas Mikul?nas From nmav at gnutls.org Mon Nov 26 22:26:44 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Nov 2012 22:26:44 +0100 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: References: <20121124215431.GA444608@rain> <50B284F1.5020402@gnutls.org> Message-ID: <50B3DE94.30209@gnutls.org> On 11/26/2012 08:54 PM, Mantas Mikul?nas wrote: > On Mon, Nov 26, 2012 at 8:44 PM, Nikos Mavrogiannopoulos > wrote: >> On Sun, Nov 25, 2012 at 10:10 PM, Mantas Mikul?nas wrote: >> >>>>> The expected result here is that `gnutls-cli` would keep trying other >>>>> addresses returned from getaddrinfo(), until at least one succeeds. >>>> >>>> >>>> I'm curious, how do other networking programs avoid this issue? Do they >>>> keep trying or do they provide an option to force IPv4 or 6? >>> >>> The ones I just tested ? `lftp`, `curl`, `nc-openbsd`, `mutt`, `ncat`, >>> `wget`, inetutils `telnet` and `ssh` ? keep trying addresses until one >>> succeeds, or until the program runs out of addresses to try. >> >> Hello, >> Could you try this patch and verify that it works in your use case? >> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=5da62fb671474b1ffaad5dd3062895ca109c47bf >> >> regards, >> Nikos > > The patch doesn't change anything; `gnutls-cli` still exit(1)'s after > the first error and does not attempt other addresses. (Also, > `gnutls-cli` now only shows the hostname, while previously it used to > show the actual IP address it tried.) Well, since you have the test environment could you provide a patch for that to work as expected? Is replacing the exit() with continue, enough? regards, Nikos From grawity at gmail.com Mon Nov 26 23:18:23 2012 From: grawity at gmail.com (=?UTF-8?B?TWFudGFzIE1pa3VsxJduYXM=?=) Date: Tue, 27 Nov 2012 00:18:23 +0200 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: <50B3DE94.30209@gnutls.org> References: <20121124215431.GA444608@rain> <50B284F1.5020402@gnutls.org> <50B3DE94.30209@gnutls.org> Message-ID: <50B3EAAF.3020601@gmail.com> On 2012-11-26 23:26, Nikos Mavrogiannopoulos wrote: > On 11/26/2012 08:54 PM, Mantas Mikul?nas wrote: > >> On Mon, Nov 26, 2012 at 8:44 PM, Nikos Mavrogiannopoulos >> wrote: >>> On Sun, Nov 25, 2012 at 10:10 PM, Mantas Mikul?nas wrote: >>> >>>>>> The expected result here is that `gnutls-cli` would keep trying other >>>>>> addresses returned from getaddrinfo(), until at least one succeeds. >>>>> >>>>> >>>>> I'm curious, how do other networking programs avoid this issue? Do they >>>>> keep trying or do they provide an option to force IPv4 or 6? >>>> >>>> The ones I just tested ? `lftp`, `curl`, `nc-openbsd`, `mutt`, `ncat`, >>>> `wget`, inetutils `telnet` and `ssh` ? keep trying addresses until one >>>> succeeds, or until the program runs out of addresses to try. >>> >>> Hello, >>> Could you try this patch and verify that it works in your use case? >>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=5da62fb671474b1ffaad5dd3062895ca109c47bf >>> >>> regards, >>> Nikos >> >> The patch doesn't change anything; `gnutls-cli` still exit(1)'s after >> the first error and does not attempt other addresses. (Also, >> `gnutls-cli` now only shows the hostname, while previously it used to >> show the actual IP address it tried.) > > > Well, since you have the test environment could you provide a patch for > that to work as expected? Is replacing the exit() with continue, enough? Just tried it ? yes, changing "exit(1)" to "continue" seems to be enough. In both "Connecting..." and "Cannot connect..." printfs, replacing 'hostname' with 'buffer' also fixes the issue with IP addresses not being displayed. diff --git a/src/socket.c b/src/socket.c index f901482..9a2ce10 100644 --- a/src/socket.c +++ b/src/socket.c @@ -176,14 +176,14 @@ socket_open (socket_st * hd, const char *hostname, const char *service, int udp) } - printf ("Connecting to '%s:%s'...\n", hostname, portname); + printf ("Connecting to [%s]:%s...\n", buffer, portname); err = connect (sd, ptr->ai_addr, ptr->ai_addrlen); if (err < 0) { - fprintf (stderr, "Cannot connect to %s:%s: %s\n", hostname, + fprintf (stderr, "Cannot connect to [%s]:%s: %s\n", buffer, portname, strerror (errno)); - exit (1); + continue; } break; } -- Mantas Mikul?nas From nmav at gnutls.org Mon Nov 26 23:34:15 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Nov 2012 23:34:15 +0100 Subject: gnutls-cli should handle network errors more gracefully In-Reply-To: <50B3EAAF.3020601@gmail.com> References: <20121124215431.GA444608@rain> <50B284F1.5020402@gnutls.org> <50B3DE94.30209@gnutls.org> <50B3EAAF.3020601@gmail.com> Message-ID: <50B3EE67.2020204@gnutls.org> On 11/26/2012 11:18 PM, Mantas Mikul?nas wrote: > diff --git a/src/socket.c b/src/socket.c > index f901482..9a2ce10 100644 > --- a/src/socket.c > +++ b/src/socket.c > @@ -176,14 +176,14 @@ socket_open (socket_st * hd, const char *hostname, > const char *service, int udp) > } > > > - printf ("Connecting to '%s:%s'...\n", hostname, portname); > + printf ("Connecting to [%s]:%s...\n", buffer, portname); > > err = connect (sd, ptr->ai_addr, ptr->ai_addrlen); > if (err < 0) > { > - fprintf (stderr, "Cannot connect to %s:%s: %s\n", hostname, > + fprintf (stderr, "Cannot connect to [%s]:%s: %s\n", buffer, > portname, strerror (errno)); > - exit (1); > + continue; Thanks. Applied. From INVALID.NOREPLY at gnu.org Tue Nov 27 10:40:09 2012 From: INVALID.NOREPLY at gnu.org (Alexander Vershilov) Date: Tue, 27 Nov 2012 09:40:09 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon Message-ID: <20121127-094008.sv89857.7151@savannah.gnu.org> URL: Summary: gnutls_x509_crt_init(1) returns null in neon Project: GnuTLS Submitted by: qnikst Submitted on: Tue 27 Nov 2012 09:40:08 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: When neon is used with resent gnutls version it segfaults when it is used by subversion to checkout some https repositories. [1,2] error was in code sample: gnutls_x509_crt dest; if (gnutls_x509_crt_init(&dest) != 0) { return NULL; } I tried to find out when this behavior is introduced and find out that it's a commit: 50f0068ae327abce4f648cfb12132b0254f9afa8 [3] And problem still persist in current gnutls versions. How to reproduce: 1). install gnutls 2). install neon with gnutls support 3). install subversion 4). try to checkout svn repo (e.g. https://crossfire.svn.sourceforge.net/svnroot/crossfire) Libraries and programs: 1). gnutls >= 2.99.4 2). neon-0.29.6 3). subversion 1.7.7 ----- [1] https://bugs.gentoo.org/show_bug.cgi?id=440936 [2] https://bugs.gentoo.org/show_bug.cgi?id=443854 [3] http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=50f0068ae327abce4f648cfb12132b0254f9afa8 I can provide additional information if needed. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 27 11:05:37 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Nov 2012 10:05:37 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121127-094008.sv89857.7151@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> Message-ID: <20121127-120537.sv707.20025@savannah.gnu.org> Follow-up Comment #1, sr #108189 (project gnutls): Hello the commit that you mention has only changes in text files so I don't know how it relates to the issue you notice. In any case if you fix the check to: if (gnutls_x509_crt_init(&dest) < 0) { (instead of != 0), does it fix the issue for you? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 27 13:51:19 2012 From: INVALID.NOREPLY at gnu.org (Alexander Vershilov) Date: Tue, 27 Nov 2012 12:51:19 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121127-120537.sv707.20025@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> Message-ID: <20121127-125118.sv89857.81956@savannah.gnu.org> Follow-up Comment #2, sr #108189 (project gnutls): I also have no idea how that commit can be related to that error, but testing it and previous commits has a stable result (an error after and and success before). I can make an image of a system where I have tested, with a sets of a scripts. Also I can send a bisect history. No, changing to '< 0' instead 'of != 0' haven't solved my issue (at least with latest gnutls), I'll check on the previous versions). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 27 18:11:24 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Nov 2012 17:11:24 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121127-125118.sv89857.81956@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> <20121127-125118.sv89857.81956@savannah.gnu.org> Message-ID: <20121127-191124.sv707.49479@savannah.gnu.org> Update of sr #108189 (project gnutls): Status: None => Need Info Assigned to: None => nmav _______________________________________________________ Follow-up Comment #3: Could you then try with valgrind? This function is very inprobable to cause an error because it is one of the most tested in our included tests. The issue could be somewhere unrelated due to a memory corruption or so. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 27 21:34:33 2012 From: INVALID.NOREPLY at gnu.org (Alexander Vershilov) Date: Tue, 27 Nov 2012 20:34:33 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121127-191124.sv707.49479@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> <20121127-125118.sv89857.81956@savannah.gnu.org> <20121127-191124.sv707.49479@savannah.gnu.org> Message-ID: <20121127-203432.sv89857.67400@savannah.gnu.org> Follow-up Comment #4, sr #108189 (project gnutls): I think that problem is that neon incorrectly uses gnutls, the only reason I've filled a bug is that neon upsteam seems dead, and this error was introduced with some gnutls update. So any suggestions how to fix this error are welcome. I've attached a valgrind log: ==13911== at 0x8C90344: gnutls_x509_crt_get_subject (x509.c:2362) this is done after calling: x509_crt_copy line 486 [1] issuer = x509_crt_copy(issuer); // <- here returns null cert = populate_cert(ne_calloc(sizeof *cert), issuer); [1] http://svn.webdav.org/repos/projects/neon/trunk/src/ne_gnutls.c (file #26984) _______________________________________________________ Additional Item Attachment: File name: subversion-neon-gnutls.log Size:5 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 28 00:17:50 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Nov 2012 23:17:50 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121127-203432.sv89857.67400@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> <20121127-125118.sv89857.81956@savannah.gnu.org> <20121127-191124.sv707.49479@savannah.gnu.org> <20121127-203432.sv89857.67400@savannah.gnu.org> Message-ID: <20121128-011750.sv707.61689@savannah.gnu.org> Follow-up Comment #5, sr #108189 (project gnutls): Which version of gnutls did you use for this trace? It would be best to try with the latest version released (3.1.5). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 28 00:30:47 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Nov 2012 23:30:47 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121128-011750.sv707.61689@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> <20121127-125118.sv89857.81956@savannah.gnu.org> <20121127-191124.sv707.49479@savannah.gnu.org> <20121127-203432.sv89857.67400@savannah.gnu.org> <20121128-011750.sv707.61689@savannah.gnu.org> Message-ID: <20121128-013047.sv707.62519@savannah.gnu.org> Follow-up Comment #6, sr #108189 (project gnutls): One issue I noticed is on line 489 that size is not set to zero. The new attached file should fix the first warning, but I don't know whether the others are related (the gnutls line numbers in the file do not correspond to anything i can check). (file #26985) _______________________________________________________ Additional Item Attachment: File name: ne_gnutls-2.c Size:39 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 28 11:33:13 2012 From: INVALID.NOREPLY at gnu.org (Alexander Vershilov) Date: Wed, 28 Nov 2012 10:33:13 +0000 Subject: [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121128-013047.sv707.62519@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> <20121127-125118.sv89857.81956@savannah.gnu.org> <20121127-191124.sv707.49479@savannah.gnu.org> <20121127-203432.sv89857.67400@savannah.gnu.org> <20121128-011750.sv707.61689@savannah.gnu.org> <20121128-013047.sv707.62519@savannah.gnu.org> Message-ID: <20121128-103313.sv89857.55816@savannah.gnu.org> Follow-up Comment #7, sr #108189 (project gnutls): Thanks, that file (with minor fixes) fixed situation. I'll apply it in gentoo, and try to mail upstream. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/