From wcang at yahoo.com  Wed Mar  1 05:25:13 2006
From: wcang at yahoo.com (Ang Way Chuang)
Date: Wed, 1 Mar 2006 04:25:13 +0000 (GMT)
Subject: [Help-gnutls] TLS message boundary
Message-ID: <20060301042513.37837.qmail@web51504.mail.yahoo.com>

Hi all,
     Does TLS/SSL preserve data message boundary like SCTP? Is assuming whatever message that is sent and received through gnutls_record_{send,recv} always respect data message boundary a correct assumption?
 
 
 Regards,
 Ang Way Chuang
 

May you be well and happy
		
---------------------------------
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20060301/1cd2b26b/attachment.htm>

From jas at extundo.com  Thu Mar  2 10:08:53 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 02 Mar 2006 10:08:53 +0100
Subject: [Help-gnutls] Re: TLS message boundary
In-Reply-To: <20060301042513.37837.qmail@web51504.mail.yahoo.com> (Ang Way
	Chuang's message of "Wed, 1 Mar 2006 04:25:13 +0000 (GMT)")
References: <20060301042513.37837.qmail@web51504.mail.yahoo.com>
Message-ID: <jas1wxltdqy.fsf@latte.josefsson.org>

Ang Way Chuang <wcang at yahoo.com> writes:

> Hi all,
>     Does TLS/SSL preserve data message boundary like SCTP? Is assuming whatever
> message that is sent and received through gnutls_record_{send,recv} always
> respect data message boundary a correct assumption?

Hi!  No, that is an incorrect assumption.  See RFC 2246:

   The record layer fragments information blocks into TLSPlaintext
   records carrying data in chunks of 2^14 bytes or less. Client message
   boundaries are not preserved in the record layer (i.e., multiple
   client messages of the same ContentType may be coalesced into a
   single TLSPlaintext record, or a single message may be fragmented
   across several records).

You can of course use a TLV format inside the TLS channel to get what
you want.

Regards,
Simon




From whatever at fsrz.net  Wed Mar  1 19:34:06 2006
From: whatever at fsrz.net (Rich Fought)
Date: Wed, 1 Mar 2006 12:34:06 -0600
Subject: [Help-gnutls] TLS message boundary
In-Reply-To: <20060301042513.37837.qmail@web51504.mail.yahoo.com>
Message-ID: <003801c63d5e$b89e7390$5103a8c0@psislidell.com>

If I understand your question correctly, SSL/TLS will fragment your data
message if it is larger than the record size (max 16k) - and it is up to the
receiving application to put the fragments back together.  So I believe the
answer to your particular question is no. 
 
Regards,
Rich

________________________________

From: help-gnutls-bounces+whatever=fsrz.net at gnu.org
[mailto:help-gnutls-bounces+whatever=fsrz.net at gnu.org] On Behalf Of Ang Way
Chuang
Sent: Tuesday, February 28, 2006 10:25 PM
To: help-gnutls at gnu.org
Subject: [Help-gnutls] TLS message boundary


Hi all,
    Does TLS/SSL preserve data message boundary like SCTP? Is assuming
whatever message that is sent and received through gnutls_record_{send,recv}
always respect data message boundary a correct assumption?


Regards,
Ang Way Chuang


May you be well and happy 

________________________________

To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre
<http://us.rd.yahoo.com/mail/uk/taglines/default/security_centre/*http://uk.
security.yahoo.com/> .







From whatever at fsrz.net  Thu Mar  2 18:39:20 2006
From: whatever at fsrz.net (Rich Fought)
Date: Thu, 2 Mar 2006 11:39:20 -0600
Subject: [Help-gnutls] TLS message boundary
In-Reply-To: <20060302050537.66748.qmail@web51509.mail.yahoo.com>
Message-ID: <000f01c63e20$3c9e22f0$5103a8c0@psislidell.com>

>From the TLS RFC (2246):
 
"6.2.1. Fragmentation

   The record layer fragments information blocks into TLSPlaintext
   records carrying data in chunks of 2^14 bytes or less. Client message
   boundaries are not preserved in the record layer (i.e., multiple
   client messages of the same ContentType may be coalesced into a
   single TLSPlaintext record, or a single message may be fragmented
   across several records)."

So the theoretical answer is no.  In practice however, as you have
discovered,
as long as you transmit a single data message per TLS_send and that data
message
is less than 16k, you should be OK.  The only caveat being that there is
a provision in the TLS Extensions RFC for negotiating a smaller record size.
This however is requested by the client, and the server may opt not to
satisfy the request.

Hope this helps,
Rich

________________________________

From: Ang Way Chuang [mailto:wcang at yahoo.com] 
Sent: Wednesday, March 01, 2006 11:06 PM
To: Rich Fought; help-gnutls at gnu.org
Subject: RE: [Help-gnutls] TLS message boundary



> Seems like data message boundary is still respected because none 
> of data are truncated/appended. The test is performed on loop back 
> interface. So is it 100% safe to assume gnutls_record_recv respect
> data message boundary for app that sends less than 16k? Please advise.








From wcang at yahoo.com  Thu Mar  2 06:05:37 2006
From: wcang at yahoo.com (Ang Way Chuang)
Date: Thu, 2 Mar 2006 05:05:37 +0000 (GMT)
Subject: [Help-gnutls] TLS message boundary
In-Reply-To: <003801c63d5e$b89e7390$5103a8c0@psislidell.com>
Message-ID: <20060302050537.66748.qmail@web51509.mail.yahoo.com>


> SSL/TLS will fragment your data message if it is larger than the 
> record size (max 16k) - and it is up to the receiving application 
> to put the fragments back together. 

Thanks. But typically my application will only send data that are 
less than 100 bytes and will not send more than 500 bytes at any 
particular time. So is the data message boundary still respected in
such cases? 

I did a quick test on my simple gnutls client/server app:

client:

 buf[0] = 0;

 for (i = 0; i < 10; i++) {
  sprintf(temp, "%c", 'a' + i);
  strcat(buf, temp);
  len = strlen(buf) + 1;
  ret = gnutls_record_send(session, buf, len);
  
  if (ret != len) {
   fprintf(stderr, "buffer length(%d) doesn't equal to send len(%d)\n", len, ret);
  }
 }
 
        gnutls_bye(session, GNUTLS_SHUT_WR);

server:
  try = 10;

  while (try-- > 0) {
   FD_ZERO(&read_fds);
   FD_SET(sockfd, &read_fds);
   select(sockfd + 1, &read_fds, NULL, NULL, NULL);
   
  }

                do {
   ret = gnutls_record_recv(session, buf, sizeof(buf));
   printf("length %d\n", ret);
   printf("buffer: %s\n", buf);
  } while (ret != 0);


The output on server:
length 2
buffer: a
length 3
buffer: ab
length 4
buffer: abc
length 5
buffer: abcd
length 6
buffer: abcde
length 7
buffer: abcdef
length 8
buffer: abcdefg
length 9
buffer: abcdefgh
length 10
buffer: abcdefghi
length 11
buffer: abcdefghij


Seems like data message boundary is still respected because none 
of data are truncated/appended. The test is performed on loop back 
interface. So is it 100% safe to assume gnutls_record_recv respect
data message boundary for app that sends less than 16k? Please advise.

Thanks in advance


Regards,
Ang Way Chuang

 



May you be well and happy
		
---------------------------------
Yahoo! Messenger  NEW - crystal clear PC to PC calling worldwide with voicemail 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20060302/b55d33c2/attachment.htm>

From wcang at yahoo.com  Fri Mar  3 09:14:54 2006
From: wcang at yahoo.com (Ang Way Chuang)
Date: Fri, 3 Mar 2006 08:14:54 +0000 (GMT)
Subject: [Help-gnutls] thread safety of gnutls
Message-ID: <20060303081454.87123.qmail@web51515.mail.yahoo.com>

Hi all,
    I am very sorry for asking too many questions. I ran a multithread test on gnutls_record_{recv,send}. When there are multiple threads using one of these functions 
 simultaneously, the application will segfault. However, if i protect these functions with mutex, it won't segfault. But i thought gnutls is thread safe by design. 
 
 I've called these in my app:
 
 gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
 gnutls_global_init();
 
 Here is thread function:
       
void * tls_session(void * data) {  int ret;  char buf[501];  int times;  unsigned int len;  gnutls_session_t session = (gnutls_session_t) data;  
 times = 30;  len = times;  memset(buf, 'a' + (rand() % ('z' - 'a')),  len);  buf[len] = 0;    while (!term && !reload && times--) {   //pthread_mutex_lock(&mutex);   ret = gnutls_record_send(session, buf, len + 1);   //pthread_mutex_unlock(&mutex);    if (ret < 1) {    fprintf(stderr, "Failed tls send %s\n", gnutls_strerror(ret));    break;   }      if (ret == 0)    break;      //pthread_mutex_lock(&mutex);   ret = gnutls_record_recv(session, buf, sizeof(buf));   //pthread_mutex_unlock(&mutex);      if (ret < 1) {    fprintf(stderr, "Failed tls recv %s\n", gnutls_strerror(ret));    break;   }      if (ret == 0)    break;     }     return NULL; } 
If the pthread_mutex_{un,}lock is commented out. Are gnutls functions supposed to be protected using synchronization primitives? Thanks in advance.
 
 Regards,
 Ang Way Chuang
 
 

May you be well and happy
		
---------------------------------
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20060303/92a51164/attachment.htm>

From nmav at gnutls.org  Sat Mar  4 09:07:49 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 4 Mar 2006 09:07:49 +0100
Subject: [Help-gnutls] thread safety of gnutls
In-Reply-To: <20060303081454.87123.qmail@web51515.mail.yahoo.com>
References: <20060303081454.87123.qmail@web51515.mail.yahoo.com>
Message-ID: <200603040907.49847.nmav@gnutls.org>

On Fri 03 Mar 2006 09:14, Ang Way Chuang wrote:
> Hi all,
>     I am very sorry for asking too many questions. I ran a
> multithread test on gnutls_record_{recv,send}. When there are
> multiple threads using one of these functions simultaneously, the
> application will segfault. However, if i protect these functions with
> mutex, it won't segfault. But i thought gnutls is thread safe by
> design.

Yes gnutls is thread safe by design. As far as I can understand from the
code below you are accessing a single session from several threads. This
is not supported. If you want to do that you have to use locks.

regards,
Nikos Mavrogiannopoulos




From e_agf at yahoo.es  Sun Mar  5 13:51:46 2006
From: e_agf at yahoo.es (Fco. J.)
Date: Sun, 05 Mar 2006 12:51:46 +0000
Subject: [Help-gnutls] Any implemetation of GNUTLS for apache?
Message-ID: <1141563106.3598.7.camel@localhost>

Hello,
Anyone knows any implementation of gnutls library for apache?

mod_gnutls for apache seems to be dead.

Thanks in advance.




From jas at extundo.com  Sun Mar  5 23:06:22 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 05 Mar 2006 23:06:22 +0100
Subject: [Help-gnutls] Re: Any implemetation of GNUTLS for apache?
In-Reply-To: <1141563106.3598.7.camel@localhost> (Fco. J.'s message of "Sun,
	05 Mar 2006 12:51:46 +0000")
References: <1141563106.3598.7.camel@localhost>
Message-ID: <jask6b8bl7l.fsf@latte.josefsson.org>

"Fco. J." <e_agf at yahoo.es> writes:

> Hello,
> Anyone knows any implementation of gnutls library for apache?
>
> mod_gnutls for apache seems to be dead.

I'm not aware of any other implementations.  Perhaps you can pick up
mod_gnutls and try to improve it?  Mod_gnutls looked rather short and
sweat to me when I looked at it some time ago.

Regards,
Simon




From jas at extundo.com  Sun Mar  5 23:53:17 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 05 Mar 2006 23:53:17 +0100
Subject: [Help-gnutls] Re: Any implemetation of GNUTLS for apache?
In-Reply-To: <jask6b8bl7l.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Sun, 05 Mar 2006 23:06:22 +0100")
References: <1141563106.3598.7.camel@localhost>
	<jask6b8bl7l.fsf@latte.josefsson.org>
Message-ID: <jaszmk4a4gy.fsf@latte.josefsson.org>

Simon Josefsson <jas at extundo.com> writes:

> "Fco. J." <e_agf at yahoo.es> writes:
>
>> Hello,
>> Anyone knows any implementation of gnutls library for apache?
>>
>> mod_gnutls for apache seems to be dead.
>
> I'm not aware of any other implementations.  Perhaps you can pick up
> mod_gnutls and try to improve it?  Mod_gnutls looked rather short and
> sweat to me when I looked at it some time ago.

Heh, oops.... I meant 'short and sweet'.  Sorry.




From chip at outoforder.cc  Mon Mar  6 00:01:14 2006
From: chip at outoforder.cc (Paul Querna)
Date: Sun, 05 Mar 2006 15:01:14 -0800
Subject: [Help-gnutls] Re: Any implemetation of GNUTLS for apache?
In-Reply-To: <jaszmk4a4gy.fsf@latte.josefsson.org>
References: <1141563106.3598.7.camel@localhost>	<jask6b8bl7l.fsf@latte.josefsson.org>
	<jaszmk4a4gy.fsf@latte.josefsson.org>
Message-ID: <440B6DBA.8040503@outoforder.cc>

Simon Josefsson wrote:
> Simon Josefsson <jas at extundo.com> writes:
> 
>> "Fco. J." <e_agf at yahoo.es> writes:
>>
>>> Hello,
>>> Anyone knows any implementation of gnutls library for apache?
>>>
>>> mod_gnutls for apache seems to be dead.
>> I'm not aware of any other implementations.  Perhaps you can pick up
>> mod_gnutls and try to improve it?  Mod_gnutls looked rather short and
>> sweat to me when I looked at it some time ago.
> 
> Heh, oops.... I meant 'short and sweet'.  Sorry.

I wouldn't call it dead, just inactive.

I have no required features or motivation to improve it.

Feel free to send patches :)

-Paul






From trapni at gentoo.org  Wed Mar  8 14:14:09 2006
From: trapni at gentoo.org (Christian Parpart)
Date: Wed, 8 Mar 2006 14:14:09 +0100
Subject: [Help-gnutls] Re: Any implemetation of GNUTLS for apache?
In-Reply-To: <440B6DBA.8040503@outoforder.cc>
References: <1141563106.3598.7.camel@localhost>
	<jaszmk4a4gy.fsf@latte.josefsson.org>
	<440B6DBA.8040503@outoforder.cc>
Message-ID: <200603081414.11540.trapni@gentoo.org>

On Monday 06 March 2006 00:01, Paul Querna wrote:
> Simon Josefsson wrote:
> > Simon Josefsson <jas at extundo.com> writes:
> >> "Fco. J." <e_agf at yahoo.es> writes:
> >>> Hello,
> >>> Anyone knows any implementation of gnutls library for apache?
> >>>
> >>> mod_gnutls for apache seems to be dead.
> >>
> >> I'm not aware of any other implementations.  Perhaps you can pick up
> >> mod_gnutls and try to improve it?  Mod_gnutls looked rather short and
> >> sweat to me when I looked at it some time ago.
> >
> > Heh, oops.... I meant 'short and sweet'.  Sorry.
>
> I wouldn't call it dead, just inactive.

hybernation :o)

> I have no required features or motivation to improve it.

I can't updates the source tree, because for whatever reason it wants a 
password/username from me. since when? and why?

> Feel free to send patches :)

I submitted patches for mod_transform about a month ago, and still no sign of 
at least telling me how the maintainer (one of outoforder.cc, whoever) feels 
about this patch in detail, though, no merged happened yet.

Regards,
Christian Parpart.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: </pipermail/attachments/20060308/5aa21941/attachment.pgp>

From jas at extundo.com  Wed Mar 15 12:28:18 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 15 Mar 2006 12:28:18 +0100
Subject: [Help-gnutls] Approaching GnuTLS 1.4.0
Message-ID: <87ek14aqwd.fsf@latte.josefsson.org>

We're approaching the release of GnuTLS 1.4.0, the next stable branch.
Please test 1.3.5 as if it were a new stable release, and report any
problems or missing features.

http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2

/Simon




From jas at extundo.com  Wed Mar 15 21:07:34 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 15 Mar 2006 21:07:34 +0100
Subject: [Help-gnutls] Re: Approaching GnuTLS 1.4.0
In-Reply-To: <4418639C.1070007@mur.at> (Rupert Kittinger's message of "Wed, 15
	Mar 2006 19:57:32 +0100")
References: <87ek14aqwd.fsf@latte.josefsson.org> <4418639C.1070007@mur.at>
Message-ID: <87u09za2ux.fsf@latte.josefsson.org>

Rupert Kittinger <rkit at mur.at> writes:

> Simon Josefsson schrieb:
>> We're approaching the release of GnuTLS 1.4.0, the next stable branch.
>> Please test 1.3.5 as if it were a new stable release, and report any
>> problems or missing features.
>> http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2
>> /Simon
>> 
>>
>
> The race condition I reported some days ago is still present
> 1.3.5. Has the fix Nikos put in the cvs head been included?

Yes, but didn't make it for 1.3.5.  It will be in 1.4.0 though.

You can also try the daily snapshots:

http://josefsson.org/daily/gnutls/
http://josefsson.org/daily/gnutls/gnutls-20060315.tar.gz

/Simon




From cameron at CS.Stanford.EDU  Thu Mar 16 10:58:12 2006
From: cameron at CS.Stanford.EDU (Cameron Ring)
Date: Thu, 16 Mar 2006 01:58:12 -0800 (PST)
Subject: [Help-gnutls] hang in gnutls_bye in gaim
Message-ID: <Pine.LNX.4.62.0603160131190.15136@xenon.Stanford.EDU>

i'm looking into a problem with gaim 1.5 + gnutls 1.0.25 where 
disconnecting from a jabber server with TLS supprt (wildfire, in this 
case) causes gaim to hang. here's the backtrace of the hung process:

#0  0x001017a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x001e2451 in recv () from /lib/tls/libc.so.6
#2  0x00861cdb in _gnutls_read (session=0x9ef4108, iptr=0x9ef65f8, sizeOfPtr=5, flags=0) at gnutls_buffers.c:217
#3  0x008622d9 in _gnutls_io_read_buffered (session=0x9ef4108, iptr=0xbfe3d0d8, sizeOfPtr=5, recv_type=4294967295) at gnutls_buffers.c:408
#4  0x0085f887 in _gnutls_recv_int (session=0x9ef4108, type=GNUTLS_ALERT, htype=4294967295, data=0x0, sizeofdata=0) at gnutls_record.c:680
#5  0x00860783 in gnutls_bye (session=0x9ef4108, how=GNUTLS_SHUT_RDWR) at gnutls_record.c:197
#6  0x080d8833 in ssl_gnutls_close (gsc=0x9ed84d0) at ssl-gnutls.c:135
#7  0x080b2fa6 in gaim_ssl_close (gsc=0x9ed84d0) at sslconn.c:183
#8  0x0811baa8 in jabber_close (gc=0x9ed7c28) at jabber.c:764
#9  0x0809a35f in gaim_connection_disconnect (gc=0x9ed7c28) at connection.c:254
#10 0x0809ac06 in gaim_connections_disconnect_all () at connection.c:616
#11 0x080d8479 in main (argc=5, argv=0xbfe3d434) at main.c:605

i'm not sure whether the problem is on the client side or the server (e.g. 
is the server not replying to our request to close the connection?), but 
i'm hoping for some pointers in the right direction. if, indeed, the 
server isn't sending a reply, is there a way to set a timeout so the 
client won't wait forever for a reply that isnt' coming?

from the application side, i guess i could grab the transport ptr and set 
a timeout on the socket before calling gnutls_bye. does that sound 
reasonable?

thanks,
cam




From jas at extundo.com  Fri Mar 17 09:52:00 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 17 Mar 2006 09:52:00 +0100
Subject: [Help-gnutls] Re: hang in gnutls_bye in gaim
In-Reply-To: <Pine.LNX.4.62.0603160131190.15136@xenon.Stanford.EDU> (Cameron
	Ring's message of "Thu, 16 Mar 2006 01:58:12 -0800 (PST)")
References: <Pine.LNX.4.62.0603160131190.15136@xenon.Stanford.EDU>
Message-ID: <87slph1mj3.fsf@latte.josefsson.org>

Cameron Ring <cameron at CS.Stanford.EDU> writes:

> i'm looking into a problem with gaim 1.5 + gnutls 1.0.25 where
> disconnecting from a jabber server with TLS supprt (wildfire, in this
> case) causes gaim to hang. here's the backtrace of the hung process:

You may want to try a more recent version.

> #0  0x001017a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x001e2451 in recv () from /lib/tls/libc.so.6
> #2  0x00861cdb in _gnutls_read (session=0x9ef4108, iptr=0x9ef65f8, sizeOfPtr=5, flags=0) at gnutls_buffers.c:217
> #3  0x008622d9 in _gnutls_io_read_buffered (session=0x9ef4108, iptr=0xbfe3d0d8, sizeOfPtr=5, recv_type=4294967295) at gnutls_buffers.c:408
> #4  0x0085f887 in _gnutls_recv_int (session=0x9ef4108, type=GNUTLS_ALERT, htype=4294967295, data=0x0, sizeofdata=0) at gnutls_record.c:680
> #5  0x00860783 in gnutls_bye (session=0x9ef4108, how=GNUTLS_SHUT_RDWR) at gnutls_record.c:197
> #6  0x080d8833 in ssl_gnutls_close (gsc=0x9ed84d0) at ssl-gnutls.c:135
> #7  0x080b2fa6 in gaim_ssl_close (gsc=0x9ed84d0) at sslconn.c:183
> #8  0x0811baa8 in jabber_close (gc=0x9ed7c28) at jabber.c:764
> #9  0x0809a35f in gaim_connection_disconnect (gc=0x9ed7c28) at connection.c:254
> #10 0x0809ac06 in gaim_connections_disconnect_all () at connection.c:616
> #11 0x080d8479 in main (argc=5, argv=0xbfe3d434) at main.c:605
>
> i'm not sure whether the problem is on the client side or the server
> (e.g. is the server not replying to our request to close the
> connection?), but i'm hoping for some pointers in the right
> direction.

Etherreal or similar might help.  Or if you control the server, debug
it.

> if, indeed, the server isn't sending a reply, is there a
> way to set a timeout so the client won't wait forever for a reply that
> isnt' coming?
>
> from the application side, i guess i could grab the transport ptr and
> set a timeout on the socket before calling gnutls_bye. does that sound
> reasonable?

I think so. You could also replace the default pull/push functions
with some socket functions that use a timeout.

Regards,
Simon




From marlam at marlam.de  Fri Mar 17 10:31:11 2006
From: marlam at marlam.de (Martin Lambers)
Date: Fri, 17 Mar 2006 10:31:11 +0100
Subject: [Help-gnutls] IDN and TLS certificates
Message-ID: <20060317093110.GA17523@cthulhu.lambers.home>

Hi!

I'm not sure how to handle Internationalized Domain Names when verifying
TLS certificates.

As I understand, a TLS certificate for r?ksm?rg?s.josef?on.example
should contain the value "xn--rksmrgs-5wao1o.josefsson.example" in a
subjectAltName field of type DNS, therefore an application should first
translate "r?ksm?rg?s.josef?on.example" to
"xn--rksmrgs-5wao1o.josefsson.example" before calling
gnutls_x509_crt_check_hostname(). Is this correct?

Regards,
Martin




From nmav at gnutls.org  Fri Mar 17 10:49:19 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 17 Mar 2006 10:49:19 +0100
Subject: [Help-gnutls] hang in gnutls_bye in gaim
In-Reply-To: <c331d99a0603170147j7664c799nf1415131f9ea2b44@mail.gmail.com>
References: <Pine.LNX.4.62.0603160131190.15136@xenon.Stanford.EDU>
	<c331d99a0603170147j7664c799nf1415131f9ea2b44@mail.gmail.com>
Message-ID: <c331d99a0603170149v2eaa845i93d95fe698924dc4@mail.gmail.com>

On 3/16/06, Cameron Ring <cameron at cs.stanford.edu> wrote:

> from the application side, i guess i could grab the transport ptr and set
> a timeout on the socket before calling gnutls_bye. does that sound
> reasonable?

Check Simon's reply. An alternative way would be to use the SHUT_WR
option to gnutls_bye(). That way you don't have to wait for the peer to reply
with a close request.

But in any case you may want to handle timeouts because you may also
get hang in a gnutls_record_recv() call.

regards,
Nikos




From jas at extundo.com  Fri Mar 17 12:25:38 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 17 Mar 2006 12:25:38 +0100
Subject: [Help-gnutls] Re: IDN and TLS certificates
In-Reply-To: <20060317093110.GA17523@cthulhu.lambers.home> (Martin Lambers's
	message of "Fri, 17 Mar 2006 10:31:11 +0100")
References: <20060317093110.GA17523@cthulhu.lambers.home>
Message-ID: <87k6at1ff1.fsf@latte.josefsson.org>

Martin Lambers <marlam at marlam.de> writes:

> Hi!
>
> I'm not sure how to handle Internationalized Domain Names when verifying
> TLS certificates.
>
> As I understand, a TLS certificate for r?ksm?rg?s.josef?on.example
> should contain the value "xn--rksmrgs-5wao1o.josefsson.example" in a
> subjectAltName field of type DNS, therefore an application should first
> translate "r?ksm?rg?s.josef?on.example" to
> "xn--rksmrgs-5wao1o.josefsson.example" before calling
> gnutls_x509_crt_check_hostname(). Is this correct?

Yes.  subjectAltName is a IDN-unaware domain name slot, so it should
contain encoded IDNs, and the hostname parameter to
gnutls_x509_crt_check_hostname is also a IDN-unaware domain name slot.

I'm not sure there is much point in making GnuTLS handle IDN before
PKIX/TLS is IDN-aware.

The ServerName extension in TLS 1.1 is IDN-aware though, and maybe
there is some place for better IDN-handling in GnuTLS there, but I
can't think of any specific improvement.

Regards,
Simon




From oliverlupton at gmail.com  Fri Mar 17 23:39:39 2006
From: oliverlupton at gmail.com (Oliver Lupton)
Date: Fri, 17 Mar 2006 22:39:39 +0000
Subject: [Help-gnutls] 64bit + gnutls_transport_set_ptr
Message-ID: <441B3AAB.20103@gmail.com>

Is there any way I can avoid this compile warning on 64bit systems?

gnutls_transport_set_ptr(session->sess, (gnutls_transport_ptr_t) fd);

Gives me:

m_ssl_gnutls.cpp:260: warning: cast to pointer from integer of different
size

I can see why...it's casting from a 32bit int to a 64bit void*, but is
there any way I can lose the warning without breaking the code? :)

Cheers,

-ol

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20060317/5cbd34f4/attachment.pgp>

From jas at extundo.com  Sat Mar 18 15:54:11 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 18 Mar 2006 15:54:11 +0100
Subject: [Help-gnutls] Re: 64bit + gnutls_transport_set_ptr
In-Reply-To: <441B3AAB.20103@gmail.com> (Oliver Lupton's message of "Fri, 17
	Mar 2006 22:39:39 +0000")
References: <441B3AAB.20103@gmail.com>
Message-ID: <87lkv7u7l8.fsf@latte.josefsson.org>

Oliver Lupton <oliverlupton at gmail.com> writes:

> Is there any way I can avoid this compile warning on 64bit systems?
>
> gnutls_transport_set_ptr(session->sess, (gnutls_transport_ptr_t) fd);
>
> Gives me:
>
> m_ssl_gnutls.cpp:260: warning: cast to pointer from integer of different
> size
>
> I can see why...it's casting from a 32bit int to a 64bit void*, but is
> there any way I can lose the warning without breaking the code? :)

The API do seem wrong here, casting an int to a pointer isn't
generally safe.  It should probably be changed to take a socket
pointer instead, e.g.:

gnutls_transport_set_ptr(session->sess, (gnutls_transport_ptr_t) &fd);

But this break all existing uses.  We could invent a new API and
deprecate this one.  Opinions?  Suggestions for the API name?

If there is some easier solution, i.e, if POSIX or something says that
void* must be able to hold all int values, and there is some
workaround to avoid the warning, maybe we can recommend that instead.
Updating all callers to this function is rather tedious work,
especially if all it solves is to get rid of a warning.

Thanks.




From jas at extundo.com  Tue Mar 21 18:16:05 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 21 Mar 2006 18:16:05 +0100
Subject: [Help-gnutls] Libtasn1 0.3.2
Message-ID: <873bhbzpka.fsf@latte.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by GNU Shishi to handle
Kerberos V5 packets.

Version 0.3.2
- Corrected bug in asn1_der_coding() which overwrited some
  data in the original structure.
- The asn1Parser, asn1Coding and asn1Decoding programs are now installed.

Commercial support contracts for Libtasn1 are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding Libtasn1
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

If you need help to use Libtasn1, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.2MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.3.2.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.2.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.3.2.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.2.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2006-08-14]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2006-08-14]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Note that the software is signed using my sub-key 0xAABB1F7B which is
stored on an OpenPGP smartcard.

Here are the SHA-1 and SHA-224 checksums:

25c228d9a3675b5d763a671d97438009e9a548d3  libtasn1-0.3.2.tar.gz
e1d1e9fe296329789045651a54c64ca7101d0c50  libtasn1-0.3.2.tar.gz.sig
295c8e1d99167b2e67ffd89188e31c373a1f9cee6080ae3adbe2607d  libtasn1-0.3.2.tar.gz
eb346b8fce70b09a90aa9a3949b1baa3149f85fd67a5daa9b5486ee8  libtasn1-0.3.2.tar.gz.sig

Enjoy,
Fabio, Nikos and Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 377 bytes
Desc: not available
URL: </pipermail/attachments/20060321/c8154741/attachment.pgp>

From jas at extundo.com  Tue Mar 21 18:51:35 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 21 Mar 2006 18:51:35 +0100
Subject: [Help-gnutls] GnuTLS 1.4.0 release candidate 1
Message-ID: <87r74vy9co.fsf@latte.josefsson.org>

We expect to release 1.4.0 shortly, and anything you'd like to change
in the software or in the final announcement (which will look much
like the below) should be sent to us within a few days...

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy improvements over the 1.2.x branch:

** Support for TLS Inner application (TLS/IA).  This is per
   draft-funk-tls-inner-application-extension-01, and is compatible
   with the recent -02 version too.

** Support for TLS Pre-Shared Key (TLS-PSK) ciphersuites have been added.

** New APIs to access the TLS Pseudo-Random-Function (PRF) and the
   client and server random fields in a session.  This is primarily
   intended for when GnuTLS is used as a component in other
   authentication protocols, such as the EAP mechanism PEAP and TTLS.

** The session resumption data are now system independent.

** GnuTLS is now easier to port to Windows through mingw32.

** Error messages are now translated using GNU Gettext.

** Documentation improvements, including more discussion of the GnuTLS
   internals.

** New function to set a X.509 private key and certificate pairs,
   and/or CRLs, from an PKCS#12 file.

** Build improvements on many platforms, including 64-bit fixes.

...and the general set of cleanups and improvements.

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

If you need help to use GnuTLS, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/ (updated fastest)

Here are the compressed sources (3.2MB):
  http://josefsson.org/gnutls/releases/gnutls-1.4.0rc1.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.4.0rc1.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.4.0rc1.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.4.0rc1.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2006-08-14]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2006-08-14]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

Note that the software is signed using my sub-key 0xAABB1F7B which is
stored on an OpenPGP smartcard, see <https://www.fsfe.org/en/card>.

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

494a3a8bff64947a61225428e03177a0133859f3  gnutls-1.4.0rc1.tar.bz2
bee5396dac88d48e92d636283ee1ee066eac9866  gnutls-1.4.0rc1.tar.bz2.sig
008c38bb7cf4aa5dc8a0b6f9f56008e396637744ed96acbaa47a1bfb  gnutls-1.4.0rc1.tar.bz2
2769e547938e1a5dee23d988e707505879abd1708803a4ad14179f6e  gnutls-1.4.0rc1.tar.bz2.sig

Enjoy,
Nikos and Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 377 bytes
Desc: not available
URL: </pipermail/attachments/20060321/19b0e9aa/attachment.pgp>