From nmav at gnutls.org  Sun May  3 20:03:47 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 May 2015 20:03:47 +0200
Subject: [gnutls-help] gnutls 3.3.15
Message-ID: <1430676227.17186.1.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.3.15. This is a bug-fix release on
the current stable branch.

* Version 3.3.15 (released 2015-05-03)

** libgnutls: gnutls_certificate_get_ours: will return the certificate even
if a callback was used to send it.

** libgnutls: Fix for MD5 downgrade in TLS 1.2 signatures. Reported by
Karthikeyan Bhargavan [GNUTLS-SA-2015-2].

** libgnutls: Check for invalid length in the X.509 version field. Without the check
certificates with invalid length would be detected as having an arbitrary
version. Reported by Hanno B?ck.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.15.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.15.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.15.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.15.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 <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
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  Sun May  3 20:05:29 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 May 2015 20:05:29 +0200
Subject: [gnutls-help] gnutls 3.4.1
Message-ID: <1430676329.17186.2.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.4.1. This is a bug-fix release on
the next stable branch.

* Version 3.4.1 (released 2015-05-03)

** libgnutls: gnutls_certificate_get_ours: will return the certificate even
if a callback was used to send it.

** libgnutls: Check for invalid length in the X.509 version field. Without
the check certificates with invalid length would be detected as having an
arbitrary version. Reported by Hanno B?ck.

** libgnutls: Handle DNS name constraints with a leading dot. Patch by
Fotis Loukos.

** libgnutls: Updated system-keys support for windows to compile in more
versions of mingw. Patch by Tim Kosse.

** libgnutls: Fix for MD5 downgrade in TLS 1.2 signatures. Reported by
Karthikeyan Bhargavan [GNUTLS-SA-2015-2].

** libgnutls: Reverted: The gnutls_handshake() process will enforce a timeout
by default. That caused issues with non-blocking programs.

** certtool: It can generate SHA256 key IDs.

** gnutls-cli: fixed crash in --benchmark-ciphers. Reported by James Cloos.

** configure: re-enabled the --enable-local-libopts flag

** API and ABI modifications:
gnutls_x509_crt_get_pk_ecc_raw: Added


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.1.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 <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos




From nmav at gnutls.org  Mon May  4 10:38:04 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 4 May 2015 10:38:04 +0200
Subject: [gnutls-help] FIPS mode: Removing TLS 1.0 + reference
In-Reply-To: <20150429204305.09a50ed9@mevla>
References: <2a3b5010ff4387a44618f37938b006f9@teksavvy.com>
 <CAJU7zaLRHubnb9v+ASAwox=naJAm4Hw8v-Qz93cEXhYHBu=THA@mail.gmail.com>
 <20150429204305.09a50ed9@mevla>
Message-ID: <CAJU7zaKc4r1spA=N0strxXWzV0CyQ-L0g9p=oiRqkgea2nfjyw@mail.gmail.com>

On Thu, Apr 30, 2015 at 2:43 AM, jonetsu at teksavvy.com
<jonetsu at teksavvy.com> wrote:
>   Here is the reference to NIST Special Publication SP 800-52 revision
> 1:
> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
>
>   Abstract:
>   "This Special Publication provides guidance to the selection
>    and configuration of TLS protocol implementations while making
>    effective use of Federal Information Processing Stand
>    ards (FIPS) and NIST- recommended cryptographic algorithms,
>    and requires that TLS 1.1 configured with FIPS- based cipher
>    suites as the minimum appropriate secure transport protocol
>    and recommends that agencies develop migration plans to TLS
>    1.2 by January 1, 2015. This Special Publication also
>    identifies TLS extensions for which mandatory support must be
>    provided and other recommended extensions."

I'm still not convinced. The version of FIPS140-2 I have does not
reference SP800-52. So the same argument applies. It should be FIPS
documents referencing the TLS 1.0 removal requirement, not vice-versa.

regards,
Nikos


From jonetsu at teksavvy.com  Tue May  5 18:56:07 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 05 May 2015 12:56:07 -0400
Subject: [gnutls-help] TLS v1.1 in GnuTLS
Message-ID: <828e30cb14702f9c889ea2b4ebebf072@teksavvy.com>

GnuTLS supports TLS v1.1 although none TLS1.1 is shown in the cipher list.? But it is shown as protocol.? Does this mean that there were no ciphers added at the TLS 1.1 stage (only protocol changes) and, the ciphers supported by 1.1 are already listed using a previous version ?

Regards.





From jonetsu at teksavvy.com  Tue May  5 18:57:56 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 05 May 2015 12:57:56 -0400
Subject: [gnutls-help] FIPS mode: compiling without SSL v3.0 and TLS v1.0
	support ?
Message-ID: <1d63f45fec3b8ace25cfc20db8d6b0bb@teksavvy.com>

Hello,

Is it possible, in both FIPS compilation (as a configure option ?) and behaviour, to also remove (SSL v3.0 protocol ? and) TLS 1.0 from GnuTLS without affecting any other part of the software ?

Regards.





From mattroisang at gmail.com  Wed May  6 01:57:45 2015
From: mattroisang at gmail.com (Mat Troi)
Date: Tue, 5 May 2015 16:57:45 -0700
Subject: [gnutls-help] How to turn off SSL 3.0 in older GnuTLS?
Message-ID: <CAA0a8nUprZ=VtsRmmNc-x7ABouCY1cfgX7B_gJTX1AxBuQddNQ@mail.gmail.com>

Hi,

I see that SSL 3.0 is not included in GnuTLS 3.4 by default.  So my
question is in GnuTLS 2.8.6, is there anyway to take it out in the "default
priority list"?

Thanks,
Mat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150505/e68ab283/attachment.html>

From blaybel.2010 at hotmail.com  Wed May  6 21:50:11 2015
From: blaybel.2010 at hotmail.com (Ali Blaybel)
Date: Wed, 6 May 2015 22:50:11 +0300
Subject: [gnutls-help] gnutls_ext_register
Message-ID: <DUB125-W44A7DB847F5FC078FBDD2A9FD00@phx.gbl>

Hello 

really i need your help, thank you anyway


if can you give me an example of how can i use this extension gnutls_ext_register and if i register this extension will become build in in gnutls (that mean i can see this extension in all example).

or i need to create a client and server example like  "Simple client example with X.509 certificate support" and "Echo server with X.509 authentication"
and only used in these examples and how can i add this extension in these examples 

please see the extension overflow below 

and really thank you 

Extension Overview
In
 order to negotiate the use of IEEE or ETSI certificate-based 
authentication, clients MAY include an extension of type 
"accepted_and_supported_certificate_type" in the extended client hello. 
The "extension_data" field of this extension SHALL contain a list of 
supported certificate types advertised by the client, where:

enum { ieee(0), ets(1), x509(2), (255) } SupportedCertType;
enum { ieee(0), etsi(1), x509(2), (255) } AcceptedCertType;

struct {
             SupportedClientCertType supported_certificate_types<1..2^8-1>;
             AcceptedClientCertType accepted_certificate_types<1..2^8-1>;
} SupportedAndAcceptedCertType;

DistinguishedName certificate_authorities<0..2^16-1>;

- Supported_certificate_types: A list of certificate types types that the client may support.
- Accepted_certificate_types: A list of certificate types that the client may accept.
- Certificate_authorities: A list of the distinguished names as described in [RFC5246].


If
 the TLS server is willing to accept using the extension described here,
 it selects one of the supported certificate types and one of the 
accepted certificate types and includes a certificate_authorities list 
in the extension described here. The CertificateRequest payload
is 
omitted from the response. The same extension type and structure will be
 used for the server?s response to the extension described here. Note 
that a server MAY send no certificate types if it either
does not 
have an appropriate certificate to send in response to the extension 
defined here or it wishes to authenticate the client using other 
authentication methods. The client MAY at its discretion
either continue the handshake, or respond with a fatal handshake_failure alert.


The
 end-entity certificate?s public key (and associated restrictions) has 
to be compatible with the certificate types listed in extension 
described here.

At the end of the hello phase, the client 
generates the pre_master_secret, encrypts it under the server?s public 
key, and sends the result to the server.

For servers aware of the
 extension described here but not wishing to use it, it will gracefully 
revert to an ordinary TLS handshake or stop the negotiation.

Clients
 return a response along with their certificates by sending the 
"Certificate" message and immediately after the "ClientKeyExchange" 
message. The premaster secret is generated
according to the cipher algorithm selected by the server in the ServerHello.cipher_suite. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150506/5bb07eea/attachment.html>

From blaybel.2010 at hotmail.com  Thu May  7 10:36:55 2015
From: blaybel.2010 at hotmail.com (Ali Blaybel)
Date: Thu, 7 May 2015 11:36:55 +0300
Subject: [gnutls-help] gnutls_ext_register
Message-ID: <DUB125-W8593DD786CF3F7BF995139FDF0@phx.gbl>

Hello really i need your help, thank you anywayIf can you give me an example of how can i use this extension gnutls_ext_register and if i register this extension will become build in in gnutls (that mean i can see this extension in all example).or i need to create a client and server example like  "Simple client example with X.509 certificate support" and "Echo server with X.509 authentication"and only used in these examples and how can i add this extension in these examples please see the extension overflow below and really thank you Extension OverviewIn order to negotiate the use of IEEE or ETSI certificate-based authentication, clients MAY include an extension of type "accepted_and_supported_certificate_type" in the extended client hello. The "extension_data" field of this extension SHALL contain a list of supported certificate types advertised by the client, where:enum { ieee(0), ets(1), x509(2), (255) } SupportedCertType;enum { ieee(0), etsi(1), x509(2), (255) } AcceptedCertType;struct {             SupportedClientCertType supported_certificate_types<1..2^8-1>;             AcceptedClientCertType accepted_certificate_types<1..2^8-1>;} SupportedAndAcceptedCertType;DistinguishedName certificate_authorities<0..2^16-1>;- Supported_certificate_types: A list of certificate types types that the client may support.- Accepted_certificate_types: A list of certificate types that the client may accept.- Certificate_authorities: A list of the distinguished names as described in [RFC5246].If the TLS server is willing to accept using the extension described here, it selects one of the supported certificate types and one of the accepted certificate types and includes a certificate_authorities list in the extension described here. The CertificateRequest payloadis omitted from the response. The same extension type and structure will be used for the server?s response to the extension described here. Note that a server MAY send no certificate types if it eitherdoes not have an appropriate certificate to send in response to the extension defined here or it wishes to authenticate the client using other authentication methods. The client MAY at its discretioneither continue the handshake, or respond with a fatal handshake_failure alert.The end-entity certificate?s public key (and associated restrictions) has to be compatible with the certificate types listed in extension described here.At the end of the hello phase, the client generates the pre_master_secret, encrypts it under the server?s public key, and sends the result to the server.For servers aware of the extension described here but not wishing to use it, it will gracefully revert to an ordinary TLS handshake or stop the negotiation.Clients return a response along with their certificates by sending the "Certificate" message and immediately after the "ClientKeyExchange" message. The premaster secret is generatedaccording to the cipher algorithm selected by the server in the ServerHello.cipher_suite. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150507/f422bc41/attachment-0001.html>

From dkg at fifthhorseman.net  Fri May  8 01:47:35 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 07 May 2015 19:47:35 -0400
Subject: [gnutls-help] gnutls_ext_register
In-Reply-To: <DUB125-W44A7DB847F5FC078FBDD2A9FD00@phx.gbl>
References: <DUB125-W44A7DB847F5FC078FBDD2A9FD00@phx.gbl>
Message-ID: <87twvokl0o.fsf@alice.fifthhorseman.net>

Hi Ali--

On Wed 2015-05-06 15:50:11 -0400, Ali Blaybel wrote:

> if can you give me an example of how can i use this extension
> gnutls_ext_register and if i register this extension will become build
> in in gnutls (that mean i can see this extension in all example).

I think you're asking about implementing a TLS extension in GnuTLS, but
i'm not convinced that the extension you're proposing is going to be
easy to implement with just gnutls_ext_register.

> or i need to create a client and server example like "Simple client
> example with X.509 certificate support" and "Echo server with X.509
> authentication" and only used in these examples and how can i add this
> extension in these examples
>
> please see the extension overflow below 
>
> and really thank you 
>
> Extension Overview

> In order to negotiate the use of IEEE or ETSI certificate-based
> authentication, clients MAY include an extension of type
> "accepted_and_supported_certificate_type" in the extended client
> hello.  The "extension_data" field of this extension SHALL contain a
> list of supported certificate types advertised by the client, where:
>
> enum { ieee(0), ets(1), x509(2), (255) } SupportedCertType;
> enum { ieee(0), etsi(1), x509(2), (255) } AcceptedCertType;
>
> struct {
>              SupportedClientCertType supported_certificate_types<1..2^8-1>;
>              AcceptedClientCertType accepted_certificate_types<1..2^8-1>;
> } SupportedAndAcceptedCertType;
>
> DistinguishedName certificate_authorities<0..2^16-1>;
>
> - Supported_certificate_types: A list of certificate types types that the client may support.
> - Accepted_certificate_types: A list of certificate types that the client may accept.
> - Certificate_authorities: A list of the distinguished names as described in [RFC5246].

The above rough cut looks similar to either RFC 6091 or RFC 7250.
GnuTLS already implements RFC 6091, but does not currently implement
7250, afaict.  Is this a different extension you're proposing?

Would it make more sense to just work with one of these frameworks and
try to extend the certificate type registry?


> At the end of the hello phase, the client generates the
> pre_master_secret, encrypts it under the server?s public key, and
> sends the result to the server.
>
> For servers aware of the extension described here but not wishing to
> use it, it will gracefully revert to an ordinary TLS handshake or stop
> the negotiation.
>
> Clients return a response along with their certificates by sending the
> "Certificate" message and immediately after the "ClientKeyExchange"
> message. The premaster secret is generated according to the cipher
> algorithm selected by the server in the ServerHello.cipher_suite.

The paragraphs above seem to assume that the key exchange mechanism is
coupled with the certificate selection mechanism.  What you've described
is the RSA key exchange mechanism, which is likely to go away in future
versions of TLS.

For example, TLS peers can also use (EC)DHE key exchange, coupled with a
certificate for the server, where the secret key from the certificate
signs the server's DH share in order to authenticate itself.  If this is
part of your draft TLS extension, i suggest you drop this part -- if you
want to add new forms of certificate, try to touch the rest of the
handshake as little as possible.

Regards,

      --dkg


From mail at lechevalier.se  Fri May  8 12:03:56 2015
From: mail at lechevalier.se (A L)
Date: Fri, 8 May 2015 12:03:56 +0200
Subject: [gnutls-help] AICCU with GnuTLS 3.4
Message-ID: <554C8A0C.6020806@lechevalier.se>

I am having troubles with compiling the IPv6 tunnel agent, AICCU with 
GnutLS-3.4 (works fine with 3.3).

Is 3.4 incompatible with 3.3, or are there other reasons why it failes? 
Sample compile output:

=================================

    x86_64-pc-linux-gnu-gcc -O2 -pipe -fomit-frame-pointer -march=native
    -mtune=native -msse3 -D_GNU_SOURCE -D AICCU_CONSOLE -D AICCU_GNUTLS
    -D_LINUX -D HAS_IFHEAD -D AICCU_TYPE="\"linux\""   -c -o
    ../common/aiccu_linux.o ../common/aiccu_linux.c
    In file included from ../common/aiccu.h:17:0,
                      from ../common/aiccu_linux.c:13:
    ../common/common.h:384:2: warning: ?gnutls_session? is deprecated
    [-Wdeprecated-declarations]
       gnutls_session  session; /* The GnuTLS sesision */
       ^
    In file included from ../common/aiccu_linux.c:13:0:
    ../common/aiccu.h:114:2: warning: ?gnutls_certificate_credentials?
    is deprecated [-Wdeprecated-declarations]
       gnutls_certificate_credentials tls_cred; /* GNUTLS credentials */
       ^
    ../common/aiccu_linux.c: In function ?aiccu_os_install?:
    ../common/aiccu_linux.c:21:3: warning: ignoring return value of
    ?system?, declared with attribute warn_unused_result [-Wunused-result]
        (void)system("modprobe -q ipv6 2>/dev/null >/dev/null");
        ^
    ../common/aiccu_linux.c:36:2: warning: ignoring return value of
    ?system?, declared with attribute warn_unused_result [-Wunused-result]
       (void)system("modprobe -q sit 2>/dev/null >/dev/null");
       ^
    ../common/aiccu_linux.c:37:2: warning: ignoring return value of
    ?system?, declared with attribute warn_unused_result [-Wunused-result]
       (void)system("modprobe -q tun 2>/dev/null >/dev/null");
       ^
    x86_64-pc-linux-gnu-gcc -O2 -pipe -fomit-frame-pointer -march=native
    -mtune=native -msse3 -D_GNU_SOURCE -D AICCU_CONSOLE -D AICCU_GNUTLS
    -D_LINUX -D HAS_IFHEAD -D AICCU_TYPE="\"linux\""
    -Wl,-O1,--sort-common,--enable-new-dtags -o aiccu main.o
    ../common/tun.o ../common/aiccu.o ../common/hash_md5.o
    ../common/hash_sha1.o ../common/common.o ../common/heartbeat.o
    ../common/tic.o ../common/ayiya.o ../common/aiccu_test.o
    ../common/resolver.o ../common/aiccu_linux.o -lgnutls -lpthread -lresolv
    ../common/common.o: In function `sock_alloc':
    common.c:(.text+0x5c7): undefined reference to
    `gnutls_certificate_type_set_priority'
    collect2: error: ld returned 1 exit status
    Makefile:148: recipe for target 'aiccu' failed
    make: *** [aiccu] Error 1
    make: Leaving directory
    '/mnt/storageTemp/portage/portage/net-misc/aiccu-2007.01.15-r4/work/aiccu/unix-console'

=================================

The source is rather old. 2007 is last update according to : 
https://www.sixxs.net/tools/aiccu/

~A


From marcossp at kth.se  Fri May  8 14:32:48 2015
From: marcossp at kth.se (=?utf-8?B?TWFyY29zIFNpbcOzIFBpY8Oz?=)
Date: Fri, 8 May 2015 12:32:48 +0000
Subject: [gnutls-help] GnuTLS-TPM handshake
Message-ID: <DB9B3FB2-7079-475A-B22C-3A9F60BDD1EA@kth.se>

Hi all,

I?m trying to set up a TLS session between client and server, both provided with a TPM and using mutual authentication. I am checking if it is feasible to do it using X.509 certificate authentication. I found out that GnuTLS needs to get access to the actual private key (either importing it from its URL or directly) by executing gnutls_certificate_set_x509_key_file(), before performing the handshake. However, it would be interesting that the private key would never leave the TPM chip.

Is there any way to do it?

Thanks!

Marcos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150508/1d047d14/attachment.html>

From nmav at gnutls.org  Fri May  8 21:33:07 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 May 2015 21:33:07 +0200
Subject: [gnutls-help] GnuTLS-TPM handshake
In-Reply-To: <DB9B3FB2-7079-475A-B22C-3A9F60BDD1EA@kth.se>
References: <DB9B3FB2-7079-475A-B22C-3A9F60BDD1EA@kth.se>
Message-ID: <1431113587.8093.0.camel@gnutls.org>

On Fri, 2015-05-08 at 12:32 +0000, Marcos Sim? Pic? wrote:
> Hi all,  

> I?m trying to set up a TLS session between client and server, both
> provided with a TPM and using mutual authentication. I am checking if
> it is feasible to do it using X.509 certificate authentication. I
> found out that GnuTLS needs to get access to the actual private key
> (either importing it from its URL or directly) by executing
> gnutls_certificate_set_x509_key_file(), before performing the
> handshake. However, it would be interesting that the private key would
> never leave the TPM chip. 

Hello,
 What you say isn't correct. gnutls_certificate_set_x509_key_file() when
given a tpmkey URL will utilize but not extract any key. Why do you
think it would extract it?

regards,
Nikos




From nmav at gnutls.org  Fri May  8 21:37:08 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 May 2015 21:37:08 +0200
Subject: [gnutls-help] AICCU with GnuTLS 3.4
In-Reply-To: <554C8A0C.6020806@lechevalier.se>
References: <554C8A0C.6020806@lechevalier.se>
Message-ID: <1431113828.8093.2.camel@gnutls.org>

On Fri, 2015-05-08 at 12:03 +0200, A L wrote:
> I am having troubles with compiling the IPv6 tunnel agent, AICCU with 
> GnutLS-3.4 (works fine with 3.3).
> 
> Is 3.4 incompatible with 3.3, or are there other reasons why it failes? 
> Sample compile output:
> =================================

>     `gnutls_certificate_type_set_priority'

This function no longer exists in 3.4. If you don't use this with
openpgp keys, just remove the call to
gnutls_certificate_type_set_priority.

regards,
Nikos




From mail at lechevalier.se  Sat May  9 15:53:25 2015
From: mail at lechevalier.se (A L)
Date: Sat, 9 May 2015 15:53:25 +0200
Subject: [gnutls-help] AICCU with GnuTLS 3.4
In-Reply-To: <1431113828.8093.2.camel@gnutls.org>
References: <554C8A0C.6020806@lechevalier.se>
 <1431113828.8093.2.camel@gnutls.org>
Message-ID: <554E1155.8020103@lechevalier.se>



On 2015-05-08 21:37, Nikos Mavrogiannopoulos wrote:
> On Fri, 2015-05-08 at 12:03 +0200, A L wrote:
>> I am having troubles with compiling the IPv6 tunnel agent, AICCU with
>> GnutLS-3.4 (works fine with 3.3).
>>
>> Is 3.4 incompatible with 3.3, or are there other reasons why it failes?
>> Sample compile output:
>> =================================
>>
>>      `gnutls_certificate_type_set_priority'
> This function no longer exists in 3.4. If you don't use this with
> openpgp keys, just remove the call to
> gnutls_certificate_type_set_priority.
>
> regards,
> Nikos

That worked well. Thanks.

I also filed a bug report with Gentoo (since that's what I am using) and 
with Sixxs. The code is rather old, so perhaps it is unmaintained.

~A



From marcossp at kth.se  Mon May 11 09:43:25 2015
From: marcossp at kth.se (=?utf-8?B?TWFyY29zIFNpbcOzIFBpY8Oz?=)
Date: Mon, 11 May 2015 07:43:25 +0000
Subject: [gnutls-help] GnuTLS-TPM handshake
In-Reply-To: <1431113587.8093.0.camel@gnutls.org>
References: <DB9B3FB2-7079-475A-B22C-3A9F60BDD1EA@kth.se>
 <1431113587.8093.0.camel@gnutls.org>
Message-ID: <76941DA3-79E6-412A-9DB0-54891317B3EE@kth.se>

Hello,

I think the function would extract the key since the description of the function, literally says:

This function can also accept URLs at  keyfile and  certfile . In
       that case it will import the private key and certificate indicated by
       the URLs. Note that the supported URLs are the ones indicated by
       gnutls_url_is_supported().

And according to the TPM literature, import the key means to extract it from the TPM and send it somewhere else. Please, correct me if I?m mistaken.

Thanks for your answer Nikos.

Best,

Marcos

On 08 May 2015, at 21:33, Nikos Mavrogiannopoulos <nmav at gnutls.org<mailto:nmav at gnutls.org>> wrote:

On Fri, 2015-05-08 at 12:32 +0000, Marcos Sim? Pic? wrote:
Hi all,

I?m trying to set up a TLS session between client and server, both
provided with a TPM and using mutual authentication. I am checking if
it is feasible to do it using X.509 certificate authentication. I
found out that GnuTLS needs to get access to the actual private key
(either importing it from its URL or directly) by executing
gnutls_certificate_set_x509_key_file(), before performing the
handshake. However, it would be interesting that the private key would
never leave the TPM chip.

Hello,
What you say isn't correct. gnutls_certificate_set_x509_key_file() when
given a tpmkey URL will utilize but not extract any key. Why do you
think it would extract it?

regards,
Nikos



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150511/3c37c47b/attachment.html>

From nmav at gnutls.org  Mon May 11 18:42:38 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 11 May 2015 18:42:38 +0200
Subject: [gnutls-help] GnuTLS-TPM handshake
In-Reply-To: <76941DA3-79E6-412A-9DB0-54891317B3EE@kth.se>
References: <DB9B3FB2-7079-475A-B22C-3A9F60BDD1EA@kth.se>
 <1431113587.8093.0.camel@gnutls.org>
 <76941DA3-79E6-412A-9DB0-54891317B3EE@kth.se>
Message-ID: <1431362558.1710.4.camel@gnutls.org>

On Mon, 2015-05-11 at 07:43 +0000, Marcos Sim? Pic? wrote:
> Hello,  

> I think the function would extract the key since the description of
> the function, literally says: 
> This function can also accept URLs at  keyfile and  certfile . In
>        that case it will import the private key and certificate indicated by
>        the URLs. Note that the supported URLs are the ones indicated by
>        gnutls_url_is_supported().
> And according to the TPM literature, import the key means to extract it from the TPM and send it somewhere else. Please, correct me if I?m mistaken. 

The documentation is inaccurate in that case. I've corrected the wording
to "it will use the ...". In any case, you cannot extract a tpmkey
anyway.

regards,
Nikos





From blaybel.2010 at hotmail.com  Mon May 11 22:58:27 2015
From: blaybel.2010 at hotmail.com (Ali Blaybel)
Date: Mon, 11 May 2015 23:58:27 +0300
Subject: [gnutls-help] gnutls_ext_register
Message-ID: <DUB125-W35F8519B59C32498353B949FDB0@phx.gbl>

Thank MR.Daniel for your help.

Mr Daniel.

Currently, I don't need to add a new type of certificate  I can be relied on "X509", all I
 need is to add new extension  
"accepted_and_supported_certificate_type"  contain the certificates type
 supported by the client (just a enumeration ieee(0), ets(1), x509(2), 
(255))
and
 in the server side when receipt this extension (if it contain number 2 
(that mean x509))  it continue its work normally, if not it return " 
Failed Handshake".

Therefore.
-  I use the tools "gnutls-serv" as a server. 
- and the client example "Simple client example with X.509 certificate support" as a client 
- and the wireshark to see if the extension is correctly added. 

I tried to add the extension in the client example before the method gnutls_handshake(session)  
gnutls_ext_register ("SupportedAndAcceptedCertType", 777, GNUTLS_EXT_TLS, NULL,NULL, NULL, NULL, NULL);"  but I don't see the extension in wireshark 

Please, if can you help me where can i added the function gnutls_ext_register to see it in wireshark. 

Thank you 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150511/b64590cb/attachment.html>

From j.ballantine at gmail.com  Fri May 15 20:44:10 2015
From: j.ballantine at gmail.com (Jim Ballantine)
Date: Fri, 15 May 2015 14:44:10 -0400
Subject: [gnutls-help] gnutls and nettles-3.1
Message-ID: <CADcmFMW=32J7D7RCPJ6KzXYnYRTmHicrdYipmVyht1i2H9-muw@mail.gmail.com>

I'm am trying to build  gnutls-3.4.1 with nettle-3.1 on a solaris 10
system, and it is failing in the configure with:

checking for NETTLE... Unknown keyword 'URL' in
'/usr/local/add-on/nettle/lib/pkgconfig/nettle.pc'
no
configure: error:
  ***
  *** Libnettle 3.1 was not found.

and the nettle.pc file contains:

less /usr/local/add-on/nettle/lib/pkgconfig/nettle.pc
prefix=/usr/local/add-on/nettle-3.1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: Nettle
Description: Nettle low-level cryptographic library (symmetric algorithms)
URL: http://www.lysator.liu.se/~nisse/nettle
Version: 3.1
Libs: -L${libdir} -lnettle
Cflags: -I${includedir}

Any ideas on what is going wrong here?

Thanks
Jim Ballantine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150515/cbbca55b/attachment.html>

From shrutipatil326 at gmail.com  Thu May 21 09:03:29 2015
From: shrutipatil326 at gmail.com (Shruti Patil)
Date: Thu, 21 May 2015 12:33:29 +0530
Subject: [gnutls-help] Unable to do handshake in gnutls using x509
	certificate
Message-ID: <CANq1oj9PN1pdA7y9J7huoivOTkw2L8TFpX3R3+a4iF=8Fwtabg@mail.gmail.com>

Hello All,

This is shruti here, I am facing some issue in hand shaking betwen server
and client... I have  generated cert.pem key.pem crl.pem using certtool.. I
am trying with the following sample code :

http://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support

http://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication


when I execute the above server and client code it displays the following
message:

"Handshake failed
GnuTLS error: Error in the certificate.
The certificate is NOT trusted. The certificate issuer is unknown. The name
in the certificate does not match the expected "

I'm not getting what's the issue and where it's going wrong...please help
me..

Thank you in advance

Best Regards,
Shruti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150521/d5468415/attachment-0001.html>

From dkg at fifthhorseman.net  Fri May 22 22:56:19 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 22 May 2015 16:56:19 -0400
Subject: [gnutls-help] Unable to do handshake in gnutls using
	x509	certificate
In-Reply-To: <CANq1oj9PN1pdA7y9J7huoivOTkw2L8TFpX3R3+a4iF=8Fwtabg@mail.gmail.com>
References: <CANq1oj9PN1pdA7y9J7huoivOTkw2L8TFpX3R3+a4iF=8Fwtabg@mail.gmail.com>
Message-ID: <87oalcnxfw.fsf@alice.fifthhorseman.net>

On Thu 2015-05-21 03:03:29 -0400, Shruti Patil wrote:
> This is shruti here, I am facing some issue in hand shaking betwen server
> and client... I have  generated cert.pem key.pem crl.pem using
> certtool..

You haven't mentioned how you generated these files specifically.

> I am trying with the following sample code :
>
> http://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support
>
> http://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication
>
>
> when I execute the above server and client code it displays the following
> message:
>
> "Handshake failed
> GnuTLS error: Error in the certificate.
> The certificate is NOT trusted. The certificate issuer is unknown. The name
> in the certificate does not match the expected "

It sounds to me like the client does not know about the server's
certificate, and so it is rejecting the connection.

If you make sure that the server's certificate was issued by a CA that
the client knows about and trusts, that should be sufficient.

what CAs does the client know about?

    --dkg


From shrutipatil326 at gmail.com  Mon May 25 09:07:59 2015
From: shrutipatil326 at gmail.com (Shruti Patil)
Date: Mon, 25 May 2015 12:37:59 +0530
Subject: [gnutls-help] tls handshaking get failed
Message-ID: <CANq1oj9KVV0oRjbuig_0UjiU7BJS066-RO0c3q2+mfx77Q=Ykg@mail.gmail.com>

  This is shruti here, I am facing some issue in hand shaking betwen server
and client... I have generated cert.pem key.pem crl.pem using certtool.. I
am trying with the following sample code :

http://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support

http://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication

when I execute the above server and client code it displays the following
message:

"Handshake failed GnuTLS error: Error in the certificate. The certificate
is NOT trusted. The certificate issuer is unknown. The name in the
certificate does not match the expected "

I'm not getting what's the issue and where it's going wrong...please help
me..

Thank you in advance

Best Regards, Shruti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150525/931030c0/attachment.html>

From jonetsu at teksavvy.com  Wed May 27 22:35:52 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Wed, 27 May 2015 16:35:52 -0400
Subject: [gnutls-help] Is  AES GCM only in TLS1.2 ?
Message-ID: <52fd302b207513f26082aec82847ae27@teksavvy.com>

Hello,


The output of the cipher listing, in FIPS mode, filtered for TLS1.2, gives:


% gnutls-cli -l --priority NORMAL | grep 1.2


?TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
?TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
?TLS_ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256
?TLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384
?[...]


Only GCM variation of AES. ?Why is GCM the only available AES variation in TLS1.2 ?


Thanks.


Regards.





From dkg at fifthhorseman.net  Thu May 28 00:37:32 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 May 2015 18:37:32 -0400
Subject: [gnutls-help] Is  AES GCM only in TLS1.2 ?
In-Reply-To: <52fd302b207513f26082aec82847ae27@teksavvy.com>
References: <52fd302b207513f26082aec82847ae27@teksavvy.com>
Message-ID: <87egm1hck3.fsf@alice.fifthhorseman.net>

On Wed 2015-05-27 16:35:52 -0400, jonetsu wrote:

> The output of the cipher listing, in FIPS mode, filtered for TLS1.2, gives:
>
> % gnutls-cli -l --priority NORMAL | grep 1.2
>
> ?TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
> ?TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
> ?TLS_ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256
> ?TLS_ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384
> ?[...]

It appears you've trimmed the right-hand side of this transcript, where
TLS1.2 actually appears.

> Only GCM variation of AES. ?Why is GCM the only available AES variation in TLS1.2 ?

I think you're misunderstanding the output of gnutls-cli -l, which looks
like this:

TLS_ECDHE_ECDSA_AES_128_GCM_SHA256                	0xc0, 0x2b	TLS1.2

I think this line says that the TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
ciphersuite is only available for TLS 1.2 and higher (because that is
when it when it was introduced).

You'll note that no ciphersuites are listed with a "TLS1.1" label,
despite the fact that GnuTLS will connect to a peer that only handles
TLS 1.1.

Similarly, there are ciphersuites marked with SSL3.0, despite the fact
that GnuTLS does not support SSLv3 any longer (SSLv3 is old and
known-broken[0]).  These ciphersuites are listed that way because that's
the protocol version in which they were introduced.

hth,

    --dkg

[0] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-03
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20150527/a86031a4/attachment.sig>

From jonetsu at teksavvy.com  Thu May 28 02:28:58 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Wed, 27 May 2015 20:28:58 -0400
Subject: [gnutls-help] Is  AES GCM only in TLS1.2 ?
In-Reply-To: <87egm1hck3.fsf@alice.fifthhorseman.net>
References: <52fd302b207513f26082aec82847ae27@teksavvy.com>
 <87egm1hck3.fsf@alice.fifthhorseman.net>
Message-ID: <20150527202858.0c5ab0fb@mevla>

On Wed, 27 May 2015 18:37:32 -0400
Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

Thanks for your reply.

> > % gnutls-cli -l --priority NORMAL | grep 1.2

> It appears you've trimmed the right-hand side of this transcript,
> where TLS1.2 actually appears.

Yes.  The '1.2' has to be there though, in order for the grep expression
to evaluate correctly and produce output.

> > Only GCM variation of AES. ?Why is GCM the only available AES
> > variation in TLS1.2 ?

> I think this line says that the TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
> ciphersuite is only available for TLS 1.2 and higher (because that is
> when it when it was introduced).

Yes.  The concern though is not only about FIPS, but also about the
recent NDcPP 1.0 in which nothing but TLS 1.2 is accepted.  So I will
have to modify somewhat the code so that it can recognize when to limit
itself to TLS 1.2 and when to offer other versions.  Depending on the
operating environment.

That is the background.  The question actually is about AES and which
variations are available when only TLS 1.2 if available.  

Seemingly that would be only the GCM variation, would it ?
 
Regards.


From dkg at fifthhorseman.net  Thu May 28 04:21:02 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 27 May 2015 22:21:02 -0400
Subject: [gnutls-help] Is  AES GCM only in TLS1.2 ?
In-Reply-To: <20150527202858.0c5ab0fb@mevla>
References: <52fd302b207513f26082aec82847ae27@teksavvy.com>
 <87egm1hck3.fsf@alice.fifthhorseman.net> <20150527202858.0c5ab0fb@mevla>
Message-ID: <87iobdfnn5.fsf@alice.fifthhorseman.net>

On Wed 2015-05-27 20:28:58 -0400, jonetsu at teksavvy.com wrote:
> That is the background.  The question actually is about AES and which
> variations are available when only TLS 1.2 if available.  
>
> Seemingly that would be only the GCM variation, would it ?

No, that's not correct, all of the ciphers will be available in TLS 1.2,
because they are all defined for TLS 1.2.  TLS 1.2 inherits all the
ciphers that come from previous versions, including those ciphers
introduced in SSLv3, TLSv1.0, and TLSv1.1.

GCM is understood to be a more secure symmetric cipher than many of the
others options, so i would recommend using it if you have the
opportunity, though.

             --dkg


From maxi1192 at gmx.de  Thu May 28 13:09:06 2015
From: maxi1192 at gmx.de (=?UTF-8?Q?=22maximilian_h=C3=B6tger=22?=)
Date: Thu, 28 May 2015 13:09:06 +0200
Subject: [gnutls-help] using gnutls_x509_crt_import
Message-ID: <trinity-c3b62e4c-f754-49a9-9e37-64328ebfacb2-1432811346323@3capp-gmx-bs13>

An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150528/880e1533/attachment-0001.html>

From shadiakiki1986 at gmail.com  Sun May 31 00:39:24 2015
From: shadiakiki1986 at gmail.com (shadi akiki)
Date: Sun, 31 May 2015 01:39:24 +0300
Subject: [gnutls-help] compiling gnutls 3.1.28 not being used by php in
	travis-ci workers
Message-ID: <CACk+RNs_PapibLSteSJqbfG+9+Mbb_+QdpLvytjC815HXNHWbQ@mail.gmail.com>

Hi

I'm compiling gnutls 3.1.28 from source on travis-ci to use it from php.

Running "*pkg-config --modversion gnutls*" before the compilation shows
2.12.14 whereas afterwards shows 3.1.28.
However, running "*var_dump(curl_version())*" as well as "*phpinfo*()"
before and after the compilation show 'ssl_version'="*GnuTLS/2.12.14*"
only.

>From digging around, I understood that php is using
/usr/lib/x86_64-linux-gnu/libgnutls.so.26 . My compiled gnutls is ending up
in /usr/local/lib/libgnutls.so.28
I thought that perhaps replacing libgnutls.so.26 with a symlink to
libgnutls.so.28
could be a dirty fix, but it doesn't work. Php complains:
*symbol gnutls_certificate_get_x509_cas, version GNUTLS_1_4 not defined in
file libgnutls.so.26 with link time reference*

What do I still need to do to get php to use my compiled gnutls?
Should I recompile php from source as well?

Here are some files with details

   - Log file
   <https://s3.amazonaws.com/archive.travis-ci.org/jobs/64740717/log.txt>
   - .travis.yml file
   <https://github.com/shadiakiki1986/gnutls-3.1-travisci/blob/master/.travis.yml>
   - Compilation bash script
   <https://github.com/shadiakiki1986/gnutls-3.1-travisci/blob/master/updateGnutls.sh>


-- 
Best, Shadi AKIKI
www.akikieng.com/shadi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150531/a0470bfc/attachment.html>