From lfinsto at gwdg.de  Tue Dec  1 13:45:57 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Tue, 1 Dec 2009 13:45:57 +0100 (CET)
Subject: Problems handling X.509 certificates
In-Reply-To: <4B141407.5020109@fifthhorseman.net>
References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de>
	<87r5rlfjy7.fsf@mocca.josefsson.org>
	<4B0E9B3E.9040800@fifthhorseman.net>
	<37863.134.76.5.25.1259596369.squirrel@mailbox.gwdg.de>
	<4B141407.5020109@fifthhorseman.net>
Message-ID: <58449.134.76.5.25.1259671557.squirrel@mailbox.gwdg.de>

Subject:   	Re: Problems handling X.509 certificates
From:   	"Daniel Kahn Gillmor" <dkg at fifthhorseman.net>
Date:   	Mon, November 30, 2009 7:50 pm


> It looks like you should *not* be allocating them yourself (and you
> should not be freeing them either).

You're right, there's no need to allocate memory for it.

> Check out line 127 of lib/gnutls_cert.c to understand how they get set
> by this function.

Thanks.  I think I'm starting to get the hang of it.

Laurence



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

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





From Kunal.Shanishchara at spirent.com  Fri Dec 11 00:55:42 2009
From: Kunal.Shanishchara at spirent.com (Shanishchara, Kunal)
Date: Thu, 10 Dec 2009 18:55:42 -0500
Subject: What makes a certificate invalid?
Message-ID: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>

Hi Everyone,
 
I have this question. 
 
What makes a certificate invalid? 
 
During a TLS handshake, if the Common name parameter does not match
between the client and server, is the handshake suppose to fail? 
 
Thanks in advance.
 
Regards,
Kunal.

<DIV><FONT size="1">

E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk at spirent.com.

Spirent Communications plc,
Northwood Park, Gatwick Road, Crawley,
West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300 

</FONT></DIV>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20091210/675654f1/attachment.htm>

From dkg at fifthhorseman.net  Fri Dec 11 01:49:00 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 10 Dec 2009 19:49:00 -0500
Subject: What makes a certificate invalid?
In-Reply-To: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>
Message-ID: <4B2196FC.3020404@fifthhorseman.net>

Hi Kunal--

On 12/10/2009 06:55 PM, Shanishchara, Kunal wrote:
> What makes a certificate invalid? 

There are many things that could make one side of a TLS connection
consider the other side's certificate invalid.  For example, the
certificate offered by the remote party could:

 0) be expired

 1) be not-yet-valid

 2) be issued by an unknown or untrusted certificate authority

 3) be issued by a known, trusted certificate authority, but during a
time that CA's own certificate was either expired or not-yet-valid.

 4) have no common name or SubjectAltName matching the expected name of
the remote party (e.g. an otherwise-valid certificate for foo.example
would not be valid if you were trying to connect to bar.example)

 5) have the wrong certificate properties for the type of connection
(e.g. a certificate that indicates it is good for use only as a TLS
client would be considered invalid when received from a TLS server)

 6) use a bad digest algorithm in the signature (e.g. if the certificate
was signed over an MD2 digest, most reasonable X.509 implementations
would consider it invalid because it is forgeable)

 7) have a bad signature (e.g. if the signature in the certificate was
originally calculated over the wrong data, or if someone tampered with
the certificate in transit)

 8) have the wrong properties for the parameters of the TLS connection
(e.g. a TLS connection made using RSA for key agreement won't work if
the server's certificate does not have the "Key Encipherment" (i think!)
X509v3 Usage flag set)

 9) simply be malformed

I'm sure someone else can come up with possible ways i've missed that a
certificate could be invalid ;)

> During a TLS handshake, if the Common name parameter does not match
> between the client and server, is the handshake suppose to fail?

If the certificate presented by the other side of the communication
doesn't match who you think you should be talking to, why would you go
on talking to them?  The reason the handshake should fail at that point
is because *no secure communications link has been established*.

You have an encrypted channel to talk to *something*, but you don't know
who is actually on the other end.  For example, it could be an attacker
who turns around and relays your communications to your expected end
party (a so-called "man in the middle" attack).  Then the attacker can
effectively see all the traffic in the clear (snooping!), and can even
make changes to it before relaying to the remote party (tampering!).
This is does not meet the security guarantees that TLS would like to make.

does this answer your question?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091210/59d90231/attachment.pgp>

From lfinsto at gwdg.de  Fri Dec 11 09:25:50 2009
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 11 Dec 2009 09:25:50 +0100 (CET)
Subject: What makes a certificate invalid?
In-Reply-To: <4B2196FC.3020404@fifthhorseman.net>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>
	<4B2196FC.3020404@fifthhorseman.net>
Message-ID: <33103.134.76.5.25.1260519950.squirrel@mailbox.gwdg.de>

From: 	Shanishchara, Kunal
 	What makes a certificate invalid?
Date: 	Thu, 10 Dec 2009 18:55:42 -0500

>> During a TLS handshake, if the Common name parameter does not match
>> between the client and server, is the handshake suppose to fail?

According to my understanding of how it works, the handshake takes place
before certificate verification.  If verification fails, an application
can break off the connection (but doesn't have to).


On Fri, December 11, 2009 1:49 am, Daniel Kahn Gillmor wrote:

> On 12/10/2009 06:55 PM, Shanishchara, Kunal wrote:
>> What makes a certificate invalid?
>
> There are many things that could make one side of a TLS connection
> consider the other side's certificate invalid.  For example, the
> certificate offered by the remote party could:
>

[...]

>
>> During a TLS handshake, if the Common name parameter does not match
>> between the client and server, is the handshake suppose to fail?
>
> If the certificate presented by the other side of the communication
> doesn't match who you think you should be talking to, why would you go
> on talking to them?  The reason the handshake should fail at that point
> is because *no secure communications link has been established*.
>

Verification might fail for any number of reasons, as Daniel describes.
In the application I'm working on, the signer might not be a CA if it's a
proxy certificate.  "Verification failing" means that
`gnutls_x509_crt_verify' sets the `GNUTLS_CERT_INVALID' bit in its
`unsigned int * VERIFY' argument.  Fortunately, it's possible to check the
other bits to find out exactly why verification "failed".  Here's an
example (taken from the manual and adapted slightly):

  gnutls_x509_crt_verify (crt, &issuer, 1, 0, &output);

  if (output & GNUTLS_CERT_INVALID)
    {
      if (output & GNUTLS_CERT_SIGNER_NOT_FOUND)
      {
        fprintf (stderr, "Not trusted");
        fprintf (stderr, ": no issuer was found");
      }

      if (output & GNUTLS_CERT_SIGNER_NOT_CA)
      {
        fprintf (stderr, "Trusted");
        fprintf (stderr, ": issuer is not a CA\n");
        fprintf (stderr, "This isn't so important, the previous
certificate might be a proxy.");
      }
      fprintf (stderr, "\n");
    }
  else
    fprintf (stderr, "Trusted\n");


In my application, I'm not sure that I want to require that the server
"know" the owner of the client's certificate.  Nor am I sure whether
`gnutls_x509_crt_verify' tests this --- I'd have to check.  I think it
should suffice that the certificate is valid and the CA is trusted,
however I haven't thought this through completely.

At any rate, `gnutls_x509_crt_verify' doesn't `abort' or `exit' if it
"fails", so the application can decide how to proceed itself, so to speak.


Laurence


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

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





From dkg at fifthhorseman.net  Fri Dec 11 17:23:03 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Dec 2009 11:23:03 -0500
Subject: What makes a certificate invalid?
In-Reply-To: <4B2196FC.3020404@fifthhorseman.net>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>
	<4B2196FC.3020404@fifthhorseman.net>
Message-ID: <4B2271E7.6030805@fifthhorseman.net>

On 12/10/2009 07:49 PM, Daniel Kahn Gillmor wrote:
> I'm sure someone else can come up with possible ways i've missed that a
> certificate could be invalid ;)

i thought of another way this morning:

10) if the certificate contains an X.509v3 extension that is marked
"critical" that it does not know how to process, it MUST reject the
certificate:

  http://tools.ietf.org/html/rfc5280#section-4.2.1.10

hth,

	--dkg

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

From rks at mur.at  Fri Dec 11 17:52:44 2009
From: rks at mur.at (Rupert Kittinger-Sereinig)
Date: Fri, 11 Dec 2009 17:52:44 +0100
Subject: What makes a certificate invalid?
In-Reply-To: <4B2196FC.3020404@fifthhorseman.net>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>
	<4B2196FC.3020404@fifthhorseman.net>
Message-ID: <4B2278DC.3090503@mur.at>

last but not least:

10) the certificate is on a revocation list

cheers,
Rupert

Daniel Kahn Gillmor schrieb:
> Hi Kunal--
> 
> On 12/10/2009 06:55 PM, Shanishchara, Kunal wrote:
>> What makes a certificate invalid? 
> 
> There are many things that could make one side of a TLS connection
> consider the other side's certificate invalid.  For example, the
> certificate offered by the remote party could:
> 
>  0) be expired
> 
>  1) be not-yet-valid
> 
>  2) be issued by an unknown or untrusted certificate authority
> 
>  3) be issued by a known, trusted certificate authority, but during a
> time that CA's own certificate was either expired or not-yet-valid.
> 
>  4) have no common name or SubjectAltName matching the expected name of
> the remote party (e.g. an otherwise-valid certificate for foo.example
> would not be valid if you were trying to connect to bar.example)
> 
>  5) have the wrong certificate properties for the type of connection
> (e.g. a certificate that indicates it is good for use only as a TLS
> client would be considered invalid when received from a TLS server)
> 
>  6) use a bad digest algorithm in the signature (e.g. if the certificate
> was signed over an MD2 digest, most reasonable X.509 implementations
> would consider it invalid because it is forgeable)
> 
>  7) have a bad signature (e.g. if the signature in the certificate was
> originally calculated over the wrong data, or if someone tampered with
> the certificate in transit)
> 
>  8) have the wrong properties for the parameters of the TLS connection
> (e.g. a TLS connection made using RSA for key agreement won't work if
> the server's certificate does not have the "Key Encipherment" (i think!)
> X509v3 Usage flag set)
> 
>  9) simply be malformed
> 
> I'm sure someone else can come up with possible ways i've missed that a
> certificate could be invalid ;)
> 
>> During a TLS handshake, if the Common name parameter does not match
>> between the client and server, is the handshake suppose to fail?
> 
> If the certificate presented by the other side of the communication
> doesn't match who you think you should be talking to, why would you go
> on talking to them?  The reason the handshake should fail at that point
> is because *no secure communications link has been established*.
> 
> You have an encrypted channel to talk to *something*, but you don't know
> who is actually on the other end.  For example, it could be an attacker
> who turns around and relays your communications to your expected end
> party (a so-called "man in the middle" attack).  Then the attacker can
> effectively see all the traffic in the clear (snooping!), and can even
> make changes to it before relaying to the remote party (tampering!).
> This is does not meet the security guarantees that TLS would like to make.
> 
> does this answer your question?
> 
> 	--dkg
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls


-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria





From Kunal.Shanishchara at spirent.com  Fri Dec 11 17:54:10 2009
From: Kunal.Shanishchara at spirent.com (Shanishchara, Kunal)
Date: Fri, 11 Dec 2009 11:54:10 -0500
Subject: What makes a certificate invalid?
In-Reply-To: <4B2271E7.6030805@fifthhorseman.net>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>
	<4B2196FC.3020404@fifthhorseman.net>
	<4B2271E7.6030805@fifthhorseman.net>
Message-ID: <FBF587DAE825034EB0AA9E586C1522ED0229B591@SPCEATEXC01.AD.SPIRENTCOM.COM>

Hi Daniel,

Thank you for the detailed answers (previous email) and pointing to the
link. These are very helpful. 

I must admit though that I am still unable to comprehend the right
behavior for the particular scenario that I have in mind.

I am going to describe it to the best of my ability. Please find the
description below.



Problem Description:

I have generated my own root certificate, lets say xyz.cer. I use this
root certificate to generate certificates for 2 different FQDNs, lets
say abc.com and def.org. 

Now, I am trying to induce an authentication failure by doing the
following.

1. The server sends the certificate generated for def.org and the client
sends a certificate for abc.com. Both these certificates were generated
using same X.509  certificate xyz.cer.
2. The server expects the client to fail the TLS authentication during
server hello, client hello messaging.
3. Based on the authentication failure, client will fallback to def.org
(as per the higher layer specification) and the successive attempt will
go through.



Questions:

Is the Server correct in expecting an authentication failure in Step 2?

If no, apart from providing invalid certificate with some obvious cause
(expired cert, etc..) is there another way to implement the
functionality on the server?

Thanks in advance. 

Thanks and regards,
Kunal.



-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: Friday, December 11, 2009 11:23 AM
To: help-gnutls at gnu.org
Cc: Shanishchara, Kunal
Subject: Re: What makes a certificate invalid?

On 12/10/2009 07:49 PM, Daniel Kahn Gillmor wrote:
> I'm sure someone else can come up with possible ways i've missed that 
> a certificate could be invalid ;)

i thought of another way this morning:

10) if the certificate contains an X.509v3 extension that is marked
"critical" that it does not know how to process, it MUST reject the
certificate:

  http://tools.ietf.org/html/rfc5280#section-4.2.1.10

hth,

	--dkg


<DIV><FONT size="1">

E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk at spirent.com.

Spirent Communications plc,
Northwood Park, Gatwick Road, Crawley,
West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300 

</FONT></DIV>




From dkg at fifthhorseman.net  Fri Dec 11 18:50:54 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 11 Dec 2009 12:50:54 -0500
Subject: What makes a certificate invalid?
In-Reply-To: <4B2278DC.3090503@mur.at>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>	<4B2196FC.3020404@fifthhorseman.net>
	<4B2278DC.3090503@mur.at>
Message-ID: <4B22867E.7040304@fifthhorseman.net>

On 12/11/2009 11:52 AM, Rupert Kittinger-Sereinig wrote:
> last but not least:
> 
> 10) the certificate is on a revocation list

right, thanks! and then there's:

12) is invalidated by OCSP

though i don't know if gnutls actively checks OCSP or CRLs at the
moment.  Does it?


	--dkg

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

From Kunal.Shanishchara at spirent.com  Fri Dec 11 22:01:32 2009
From: Kunal.Shanishchara at spirent.com (Shanishchara, Kunal)
Date: Fri, 11 Dec 2009 16:01:32 -0500
Subject: What makes a certificate invalid?
In-Reply-To: <4B22B26A.3040502@mur.at>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>	<4B2196FC.3020404@fifthhorseman.net>	<4B2271E7.6030805@fifthhorseman.net>
	<FBF587DAE825034EB0AA9E586C1522ED0229B591@SPCEATEXC01.AD.SPIRENTCOM.COM>
	<4B22B26A.3040502@mur.at>
Message-ID: <FBF587DAE825034EB0AA9E586C1522ED0229B691@SPCEATEXC01.AD.SPIRENTCOM.COM>

Thanks for your query Rupert.

The problem we are trying to solve is to test the behavior when a
failure happens. Sorry for not making this clear in my earlier email. 

Regards,
Kunal.

 

-----Original Message-----
From: Rupert Kittinger-Sereinig [mailto:rks at mur.at] 
Sent: Friday, December 11, 2009 3:58 PM
To: Shanishchara, Kunal
Subject: Re: What makes a certificate invalid?


I do not understand the problem you want to solve. Why do you want the
handshake to fail?

If you want to use this as a way for the client to choose between
several certificates, I do not think this is necessary. The client
certificate request already includes a list of Distinguished Names that
are acceptable Certificate Authorities.

cheers,
Rupert


Shanishchara, Kunal schrieb:
> Hi Daniel,
> 
> Thank you for the detailed answers (previous email) and pointing to 
> the link. These are very helpful.
> 
> I must admit though that I am still unable to comprehend the right 
> behavior for the particular scenario that I have in mind.
> 
> I am going to describe it to the best of my ability. Please find the 
> description below.
> 
> 
> 
> Problem Description:
> 
> I have generated my own root certificate, lets say xyz.cer. I use this

> root certificate to generate certificates for 2 different FQDNs, lets 
> say abc.com and def.org.
> 
> Now, I am trying to induce an authentication failure by doing the 
> following.
> 
> 1. The server sends the certificate generated for def.org and the 
> client sends a certificate for abc.com. Both these certificates were 
> generated using same X.509  certificate xyz.cer.
> 2. The server expects the client to fail the TLS authentication during

> server hello, client hello messaging.
> 3. Based on the authentication failure, client will fallback to 
> def.org (as per the higher layer specification) and the successive 
> attempt will go through.
> 
> 
> 
> Questions:
> 
> Is the Server correct in expecting an authentication failure in Step
2?
> 
> If no, apart from providing invalid certificate with some obvious 
> cause (expired cert, etc..) is there another way to implement the 
> functionality on the server?
> 
> Thanks in advance. 
> 
> Thanks and regards,
> Kunal.
> 
> 
>
--
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria


<DIV><FONT size="1">

E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk at spirent.com.

Spirent Communications plc,
Northwood Park, Gatwick Road, Crawley,
West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300 

</FONT></DIV>




From rks at mur.at  Fri Dec 11 23:40:20 2009
From: rks at mur.at (Rupert Kittinger-Sereinig)
Date: Fri, 11 Dec 2009 23:40:20 +0100
Subject: What makes a certificate invalid?
In-Reply-To: <FBF587DAE825034EB0AA9E586C1522ED0229B691@SPCEATEXC01.AD.SPIRENTCOM.COM>
References: <FBF587DAE825034EB0AA9E586C1522ED0229B43B@SPCEATEXC01.AD.SPIRENTCOM.COM>	<4B2196FC.3020404@fifthhorseman.net>	<4B2271E7.6030805@fifthhorseman.net>
	<FBF587DAE825034EB0AA9E586C1522ED0229B591@SPCEATEXC01.AD.SPIRENTCOM.COM>
	<4B22B26A.3040502@mur.at>
	<FBF587DAE825034EB0AA9E586C1522ED0229B691@SPCEATEXC01.AD.SPIRENTCOM.COM>
Message-ID: <4B22CA54.4050705@mur.at>

Ok, I see.

Maybe it is easiest to modify the source of the peer of the system under 
test to get the responses you expect?

Rupert


Shanishchara, Kunal schrieb:
> Thanks for your query Rupert.
> 
> The problem we are trying to solve is to test the behavior when a
> failure happens. Sorry for not making this clear in my earlier email. 
> 
> Regards,
> Kunal.
> 
>  
> 
> -----Original Message-----
> From: Rupert Kittinger-Sereinig [mailto:rks at mur.at] 
> Sent: Friday, December 11, 2009 3:58 PM
> To: Shanishchara, Kunal
> Subject: Re: What makes a certificate invalid?
> 
> 
> I do not understand the problem you want to solve. Why do you want the
> handshake to fail?
> 
> If you want to use this as a way for the client to choose between
> several certificates, I do not think this is necessary. The client
> certificate request already includes a list of Distinguished Names that
> are acceptable Certificate Authorities.
> 
> cheers,
> Rupert
> 
> 
> Shanishchara, Kunal schrieb:
>> Hi Daniel,
>>
>> Thank you for the detailed answers (previous email) and pointing to 
>> the link. These are very helpful.
>>
>> I must admit though that I am still unable to comprehend the right 
>> behavior for the particular scenario that I have in mind.
>>
>> I am going to describe it to the best of my ability. Please find the 
>> description below.
>>
>>
>>
>> Problem Description:
>>
>> I have generated my own root certificate, lets say xyz.cer. I use this
> 
>> root certificate to generate certificates for 2 different FQDNs, lets 
>> say abc.com and def.org.
>>
>> Now, I am trying to induce an authentication failure by doing the 
>> following.
>>
>> 1. The server sends the certificate generated for def.org and the 
>> client sends a certificate for abc.com. Both these certificates were 
>> generated using same X.509  certificate xyz.cer.
>> 2. The server expects the client to fail the TLS authentication during
> 
>> server hello, client hello messaging.
>> 3. Based on the authentication failure, client will fallback to 
>> def.org (as per the higher layer specification) and the successive 
>> attempt will go through.
>>
>>
>>
>> Questions:
>>
>> Is the Server correct in expecting an authentication failure in Step
> 2?
>> If no, apart from providing invalid certificate with some obvious 
>> cause (expired cert, etc..) is there another way to implement the 
>> functionality on the server?
>>
>> Thanks in advance. 
>>
>> Thanks and regards,
>> Kunal.
>>
>>
>>
> --
> Rupert Kittinger-Sereinig <rks at mur.at>
> Krenngasse 32
> A-8010 Graz
> Austria
> 
> 
> <DIV><FONT size="1">
> 
> E-mail confidentiality.
> --------------------------------
> This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system. If you require assistance, please contact our IT department at helpdesk at spirent.com.
> 
> Spirent Communications plc,
> Northwood Park, Gatwick Road, Crawley,
> West Sussex, RH10 9XN, United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
> 
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> 
> Or if within the US,
> 
> Spirent Communications,
> 26750 Agoura Road, Calabasas, CA, 91302, USA.
> Tel No. 1-818-676- 2300 
> 
> </FONT></DIV>


-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria





From addarathbone at googlemail.com  Sun Dec 13 22:59:33 2009
From: addarathbone at googlemail.com (Adda Rathbone)
Date: Sun, 13 Dec 2009 22:59:33 +0100
Subject: kx srp vs dhe
Message-ID: <20091213215933.GA21728@debbie>

Hello, 
I am writing a server using gnutls. The main idea was that a user
connects with a password. For that reason I want to use the SRP
authentication and as fallback the normal x509 authentication.

However if I use the gnutls_certificate_set_dh_params()
function in my server program, my srp client won't use the SRP kx
anymore (now it uses DHE-RSA).
Is there a reason for this behaviour?

I thought SRP would behave like PSK (PSK is not affected). 
Does this mean SRP kx is not as secure as DHE kx?


Thank you
Adda Rathbone

PS: 
client prio. settings: "SECURE256:+SRP"
server prio. settings: "SECURE256:+SRP:+SRP-DSS:+SRP-RSA"




From mrsam at courier-mta.com  Wed Dec 16 01:29:53 2009
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Tue, 15 Dec 2009 19:29:53 -0500
Subject: Concurrent gnutls_record_send and gnutls_record_recv
Message-ID: <cone.1260923393.103046.10841.500@commodore.email-scan.com>

I want my application to be able to read/write from a TLS session 
concurrently, which requires non-blocking socket transport, and I am trying 
to figure out how to use the API correctly. I see that the documentation 
indicates the gnutls is thread safe; but does that mean that one thread can 
be using gnutls_record_send() while another thread be using 
gnutls_record_recv() at the same time? That's one approach that I am 
considering. If not, and I have to multiplex a single thread between reading 
and writing, I am trying to figure out how to use the API correctly. So far, 
I have:

* If there's something waiting to be written, call gnutls_record_send. If 
gnutls_record_send returned GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, call 
gnutls_record_get_direction(), and note its return value. If 
gnutls_record_send wrote something, and there's more left to write, take it 
from the top.

* Call gnutls_record_recv. If something was read, process the read data, and 
take it from the top again. If gnutls_record_recv came back with 
GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, call gnutls_record_get_direction(), 
combine its return value with the return value after gnutls_record_send() 
(if applicable), computing the corresponding combination of POLLIN and 
POLLOUT, then call poll() to wait for the required I/O state.

Also, in an established TLS session, after the handshake completes, if 
gnutls_record_recv() or gnutls_record_send() returns GNUTLS_E_INTERRUPTED or 
GNUTLS_E_AGAIN, will gnutls_record_get_direction() always return 0 after 
gnutls_record_recv and 1 after gnutls_record_send(), or are there situations 
where gnutls_record_recv() would need to write to the underlying transport, 
and gnutls_record_send() would need to read from the underlying transport, 
and how would that be squared away with the application's simultaneous usage 
of gnutls_record_send() and gnutls_record_recv()? If, say, after 
gnutls_record_recv() returns GNUTLS_E_AGAIN or GNUTLS_E_INTERRUPTED, and 
gnutls_record_get_direction returns 1 (indicating write I/O is required), 
must I subsequently call gnutls_record_recv() again, after I/O is available, 
and calling gnutls gnutls_record_send() (as my I/O loop does) would mess 
things up?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20091215/9c1300cc/attachment.pgp>

From rvandolson at esri.com  Thu Dec 17 03:11:22 2009
From: rvandolson at esri.com (Ray Van Dolson)
Date: Wed, 16 Dec 2009 18:11:22 -0800
Subject: GnuTLS error -73: ASN1 parser: Error in TAG.
Message-ID: <20091217021122.GA2600@esri.com>

I'm getting this from multiple FTP clients that rely on GnuTLS when
connecting to an FTP site using explicit TLS (STARTTLS / AUTH TLS).

I suspect this is an issue with the certificate the site uses, but
would like to confirm and also learn a bit about how to troubleshoot
this sort of thing.

I tried to use gnutls-cli:

  $ gnutls-cli -V --insecure --print-cert -s -p 21 ftp.pp.xw.gm.com
  Resolving 'ftp.pp.xw.gm.com'...
  Connecting to '198.208.1.30:21'...

  - Simple Client Mode:

  - Received[51]: 220 usplgmxfs001 FTP server (TLSFTP 1.4.2) ready.
  AUTH TLS
  - Sent: 9 bytes
  - Received[18]: 234 AUTH TLS OK.
  *** Starting TLS handshake
  *** Fatal error: ASN1 parser: Error in TAG.
  *** Handshake has failed

However it doesn't really give me any specific errors here and I'm not
sure how to force it to dump the certificate in this scenario.  tcpdump
shows me that the cert _is_ being transferred, but, I guess since it's
invalid, gnutls-cli doesn't proceed any further with output.

I got a bit more info out of openssl s_client:

  $ openssl s_client -connect ftp.pp.xw.gm.com:21 -starttls ftp
  CONNECTED(00000003)
  468:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1316:
  468:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:828:
  468:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:748:Field=value, Type=X509_EXTENSION
  468:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:709:
  468:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error:tasn_dec.c:578:Field=extensions, Type=X509_CINF
  468:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:748:Field=cert_info, Type=X509
  468:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1 lib:s3_clnt.c:972:

So it looks like a few of the listed fields are invalid.. but, again, I
don't know how to actually dump a copy of the cert so I can look at it
more closely.

Anyone have any pointers?  Maybe someone wants to try to connect to the
site above and tell me exactly how this cert is invalid. :)

Thanks,
Ray




From nmav at gnutls.org  Fri Dec 18 10:58:11 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2009 11:58:11 +0200
Subject: kx srp vs dhe
In-Reply-To: <20091213215933.GA21728@debbie>
References: <20091213215933.GA21728@debbie>
Message-ID: <4B2B5233.3040505@gnutls.org>

Adda Rathbone wrote:
> Hello, 
> I am writing a server using gnutls. The main idea was that a user
> connects with a password. For that reason I want to use the SRP
> authentication and as fallback the normal x509 authentication.
> 
> However if I use the gnutls_certificate_set_dh_params()
> function in my server program, my srp client won't use the SRP kx
> anymore (now it uses DHE-RSA).
> Is there a reason for this behaviour?
> 
> I thought SRP would behave like PSK (PSK is not affected). 
> Does this mean SRP kx is not as secure as DHE kx?
> PS:
> client prio. settings: "SECURE256:+SRP"
> server prio. settings: "SECURE256:+SRP:+SRP-DSS:+SRP-RSA"

This only has to do with priorities. By using
gnutls_certificate_set_dh_params() you effectively enable the DHE
ciphersuites that happen to take precedence to the SRP ones (that is
what your priority string shows).

regards,
Nikos




From nmav at gnutls.org  Fri Dec 18 11:06:51 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2009 12:06:51 +0200
Subject: Concurrent gnutls_record_send and gnutls_record_recv
In-Reply-To: <cone.1260923393.103046.10841.500@commodore.email-scan.com>
References: <cone.1260923393.103046.10841.500@commodore.email-scan.com>
Message-ID: <4B2B543B.4030000@gnutls.org>

Sam Varshavchik wrote:
> I want my application to be able to read/write from a TLS session
> concurrently, which requires non-blocking socket transport, and I am
> trying to figure out how to use the API correctly. I see that the
> documentation indicates the gnutls is thread safe; but does that mean
> that one thread can be using gnutls_record_send() while another thread
> be using gnutls_record_recv() at the same time? 

Yes this can be done in a thread safe way without locks. Even fork and
read/write from different processes works. The only issue is on
gnutls_bye(). To terminate the session properly you should call with
SHUT_WR and start reading until EOF (0) is received.

> That's one approach that
> I am considering. If not, and I have to multiplex a single thread
> between reading and writing, I am trying to figure out how to use the
> API correctly. So far, I have:
> 
> * If there's something waiting to be written, call gnutls_record_send.
> If gnutls_record_send returned GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN,
> call gnutls_record_get_direction(), and note its return value. If
> gnutls_record_send wrote something, and there's more left to write, take
> it from the top.
> 
> * Call gnutls_record_recv. If something was read, process the read data,
> and take it from the top again. If gnutls_record_recv came back with
> GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, call
> gnutls_record_get_direction(), combine its return value with the return
> value after gnutls_record_send() (if applicable), computing the
> corresponding combination of POLLIN and POLLOUT, then call poll() to
> wait for the required I/O state.
> 
> Also, in an established TLS session, after the handshake completes, if
> gnutls_record_recv() or gnutls_record_send() returns
> GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, will
> gnutls_record_get_direction() always return 0 after gnutls_record_recv
> and 1 after gnutls_record_send(), or are there situations where
> gnutls_record_recv() would need to write to the underlying transport,
> and gnutls_record_send() would need to read from the underlying
> transport, and how would that be squared away with the application's
> simultaneous usage of gnutls_record_send() and gnutls_record_recv()?

No there is no such case. They behave exactly like recv() and send().


best regards,
Nikos




From nmav at gnutls.org  Fri Dec 18 11:10:17 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2009 12:10:17 +0200
Subject: GnuTLS error -73: ASN1 parser: Error in TAG.
In-Reply-To: <20091217021122.GA2600@esri.com>
References: <20091217021122.GA2600@esri.com>
Message-ID: <4B2B5509.1050703@gnutls.org>

Ray Van Dolson wrote:
> I'm getting this from multiple FTP clients that rely on GnuTLS when
> connecting to an FTP site using explicit TLS (STARTTLS / AUTH TLS).
> 
> I suspect this is an issue with the certificate the site uses, but
> would like to confirm and also learn a bit about how to troubleshoot
> this sort of thing.

It seems to be an encoding error in the certificate.

> I tried to use gnutls-cli:
> 
>   $ gnutls-cli -V --insecure --print-cert -s -p 21 ftp.pp.xw.gm.com
>   Resolving 'ftp.pp.xw.gm.com'...
>   Connecting to '198.208.1.30:21'...
> 
>   - Simple Client Mode:
> 
>   - Received[51]: 220 usplgmxfs001 FTP server (TLSFTP 1.4.2) ready.
>   AUTH TLS
>   - Sent: 9 bytes
>   - Received[18]: 234 AUTH TLS OK.
>   *** Starting TLS handshake
>   *** Fatal error: ASN1 parser: Error in TAG.
>   *** Handshake has failed
> 
> However it doesn't really give me any specific errors here and I'm not
> sure how to force it to dump the certificate in this scenario.  tcpdump
> shows me that the cert _is_ being transferred, but, I guess since it's
> invalid, gnutls-cli doesn't proceed any further with output.

Indeed. The handshake procedure tries to parse the certificate to
retrieve parameters and fails thus handshake is not completed in order
to return the certificate.

> So it looks like a few of the listed fields are invalid.. but, again, I
> don't know how to actually dump a copy of the cert so I can look at it
> more closely.

Maybe you could extract the certificate with wireshark.


regards,
Nikos




From ilari.liusvaara at elisanet.fi  Wed Dec 30 23:50:06 2009
From: ilari.liusvaara at elisanet.fi (Ilari Liusvaara)
Date: Thu, 31 Dec 2009 00:50:06 +0200
Subject: gnutls_openpgp_crt_verify_self and key fingerprint
Message-ID: <20091230225005.GA17876@Knoppix>

I'm writing new protocol implementation that utilizes TLS-OpenPGP
and GnuTLS and I am not completely sure what I'm doing with
authentication is safe thing to do:

Does gnutls_openpgp_crt_verify_self() verify OpenPGP certificate
throughly enough that the gnutls_openpgp_crt_get_fingerprint()
output can be trusted not to be forgeable by grabbing certificate
(without stealing/deriving corresponding private keys) with desired 
fingerprint and tampering with it?

The scenario I'm most worried about is attacker using unauthorized
subkey (missing/invalid main->subkey signature) to pass TLS signature
checks. If that is not caught, the fingerprint value will be
completely untrustworthy (since AFAIK fingerprint comes from the
main key and does not directly cover subkeys). I'm guessing whole
purpose of ...verify_self() is to catch trickery like that (if not,
what it is for?)

I have tried to search for information wheither what I'm doing
is safe or not, but I haven't come up with information either
way. And looking at documentation and OpenPGP RFCs was not
very helpful.

And no, gnutls_openpgp_crt_verify_ring() is effectively not an
option (I don't go into details why here).

-Ilari