From orbisvicis at gmail.com  Sat Aug  7 21:05:56 2010
From: orbisvicis at gmail.com (Yclept Nemo)
Date: Sat, 7 Aug 2010 15:05:56 -0400
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>
Message-ID: <AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>

More information, not very helpful I'm afraid:
http://pastebin.com/qJMm2XyY
basically
gdb
set logging on
attach ...
directory ...
b gnutls_record.c:59
c
...
c 10
...
while 1==1
> step
> end



From orbisvicis at gmail.com  Sat Aug  7 20:18:24 2010
From: orbisvicis at gmail.com (Yclept Nemo)
Date: Sat, 7 Aug 2010 14:18:24 -0400
Subject: [2.10.1] segfault at gnutls_record.c:58
Message-ID: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>

Hi,

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb744f710 (LWP 23279)]
gnutls_protocol_get_version (session=0x8ba9b00) at gnutls_record.c:58
58      gnutls_record.c: No such file or directory.
        in gnutls_record.c
(gdb) bt
#0  gnutls_protocol_get_version (session=0x8ba9b00) at gnutls_record.c:58
#1  0x08074b0b in ap_run_fixups ()
#2  0x08089f90 in ap_process_request ()
#3  0x080872ab in ?? ()
#4  0x08080b29 in ap_run_process_connection ()
#5  0x0808e3c9 in ?? ()
#6  0x0808e707 in ?? ()
#7  0x0808e7c4 in ?? ()
#8  0x0808f24b in ap_mpm_run ()
#9  0x08066dd5 in main ()
(gdb)

Does this directly concern GnuTLS? I'm using it in tandem with
mod_gnutls 0.5.7/apache. I wish I could get more in-depth backtrace,
but every time I step into gnutls_protocol_get_version gdb reports a
broken pipe. From the apache errorfile:
[Sat Aug 07 13:57:00 2010] [error] [client 74.105.42.220] GnuTLS:
Handshake Failed (-8) 'A record packet with illegal version was
received.'
[Sat Aug 07 13:57:00 2010] [error] [client 74.105.42.220] GnuTLS:
Handshake Failed (-8) 'A record packet with illegal version was
received.'
[Sat Aug 07 13:57:00 2010] [error] [client 74.105.42.220] GnuTLS:
Handshake Failed (-8) 'A record packet with illegal version was
received.'
[Sat Aug 07 13:57:01 2010] [error] [client 74.105.42.220] GnuTLS:
Handshake Failed (-8) 'A record packet with illegal version was
received.'
[Sat Aug 07 13:57:01 2010] [error] [client 74.105.42.220] GnuTLS:
Handshake Failed (-8) 'A record packet with illegal version was
received.'
[Sat Aug 07 13:57:01 2010] [notice] child pid 22594 exit signal
Segmentation fault (11)
I'm assuming this is pertinent, since older versions had the same
error minus the segfault.
If I set a breakpoint at gnutls_record.c:59, it enters into
gnutls_protocol_get_version a few times before crashing.

Sincerely,



From nmav at gnutls.org  Sun Aug  8 23:28:37 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 9 Aug 2010 00:28:37 +0300
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>
	<AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>
Message-ID: <AANLkTinc6DGpJEzH_iNnJnjD_A-i41ZgaWvYx8MA9GPV@mail.gmail.com>

A bug report is only helpful if it can be reproduced. A segfault can
be anything related to memory corruption that could occur by any
unrelated code. Please specify a way to reproduce it.

On Sat, Aug 7, 2010 at 10:05 PM, Yclept Nemo <orbisvicis at gmail.com> wrote:
> More information, not very helpful I'm afraid:
> http://pastebin.com/qJMm2XyY
> basically
> gdb
> set logging on
> attach ...
> directory ...
> b gnutls_record.c:59
> c
> ...
> c 10
> ...
> while 1==1
>> step
>> end
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls
>



From orbisvicis at gmail.com  Fri Aug 13 08:23:52 2010
From: orbisvicis at gmail.com (Yclept Nemo)
Date: Fri, 13 Aug 2010 02:23:52 -0400
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>
	<AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>
	<AANLkTinc6DGpJEzH_iNnJnjD_A-i41ZgaWvYx8MA9GPV@mail.gmail.com>
	<AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>
Message-ID: <AANLkTi==v4CL3A--7bd3Xo4UZnf7WCTALAV65UVYfPB=@mail.gmail.com>

meh, how gmail handles mailing list replies is troubling. To the
correct recipients:

On Fri, Aug 13, 2010 at 2:21 AM, Yclept Nemo <orbisvicis at gmail.com> wrote:
> It is with:
> mod_gnutls-0.5.7 or mod_gnutls-0.5.5
> GnuTLSPriorities
> NONE:+CAMELLIA-256-CBC:+AES-256-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE:+VERS-TLS1.1:+VERS-SSL3.0
> gnutls-2.10.1
> httpd: Server version: Apache/2.2.8 (Ubuntu)
> firefox 3.6.8
>
> There is no segfault if "GnuTLSPriorities SECURE256" or if I downgrade
> to an older version of gnutls (can't quite remember which release, but
> probably 2.9.3or9). I can't really comment on usage of
> mod_gnutls-0.5.7 because I experience another bug that also affects
> versions >0.5.5 http://issues.outoforder.cc/view.php?id=106
>



From nmav at gnutls.org  Tue Aug 17 19:09:52 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 17 Aug 2010 19:09:52 +0200
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>	<AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>	<AANLkTinc6DGpJEzH_iNnJnjD_A-i41ZgaWvYx8MA9GPV@mail.gmail.com>
	<AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>
Message-ID: <4C6AC260.10902@gnutls.org>

On 08/13/2010 08:21 AM, Yclept Nemo wrote:
> It is with:
> mod_gnutls-0.5.7 or mod_gnutls-0.5.5
> GnuTLSPriorities
> NONE:+CAMELLIA-256-CBC:+AES-256-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE:+VERS-TLS1.1:+VERS-SSL3.0
> gnutls-2.10.1
> httpd: Server version: Apache/2.2.8 (Ubuntu)
> firefox 3.6.8
> 
> There is no segfault if "GnuTLSPriorities SECURE256" or if I downgrade
> to an older version of gnutls (can't quite remember which release, but
> probably 2.9.3or9). I can't really comment on usage of
> mod_gnutls-0.5.7 because I experience another bug that also affects
> versions >0.5.5 http://issues.outoforder.cc/view.php?id=106

Hello,
 Does the patch attached in http://issues.outoforder.cc/view.php?id=106
solve the issue you see?

regards,
Nikos




From orbisvicis at gmail.com  Wed Aug 18 21:50:02 2010
From: orbisvicis at gmail.com (Yclept Nemo)
Date: Wed, 18 Aug 2010 15:50:02 -0400
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTikctF65g8TqLaFGeaQfz2FgcSqiQYj4Vjob=RSB@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>
	<AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>
	<AANLkTinc6DGpJEzH_iNnJnjD_A-i41ZgaWvYx8MA9GPV@mail.gmail.com>
	<AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>
	<4C6AC260.10902@gnutls.org>
	<AANLkTikctF65g8TqLaFGeaQfz2FgcSqiQYj4Vjob=RSB@mail.gmail.com>
Message-ID: <AANLkTimsd2ECT6roN9kfbQ12wUdQvOw2OWie6tBm8ubm@mail.gmail.com>

Hi,

Since the patch attached (patch3.txt) only applies cleanly against the
latest mod_gnutls, I'm now using 0.5.7 and haven't tested 0.5.5. From
a limited 1/2-hour of testing I can report the patch solves the bug
reported at http://issues.outoforder.cc/view.php?id=106, so everything
looks good on that front. One note: I'm using apache2-mpm-prefork
2.2.8-1ubuntu0.11 so the additional issues tinlans is reporting might
very well be thread-safety problems.

While the patch also resolves the segfaults I reported when using a
customized GnuTLSPriorities list, it seems to break any communication
with the browser:
GnuTLS: Handshake Failed (-8) 'A record packet with illegal version
was received.'
Invalid method in request \x10
"\x10" 501 521 "-" "-"
(GnuTLSPriorities
NONE:+CAMELLIA-256-CBC:+AES-256-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE:+VERS-TLS1.1:+VERS-SSL3.0)

Also, I'm not sure if this is related to changes from the patch, but
firefox (same version as above) is telling me:
": server does not support RFC 5746, see CVE-2009-3555"

thanks,

One question, does 0.5.8 incorporate patch3.txt?



From orbisvicis at gmail.com  Wed Aug 18 23:52:56 2010
From: orbisvicis at gmail.com (Yclept Nemo)
Date: Wed, 18 Aug 2010 17:52:56 -0400
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTimsd2ECT6roN9kfbQ12wUdQvOw2OWie6tBm8ubm@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>
	<AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>
	<AANLkTinc6DGpJEzH_iNnJnjD_A-i41ZgaWvYx8MA9GPV@mail.gmail.com>
	<AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>
	<4C6AC260.10902@gnutls.org>
	<AANLkTikctF65g8TqLaFGeaQfz2FgcSqiQYj4Vjob=RSB@mail.gmail.com>
	<AANLkTimsd2ECT6roN9kfbQ12wUdQvOw2OWie6tBm8ubm@mail.gmail.com>
Message-ID: <AANLkTimc+quakvHufYyB8MKfzS_=xPN3-oZO6OQPu69v@mail.gmail.com>

Eh, nevermind the last bit, I learned to add ":%SAFE_RENEGOTIATION".



From nmav at gnutls.org  Thu Aug 19 03:22:12 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Aug 2010 03:22:12 +0200
Subject: [2.10.1] segfault at gnutls_record.c:58
In-Reply-To: <AANLkTimsd2ECT6roN9kfbQ12wUdQvOw2OWie6tBm8ubm@mail.gmail.com>
References: <AANLkTimiG-T6n4KMp0ksvEk8vi-RGvr7NzfnURNkcJ-u@mail.gmail.com>	<AANLkTikdbUW2B+PjParaKG7Rg356d1cUvDBL7d=0GOdP@mail.gmail.com>	<AANLkTinc6DGpJEzH_iNnJnjD_A-i41ZgaWvYx8MA9GPV@mail.gmail.com>	<AANLkTi=srZHYUKf0FE7UoHPN2YeO6LEsyg_UqDvVuTSC@mail.gmail.com>	<4C6AC260.10902@gnutls.org>	<AANLkTikctF65g8TqLaFGeaQfz2FgcSqiQYj4Vjob=RSB@mail.gmail.com>
	<AANLkTimsd2ECT6roN9kfbQ12wUdQvOw2OWie6tBm8ubm@mail.gmail.com>
Message-ID: <4C6C8744.9090208@gnutls.org>

On 08/18/2010 09:50 PM, Yclept Nemo wrote:
> Hi,

> While the patch also resolves the segfaults I reported when using a
> customized GnuTLSPriorities list, it seems to break any communication
> with the browser:
> GnuTLS: Handshake Failed (-8) 'A record packet with illegal version
> was received.'
> Invalid method in request \x10
> "\x10" 501 521 "-" "-"
> (GnuTLSPriorities
> NONE:+CAMELLIA-256-CBC:+AES-256-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE:+VERS-TLS1.1:+VERS-SSL3.0)

Note that your priority string is wrong. TLS1.0 is missing from this
string, thus any fallback from TLS1.1 will be to TLS1.0 that is not
supported and thus the handshake will fail. I'd suggest to use one of
the preconfigured priority strings.

> Also, I'm not sure if this is related to changes from the patch, but
> firefox (same version as above) is telling me:
> ": server does not support RFC 5746, see CVE-2009-3555"

By default it is configured to be in %PARTIAL_RENEGOTIATION mode for
maximum compatibility. This will allow non-RFC5746 compliant clients to
connect. In %SAFE_RENEGOTIATION mode non compliant clients will fail to
connect.

> One question, does 0.5.8 incorporate patch3.txt?

Indeed.

regards,
Nikos



From org.gnu.help-gnutls at coreland.ath.cx  Mon Aug 23 20:28:33 2010
From: org.gnu.help-gnutls at coreland.ath.cx (org.gnu.help-gnutls at coreland.ath.cx)
Date: Mon, 23 Aug 2010 18:28:33 +0000
Subject: Couple of questions regarding CommonName and peer verification
Message-ID: <20100823182833.GA54324@logik.internal.network>

'Lo.

I'm working on a small server program (the actual details of which
aren't important).

I want to use certificates and TLS to provide strong authentication
but two questions still remain:

1. Users have accounts on the server. A user may have many
   certificates registered to his account (and may log in using
   any of them). I want the user's username to appear in each
   certificate and the proper place for this appears to be in
   the CommonName field. The problem: Unless I'm mistaken, this
   field seems to be assumed to contain a hostname which is then
   checked and results in a warning if it doesn't match the
   expected value (which of course, it never will). Is there
   a better place to put an application-specific username in
   certificates?

2. I want to only allow connections from peers the server
   has certificates for - a whitelist. What's the simplest
   way to implement this? At the moment, I can only seem to
   get GnuTLS to verify peers with the CA (which it needs to
   do anyway, but I want to add this additional restriction).

As for the second question, I suppose I could create a server-specific
CA, issue certificates to all clients and then only check connecting
client certs against that CA (effectively creating a whitelist).

Perhaps there's a better way, though?




From ruckuus at gmail.com  Wed Aug 25 05:00:00 2010
From: ruckuus at gmail.com (Dwi Sasongko Supriyadi)
Date: Wed, 25 Aug 2010 10:00:00 +0700
Subject: Libtasn1-1.8 doesn't exist in gnutls directory
Message-ID: <AANLkTi=OLtqsgvrpZuOueqD4nJg4QiBMs662rYym9jE6@mail.gmail.com>

Hello Folks,

I did not see libtasn1-1.8 in gnutls directory,

[1] ftp://ftp.gnu.org/gnu/gnutls/

instead I get it from:

[2] http://ftp.gnu.org/gnu/libtasn1/

According this post:

http://www.mail-archive.com/help-shishi at gnu.org/msg00491.html

the "official" place for libtasn is in [1]. Does anyone aware of this?

Thanks in advance,
DWI




-- 
"A mathematician is a device for turning coffee into theorems." - Paul Erdos

Contacts:
? ? +62 857 8038 8298
? ? +62 813 9876 6576

Skype: dwi.sasongko
GTalk: ruckuus



From wkfta at hotmail.com  Wed Aug 25 09:02:20 2010
From: wkfta at hotmail.com (liuxiaoyu)
Date: Wed, 25 Aug 2010 15:02:20 +0800
Subject: Verify MD2 algorithm signed certificates
Message-ID: <BAY122-W3A23FB94C26BC1B26EEF7A0840@phx.gbl>


Hi,

 

I am attemping to verify some MD2 algorithm signed certificates using GnuTLS 2.6.3. 

 

I notice it says in the GnuTLS manual that MD2 algorithms have been broken and should not be trusted, but flag "GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2" can be used with verification functions "guntls_x509_crt_verify()" to allow certificates to be signed using the old MD2 algorithm.

 

However, when I used the following function call it still return "GNUTLS_CERT_INVALID".

 

 gnutls_x509_crt_verify (crt, ca_list, ca_list_size,
    GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT | GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, &output);

 

I have attached the certificates I used. Zip password: guntls

 

Is there any problem in the certificates? Any advise on what I should do to make it work?


Thanks and Regards,

Sean
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100825/0dd67987/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cred.zip
Type: application/x-zip-compressed
Size: 2307 bytes
Desc: not available
URL: </pipermail/attachments/20100825/0dd67987/attachment.bin>

From lfinsto at gwdg.de  Wed Aug 25 12:33:55 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 25 Aug 2010 12:33:55 +0200
Subject: Couple of questions regarding CommonName and peer verification
Message-ID: <97017cbf21abf67a4ad378d63cf9306b.squirrel@mailbox.gwdg.de>

On Mon, August 23, 2010 8:28 pm, org.gnu.help-gnutls at coreland.ath.cx wrote:
> 'Lo.
> I'm working on a small server program (the actual details of which
aren't important).
> I want to use certificates and TLS to provide strong authentication but
two questions still remain:
> 1. Users have accounts on the server. A user may have many
>    certificates registered to his account (and may log in using
>    any of them). I want the user's username to appear in each
>    certificate and the proper place for this appears to be in
>    the CommonName field. The problem: Unless I'm mistaken, this
>    field seems to be assumed to contain a hostname which is then checked
and results in a warning if it doesn't match the
>    expected value (which of course, it never will). Is there
>    a better place to put an application-specific username in
>    certificates?

I have the same problem.  My solution is to not call
`gnutls_x509_crt_check_hostname' when verifying the client certificate. I
have a certificate from a "real" CA, i.e., one issued by a research
institution, and the CommonName field contains my name and nothing else. 
It is not intended that it should be bound to any particular machine,
server, domain, or similar entity.  I think it's reasonable for a person
to be able to use a single certificate from various computers.  However,
I'm still finding my way with respect to X.509 certificates, so perhaps
there's a better solution.  At any rate, this certificate, which I must
use on the client-side, would seem to be incompatible with the use
`gnutls_x509_crt_check_hostname' by the server.
> 2. I want to only allow connections from peers the server
>    has certificates for - a whitelist. What's the simplest
>    way to implement this? At the moment, I can only seem to
>    get GnuTLS to verify peers with the CA (which it needs to
>    do anyway, but I want to add this additional restriction).

I think the best place to do this would be following the call to `accept'
on the server side.  The following (C++) code fragment shows how to get
the IP address (and port) of the client that has just initiated a
connection:
  int listen_sd, sd;
  struct sockaddr_in sa_cli;
  int client_len;
  char topbuf[512];
  stringstream temp_strm;


  [...]

  sd = accept (listen_sd, (SA *) & sa_cli, (socklen_t*) &client_len);
temp_strm.str("");

  temp_strm << thread_ctr_str << "In `listen_auth':  Connection from "
            << inet_ntop (AF_INET,
                          &sa_cli.sin_addr,
                          topbuf, sizeof (topbuf))
                << ", port " << ntohs (sa_cli.sin_port)
                << endl;

I think it should be easy to check it against a list of IP-addresses and
break off the connection if it's not in the list.

> As for the second question, I suppose I could create a server-specific
CA, issue certificates to all clients and then only check connecting
client certs against that CA (effectively creating a whitelist).

I think this would only be useful for testing purposes and wouldn't work
for "real" CA certificates issued by "trusted" organizations.


Laurence Finston


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de







From nmav at gnutls.org  Wed Aug 25 16:58:25 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Aug 2010 16:58:25 +0200
Subject: Couple of questions regarding CommonName and peer verification
In-Reply-To: <20100823182833.GA54324@logik.internal.network>
References: <20100823182833.GA54324@logik.internal.network>
Message-ID: <4C752F91.2070702@gnutls.org>

On 08/23/2010 08:28 PM, org.gnu.help-gnutls at coreland.ath.cx wrote:
> 'Lo.
> 
> I'm working on a small server program (the actual details of which
> aren't important).
> 
> I want to use certificates and TLS to provide strong authentication
> but two questions still remain:
> 
> 1. Users have accounts on the server. A user may have many
>    certificates registered to his account (and may log in using
>    any of them). I want the user's username to appear in each
>    certificate and the proper place for this appears to be in
>    the CommonName field. The problem: Unless I'm mistaken, this
>    field seems to be assumed to contain a hostname which is then
>    checked and results in a warning if it doesn't match the
>    expected value (which of course, it never will). Is there
>    a better place to put an application-specific username in
>    certificates?

Only if you use it as a web server certificate. Otherwise you are free
to put whatever you like there. I remember there was a UID field as well.

> 2. I want to only allow connections from peers the server
>    has certificates for - a whitelist. What's the simplest
>    way to implement this? At the moment, I can only seem to
>    get GnuTLS to verify peers with the CA (which it needs to
>    do anyway, but I want to add this additional restriction).

Why not use certificates and certificate revocation lists? Otherwise
there is no point into using certificates at all. You could use TLS-SRP
or TLS-PSK with symmetric keys and avoid the burden of certificates.

If you insist on this restriction just compare the certificate sent in
the connection with the certificates in your whitelist.

> As for the second question, I suppose I could create a server-specific
> CA, issue certificates to all clients and then only check connecting
> client certs against that CA (effectively creating a whitelist).

This is the obvious thing of doing when using certificates for
authentication. You can revoke certificates and put them into a server
accessible revocation list as well.

regards,
Nikos



From nmav at gnutls.org  Wed Aug 25 17:13:51 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 Aug 2010 17:13:51 +0200
Subject: Verify MD2 algorithm signed certificates
Message-ID: <4C75332F.6070706@gnutls.org>

On 08/25/2010 09:02 AM, liuxiaoyu wrote:

> Hi,
> I am attemping to verify some MD2 algorithm signed certificates using GnuTLS 2.6.3. 
> I notice it says in the GnuTLS manual that MD2 algorithms have been broken and should not be trusted, but flag "GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2" can be used with verification functions "guntls_x509_crt_verify()" to allow certificates to be signed using the old MD2 algorithm.
> However, when I used the following function call it still return "GNUTLS_CERT_INVALID".
>  gnutls_x509_crt_verify (crt, ca_list, ca_list_size,
>     GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT | GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, &output);

MD2 is not supported by libgcrypt thus verification or generation always
fails. If you insist in verifying that you could try the gnutls 2.11.x
versions compiled against nettle.

In any case you shouldn't even bother. MD2 is so broken that even if the
signature check is correct you shouldn't trust the certificate anyway.

regards,
Nikos





From haloris-tx at yahoo.co.uk  Sat Aug 28 19:34:19 2010
From: haloris-tx at yahoo.co.uk (Carson Hewitt)
Date: Sat, 28 Aug 2010 19:34:19 +0200
Subject: wildcard matching components
Message-ID: <haloris-tx-2444E5.19341928082010@snews.gmane.org>

Hello,

I was trying to open an audio stream over https using VLC (1.1.3), which bundles 
gnutls.

The CA chain verification is fine. Then we get:

gnutls error: Certificate does not match "foo.bar.example.com"

Indeed, the common name of the server certificate is "*.example.com", which does 
not match our hostname because of the dot in foo.bar (I don't know if this 
behaviour is specified by the protocols implemented by gnutls, or if it's up to 
the implementation).

Is there a way to convince gnutls to trust the certificate even if it does not 
match the hostname ?

-- Carson




From nmav at gnutls.org  Sun Aug 29 21:02:55 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 29 Aug 2010 21:02:55 +0200
Subject: wildcard matching components
In-Reply-To: <haloris-tx-2444E5.19341928082010@snews.gmane.org>
References: <haloris-tx-2444E5.19341928082010@snews.gmane.org>
Message-ID: <4C7AAEDF.1080709@gnutls.org>

On 08/28/2010 07:34 PM, Carson Hewitt wrote:
> Hello,
> 
> I was trying to open an audio stream over https using VLC (1.1.3), which bundles 
> gnutls.
> 
> The CA chain verification is fine. Then we get:
> 
> gnutls error: Certificate does not match "foo.bar.example.com"
> Indeed, the common name of the server certificate is "*.example.com", which does 
> not match our hostname because of the dot in foo.bar (I don't know if this 
> behaviour is specified by the protocols implemented by gnutls, or if it's up to 
> the implementation).
> Is there a way to convince gnutls to trust the certificate even if it
does not
> match the hostname ?

gnutls name verification functions follow RFC2818 that explicitly says
that *.example.com should not match foo.bar.example.com. However using
the RFC2818 name checking is up to the application using gnutls. Just
tell your application not to check the name on the certificate.

regards,
Nikos



From haloris-tx at yahoo.co.uk  Sun Aug 29 23:25:22 2010
From: haloris-tx at yahoo.co.uk (Carson Hewitt)
Date: Sun, 29 Aug 2010 23:25:22 +0200
Subject: wildcard matching components
References: <haloris-tx-2444E5.19341928082010@snews.gmane.org>
	<4C7AAEDF.1080709@gnutls.org>
Message-ID: <haloris-tx-3EC001.23252229082010@snews.gmane.org>

In article <4C7AAEDF.1080709 at gnutls.org>,
 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 08/28/2010 07:34 PM, Carson Hewitt wrote:
> > Hello,
> > 
> > gnutls error: Certificate does not match "foo.bar.example.com"
> 
> gnutls name verification functions follow RFC2818 that explicitly says
> that *.example.com should not match foo.bar.example.com. However using
> the RFC2818 name checking is up to the application using gnutls. Just
> tell your application not to check the name on the certificate.
> 
> regards,
> Nikos

Thanks for your reply. Now back to the VLC people !




From goran.pivac at gmail.com  Mon Aug 30 10:41:19 2010
From: goran.pivac at gmail.com (Goran Pivac)
Date: Mon, 30 Aug 2010 10:41:19 +0200
Subject: compile gnu-tls 2.10.1
Message-ID: <AANLkTimSKrzebnuy42x4qNCgCmqCfz5k7KMkjEXc2B+i@mail.gmail.com>

Hi,
I'm trying to compile and install gnutls2.10.1 on my AIX6.1 machine
but I'm having difficulties.

This is an error I get:
*****************************
make[1]: Entering directory `/tmp/gnutls-2.10.1'
Making all in lib
make[2]: Entering directory `/tmp/gnutls-2.10.1/lib'
/usr/linux/bin/make  all-recursive
make[3]: Entering directory `/tmp/gnutls-2.10.1/lib'
Making all in gl
make[4]: Entering directory `/tmp/gnutls-2.10.1/lib/gl'
/usr/linux/bin/make  all-recursive
make[5]: Entering directory `/tmp/gnutls-2.10.1/lib/gl'
Making all in tests
make[6]: Entering directory `/tmp/gnutls-2.10.1/lib/gl/tests'
/usr/linux/bin/make  all-recursive
make[7]: Entering directory `/tmp/gnutls-2.10.1/lib/gl/tests'
Making all in .
make[8]: Entering directory `/tmp/gnutls-2.10.1/lib/gl/tests'
make[8]: Nothing to be done for `all-am'.
make[8]: Leaving directory `/tmp/gnutls-2.10.1/lib/gl/tests'
make[7]: Leaving directory `/tmp/gnutls-2.10.1/lib/gl/tests'
make[6]: Leaving directory `/tmp/gnutls-2.10.1/lib/gl/tests'
make[6]: Entering directory `/tmp/gnutls-2.10.1/lib/gl'
make[6]: Nothing to be done for `all-am'.
make[6]: Leaving directory `/tmp/gnutls-2.10.1/lib/gl'
make[5]: Leaving directory `/tmp/gnutls-2.10.1/lib/gl'
make[4]: Leaving directory `/tmp/gnutls-2.10.1/lib/gl'
Making all in po
make[4]: Entering directory `/tmp/gnutls-2.10.1/lib/po'
make[4]: Leaving directory `/tmp/gnutls-2.10.1/lib/po'
Making all in includes
make[4]: Entering directory `/tmp/gnutls-2.10.1/lib/includes'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/lib/includes'
Making all in x509
make[4]: Entering directory `/tmp/gnutls-2.10.1/lib/x509'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/lib/x509'
Making all in minitasn1
make[4]: Entering directory `/tmp/gnutls-2.10.1/lib/minitasn1'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/lib/minitasn1'
make[4]: Entering directory `/tmp/gnutls-2.10.1/lib'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/lib'
make[3]: Leaving directory `/tmp/gnutls-2.10.1/lib'
make[2]: Leaving directory `/tmp/gnutls-2.10.1/lib'
Making all in libextra
make[2]: Entering directory `/tmp/gnutls-2.10.1/libextra'
/usr/linux/bin/make  all-recursive
make[3]: Entering directory `/tmp/gnutls-2.10.1/libextra'
Making all in gl
make[4]: Entering directory `/tmp/gnutls-2.10.1/libextra/gl'
/usr/linux/bin/make  all-am
make[5]: Entering directory `/tmp/gnutls-2.10.1/libextra/gl'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory `/tmp/gnutls-2.10.1/libextra/gl'
make[4]: Leaving directory `/tmp/gnutls-2.10.1/libextra/gl'
Making all in includes
make[4]: Entering directory `/tmp/gnutls-2.10.1/libextra/includes'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/libextra/includes'
make[4]: Entering directory `/tmp/gnutls-2.10.1/libextra'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/libextra'
make[3]: Leaving directory `/tmp/gnutls-2.10.1/libextra'
make[2]: Leaving directory `/tmp/gnutls-2.10.1/libextra'
Making all in gl
make[2]: Entering directory `/tmp/gnutls-2.10.1/gl'
/usr/linux/bin/make  all-recursive
make[3]: Entering directory `/tmp/gnutls-2.10.1/gl'
Making all in tests
make[4]: Entering directory `/tmp/gnutls-2.10.1/gl/tests'
/usr/linux/bin/make  all-recursive
make[5]: Entering directory `/tmp/gnutls-2.10.1/gl/tests'
Making all in .
make[6]: Entering directory `/tmp/gnutls-2.10.1/gl/tests'
make[6]: Nothing to be done for `all-am'.
make[6]: Leaving directory `/tmp/gnutls-2.10.1/gl/tests'
make[5]: Leaving directory `/tmp/gnutls-2.10.1/gl/tests'
make[4]: Leaving directory `/tmp/gnutls-2.10.1/gl/tests'
make[4]: Entering directory `/tmp/gnutls-2.10.1/gl'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/gl'
make[3]: Leaving directory `/tmp/gnutls-2.10.1/gl'
make[2]: Leaving directory `/tmp/gnutls-2.10.1/gl'
Making all in src
make[2]: Entering directory `/tmp/gnutls-2.10.1/src'
Making all in cfg
make[3]: Entering directory `/tmp/gnutls-2.10.1/src/cfg'
Making all in platon
make[4]: Entering directory `/tmp/gnutls-2.10.1/src/cfg/platon'
Making all in str
make[5]: Entering directory `/tmp/gnutls-2.10.1/src/cfg/platon/str'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory `/tmp/gnutls-2.10.1/src/cfg/platon/str'
make[5]: Entering directory `/tmp/gnutls-2.10.1/src/cfg/platon'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory `/tmp/gnutls-2.10.1/src/cfg/platon'
make[4]: Leaving directory `/tmp/gnutls-2.10.1/src/cfg/platon'
make[4]: Entering directory `/tmp/gnutls-2.10.1/src/cfg'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/tmp/gnutls-2.10.1/src/cfg'
make[3]: Leaving directory `/tmp/gnutls-2.10.1/src/cfg'
make[3]: Entering directory `/tmp/gnutls-2.10.1/src'
cli.gaa -o cli-gaa.c -i cli-gaa.h
make[3]: cli.gaa: Command not found
make[3]: [cli-gaa.c] Error 127 (ignored)
make[3]: Leaving directory `/tmp/gnutls-2.10.1/src'
make[2]: Leaving directory `/tmp/gnutls-2.10.1/src'
Making all in doc
make[2]: Entering directory `/tmp/gnutls-2.10.1/doc'
/usr/linux/bin/make  all-recursive
make[3]: Entering directory `/tmp/gnutls-2.10.1/doc'
Making all in examples
make[4]: Entering directory `/tmp/gnutls-2.10.1/doc/examples'
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99   -g -O2
-no-install  -o ex-serv1 ex-serv1.o libexamples.la ../../lib/li
bgnutls.la ../../libextra/libgnutls-extra.la ../../gl/libgnu.la
libtool: link: gcc -std=gnu99 -g -O2 -o ex-serv1 ex-serv1.o
./.libs/libexamples.a -L../../lib/.libs -lgnutls
-L../../libextra/.libs
 -lgnutls-extra ../../gl/.libs/libgnu.a
-Wl,-blibpath:/tmp/gnutls-2.10.1/lib/.libs:/tmp/gnutls-2.10.1/libextra/.libs:/usr/local/lib:
/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0:/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/../../..:/usr/lib:/lib
ld: 0711-317 ERROR: Undefined symbol: .gcry_control
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make[4]: *** [ex-serv1] Error 1
make[4]: Leaving directory `/tmp/gnutls-2.10.1/doc/examples'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/gnutls-2.10.1/doc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/gnutls-2.10.1/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/gnutls-2.10.1'
make: *** [all] Error 2
*********************************************
???
ld: 0711-317 ERROR: Undefined symbol: .gcry_control
???


I'm using make3.8.
gcc4.2.0.3
and before that I've compiled and installed libgcrypt1.4.6 downloaded
from ftp://ftp.gnupg.org/gcrypt/libgcrypt/

I've also tried with older version of gnutls2.8.6, but error is the same!

I'm new at compiling, but I have a feeling that it's very stupid error!


Does anybody have any idea?



From mike.hoy at canberra.com  Mon Aug 30 20:31:26 2010
From: mike.hoy at canberra.com (HOY Mike)
Date: Mon, 30 Aug 2010 14:31:26 -0400
Subject: 2.10.1
Message-ID: <0C4556B6BAE1734A840FDF7EEE66C1A50669C27D@AUSMERIMX01.adom.ad.corp>

Hello,

 

I am working with a customer device that support TLS.  Upon completing
the handshake I expect to see data come at me.  I get a decompression
error on the second buffer, the first being a small header.

 

All the data I get before getting the error is decrypted correctly.

 

The decompression dies because the length is 4 bytes longer than the
compress_size value.  Can the customer device cause this or do I have
something set wrong or not at all?

 

The length is 16388 and the compress_size is 16384 (max for the
session).

 

Mike Hoy

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100830/d0e1d4a4/attachment.htm>

From nmav at gnutls.org  Mon Aug 30 20:53:35 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 30 Aug 2010 20:53:35 +0200
Subject: 2.10.1
In-Reply-To: <0C4556B6BAE1734A840FDF7EEE66C1A50669C27D@AUSMERIMX01.adom.ad.corp>
References: <0C4556B6BAE1734A840FDF7EEE66C1A50669C27D@AUSMERIMX01.adom.ad.corp>
Message-ID: <4C7BFE2F.4050102@gnutls.org>

On 08/30/2010 08:31 PM, HOY Mike wrote:
> Hello,

> I am working with a customer device that support TLS.  Upon completing
> the handshake I expect to see data come at me.  I get a decompression
> error on the second buffer, the first being a small header.
> All the data I get before getting the error is decrypted correctly.
> The decompression dies because the length is 4 bytes longer than the
> compress_size value.  Can the customer device cause this or do I have
> something set wrong or not at all?
> The length is 16388 and the compress_size is 16384 (max for the
> session).

Please be more specific. Who returns the decompression error? Is it the
internal compression in gnutls or some other scheme you use? If it is
the former, did you try without the zlib compression?

regards,
Nikos



From nmav at gnutls.org  Tue Aug 31 00:02:51 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 31 Aug 2010 00:02:51 +0200
Subject: 2.10.1
In-Reply-To: <0C4556B6BAE1734A840FDF7EEE66C1A50669C521@AUSMERIMX01.adom.ad.corp>
References: <0C4556B6BAE1734A840FDF7EEE66C1A50669C27D@AUSMERIMX01.adom.ad.corp>
	<4C7BFE2F.4050102@gnutls.org>
	<0C4556B6BAE1734A840FDF7EEE66C1A50669C521@AUSMERIMX01.adom.ad.corp>
Message-ID: <4C7C2A8B.5000902@gnutls.org>

On 08/30/2010 10:44 PM, HOY Mike wrote:
> The decompression error is coming from gnutls in gnutls_cipher.c, the
> last size test in _gnutls_ciphertext2compressed.  The TLS Session is
> setup WITHOUT compression, at least, according to the packet exchange
> before the keys are exchanged.

Then please enable logging using gnutls_global_set_log_function() and
gnutls_global_set_log_level().


> The thing that makes we look at gnutls is that with Opera I can transfer
> the file without trouble.  And all of this is being done without client
> certificates.

What is the server on the other side of the connection? The plaintext
value of 16488 is clearly violating the TLS spec. The maximum size for a
TLS record is 16484, and I guess this is the reason why gnutls is
complaining.


regards,
Nikos





From nmav at gnutls.org  Tue Aug 31 17:56:26 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 31 Aug 2010 17:56:26 +0200
Subject: 2.10.1
In-Reply-To: <0C4556B6BAE1734A840FDF7EEE66C1A50669CA08@AUSMERIMX01.adom.ad.corp>
References: <0C4556B6BAE1734A840FDF7EEE66C1A50669C27D@AUSMERIMX01.adom.ad.corp>
	<4C7BFE2F.4050102@gnutls.org>
	<0C4556B6BAE1734A840FDF7EEE66C1A50669C521@AUSMERIMX01.adom.ad.corp>
	<4C7C2A8B.5000902@gnutls.org>
	<0C4556B6BAE1734A840FDF7EEE66C1A50669CA08@AUSMERIMX01.adom.ad.corp>
Message-ID: <4C7D262A.8080603@gnutls.org>

On 08/31/2010 04:56 PM, HOY Mike wrote:
> Hello Nikos,
> 
> I have a dump at level 10 of the TLS session.  If you need anything else
> please let me know.

Would removing the check in the compressed2ciphertext allow gnutls to
continue? If yes, I might something similar to the %COMPAT string
capabilities. I'd also ask for more information on the peer's TLS
implementation.

regards,
Nikos