mainGnuTLS - Support: sr #108552, gnutls-dane: verify_ca() function...

 
 

sr #108552: gnutls-dane: verify_ca() function assumes that there are only two certificates

Submitter:  None
Submitted:  Sat 19 Apr 2014 06:49:50 PM UTC
   
 
Category:  Extra library Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 10 May 2014 08:52:23 AM UTC, comment #6: 

Not really. The protocol (rfc5246) specifies:
"This is a sequence (chain) of certificates.  The sender's
certificate MUST come first in the list.  Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to validate it in any case.".

Only the self-signed one may be omitted. Nevertheless, I agree that there are quite some servers that don't follow the protocol.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Mon 28 Apr 2014 07:07:01 PM UTC, comment #5: 

No, a server only needs to send servers up to the CA that you have a certificate for:
Server -> Intermediate CA -> Root CA

The TLSA record could reference the Root CA, and you could have both the Root CA and the Intermediate CA in your store of trusted certificates.

My standard installation of Firefox has both of these as trusted certificates, but the second one is an intermediate of the first one:
AddTrust External CA Root
COMODO High-Assurance Secure Server CA

If most users have both CAs then the server could easily be configured not to send any issuer certificates. Only the DANE-TA type of TLSA record requires the server to provide all of the certificates.

Anonymous
Mon 28 Apr 2014 12:11:42 PM UTC, comment #4: 

There could be, but these will be misconfigured servers. A TLS server has to send up to the last self-signed certificate. If we have code for the compliant to the protocol servers, we can think whether it makes sense to support the non-compliant ones.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Mon 28 Apr 2014 11:38:42 AM UTC, comment #3: 

There may be servers that won't give you the intermediate CA either, so you'll need to follow the chain up until you run out of certificates or find a TLSA match.

For performance it would be best to find as many certificates as possible before starting the TLSA matching [if there is more than one TLSA record].

Anonymous
Mon 28 Apr 2014 09:36:15 AM UTC, comment #2: 

You are correct. My main concern was whether to allow a DANE entry that indicated a CA that is found after a chain of 16 hops is evaluated. I thought that restricting it to the immediate issuer is the most sensible approach.

About the limitation in dane_verify_session_crt() you mention it is indeed present. It could be lifted by using gnutls_certificate_get_issuer() to find the issuer of the last certificate in the chain and append it to the list. I'll try to work on that once I have some time.


Nikos Mavrogiannopoulos <nmav>
Group administrator
Sun 20 Apr 2014 08:33:28 PM UTC, comment #1: 

The implementation (as of 3.2.12) also requires that the server will provide the CA certificate to be matched, which is not how usage 0 is supposed to work. The client is expected to already have (and trust) the CA certificate.

The call to verify_ca() needs to have the full chain, not just the certificate chain provided by the peer. This chain needs to go as far as possible (e.g. there may be a trusted intermediate CA that verification could normally stop at but the DANE record may match the root CA).

Anonymous
Sat 19 Apr 2014 06:49:50 PM UTC, original submission:  

The verify_ca() function in gnutls-dane assumes that there are only two certificates but RFC6698 does not impose this restriction. There may be one or more intermediate certificates between the first certificate and the certificate referenced in the TLSA record (and certificates above the certificate referenced in the TLSA record).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-12-11 nmav StatusConfirmed Done
        Open/ClosedOpen Closed
    2014-04-28 nmav StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code