Project

General

Profile

Feature #991

whitelist: UTF8 certificates not whitelisted

Added by Ulrich Weber over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
11.06.2015
Due date:
Estimated time:
Resolution:
Fixed

Description

Whitelist plugin creates identification_t with printablestrings ASN1. These IDs will get binary hashed.

When clients connect with UTF8 ASN1 (default in openssl and recommended by RFC2459),
compare_dn() will allow the clients (binary compare fails, but printablestrings will be compared with UTF8 and succeeds)
but the whitelist plugin will reject it afterwards (Look will be done in the wrong hash bucket).

Workaround for us is to install all certificates in strongswan as ASN1_UTF8STRING instead of ASN1_PRINTABLESTRING

Associated revisions

Revision 520fba48 (diff)
Added by Tobias Brunner over 5 years ago

identification: Add hash() method

Compared to hashing the encoding we can ignore string types of RDNs when
hashing DNs, making hash() compatible to equals() that does the same.

Fixes #991.

Revision 6fe8fe0c (diff)
Added by Tobias Brunner over 5 years ago

whitelist: Use hash() method so DNs with different string types match

strongSwan uses PrintableString when encoding DNs from strings (if the
character set permits it, otherwise T61String is currently used) but
certificates might be encoded with UTF8String even for simple ASCII strings.
By ignoring this string type when hashing RDNs we make sure the same hash
results in this case as long as the actual string values are the same.

Fixes #991.

History

#1 Updated by Ulrich Weber over 5 years ago

Attached workaround: Switch ASN1_PRINTABLESTRING to ASN1_UTF8STRING

#2 Updated by Tobias Brunner over 5 years ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Feedback

recommended by RFC2459

Actually, RFC 5280 removed that constraint concerning certificates issued after Dec 31, 2003 (see RFC 4630).

Attached workaround: Switch ASN1_PRINTABLESTRING to ASN1_UTF8STRING

Naturally, this will fail with certificates that use ASN1_PRINTABLESTRING (and if the input data is not properly UTF8 encoded already this won't be fixed). I guess it would be better if it was possible to somehow specify how an identity is encoded (also in certificates generated by the pki utility), but that would require better (or any) support for UTF8/Unicode in general.

As a workaround that does not require any code changes you may use the ID prefixes (introduced with 5.2.2) and the raw binary encoding of the subject DNs of the certificates when configuring identities in the whitelist plugin. Just extract the complete binary subject DN then encode it as asn1dn:#<hex encoding>. To extract the DN you could use e.g. openssl asn1parse (find the offset and length + hl of the subject DN) then use e.g. xxd -s <offset> -l <length+hl> -g 0 -c <length+hl> -p to produce a hex string.

#3 Updated by Ulrich Weber over 5 years ago

I added the workaround only as reference, since we have control over all server and clients this works fine for us.

However since openssl generates UTF as default while strongswan generates printablestring as default,
probably everybody trying to use the whitelist plugin will stumble over this and wonder why it doesnt work for them...

The bug is in the whitelist_listener hash function, it should produce a hash ignoring the ASN1 types,
so ASN1_PRINTABLESTRING and ASN1_UTF8STRING certificates with the same DN should generate the same hash id.

#4 Updated by Tobias Brunner over 5 years ago

However since openssl generates UTF as default while strongswan generates printablestring as default,
probably everybody trying to use the whitelist plugin will stumble over this and wonder why it doesnt work for them...

Many strongSwan users probably use pki to generate certs and won't notice anything, just saying :)

But I saw that RDNs with characters outside the PrintableString character set (see X.680, section 41.4) are encoded as ASN1_T61STRING, no idea why not as ASN1_UTF8STRING (today most such strings will be UTF-8 encoded I guess, and T61String is rather exotic). That might be something worth changing besides this issue here.

The bug is in the whitelist_listener hash function, it should produce a hash ignoring the ASN1 types,
so ASN1_PRINTABLESTRING and ASN1_UTF8STRING certificates with the same DN should generate the same hash id.

Yes, that could work. I've implemented a hash() method for identification_t that takes the identity type into account and ignores string types for RDNs (see id-hash branch).

The "proper" (i.e. RFC-compliant) way to compare RDNs would probably be to use the procedure defined in RFC 4518 (with the clarifications from RFC 5280, section 7.1) to derive a normalized string for comparison (the same could be used before hashing).

#5 Updated by Tobias Brunner over 5 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.3.3
  • Resolution set to Fixed

Also available in: Atom PDF