Re: [squid-dev] [PATCH] support custom OIDs in *_cert ACLs
If there is not any objection I will apply this patch to trunk. On 05/26/2015 12:00 PM, Tsantilas Christos wrote: Hi all, This patch allow user_cert and ca_cert ACLs to match arbitrary stand-alone OIDs (not DN/C/O/CN/L/ST objects or their substrings). For example, should be able to match certificates that have 1.3.6.1.4.1.1814.3.1.14 OID in the certificate Subject or Issuer field. Squid configuration would look like this: acl User_Cert-TrustedCustomerNum user_cert 1.3.6.1.4.1.1814.3.1.14 1001 This is a Measurement Factory project ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
[squid-dev] [PATCH] support custom OIDs in *_cert ACLs
Hi all,
This patch allow user_cert and ca_cert ACLs to match arbitrary
stand-alone OIDs (not DN/C/O/CN/L/ST objects or their substrings). For
example, should be able to match certificates that have
1.3.6.1.4.1.1814.3.1.14 OID in the certificate Subject or Issuer field.
Squid configuration would look like this:
acl User_Cert-TrustedCustomerNum user_cert 1.3.6.1.4.1.1814.3.1.14 1001
This is a Measurement Factory project
support custom OIDs in *_cert ACLs
This patch allow user_cert and ca_cert ACLs to match arbitrary stand-alone OIDs
(not DN/C/O/CN/L/ST objects or their substrings). For example, should be able to
match certificates that have 1.3.6.1.4.1.1814.3.1.14 OID in the certificate
Subject or Issuer field. Squid configuration would look like this:
acl User_Cert-TrustedCustomerNum user_cert 1.3.6.1.4.1.1814.3.1.14 1001
This is a Measurement Factory project
=== modified file 'src/acl/CertificateData.cc'
--- src/acl/CertificateData.cc 2015-01-29 19:05:24 +
+++ src/acl/CertificateData.cc 2015-05-26 08:52:46 +
@@ -110,41 +110,62 @@
else {
bool valid = false;
for (std::liststd::string::const_iterator it = validAttributes.begin(); it != validAttributes.end(); ++it) {
if (*it == * || *it == newAttribute) {
valid = true;
break;
}
}
if (!valid) {
debugs(28, DBG_CRITICAL, FATAL: Unknown option. Supported option(s) are: validAttributesStr);
self_destruct();
}
/* an acl must use consistent attributes in all config lines */
if (attribute) {
if (strcasecmp(newAttribute, attribute) != 0) {
debugs(28, DBG_CRITICAL, FATAL: An acl must use consistent attributes in all config lines ( newAttribute != attribute ).);
self_destruct();
}
-} else
+} else {
+if (strcasecmp(newAttribute, DN) != 0) {
+int nid = OBJ_txt2nid(newAttribute);
+if (nid == 0) {
+ const size_t span = strspn(newAttribute, 0123456789.);
+ if(newAttribute[span] == '\0') { // looks like a numerical OID
+ // create a new object based on this attribute
+
+ // NOTE: Not a [bad] leak: If the same attribute
+ // has been added before, the OBJ_txt2nid call
+ // would return a valid nid value.
+ // TODO: call OBJ_cleanup() on reconfigure?
+ nid = OBJ_create(newAttribute, newAttribute, newAttribute);
+ debugs(28, 7, New SSL certificate attribute created with name: newAttribute and nid: nid);
+ }
+}
+if (nid == 0) {
+debugs(28, DBG_CRITICAL, FATAL: Not valid SSL certificate attribute name or numerical OID: newAttribute);
+self_destruct();
+}
+}
attribute = xstrdup(newAttribute);
+}
}
}
values.parse();
}
bool
ACLCertificateData::empty() const
{
return values.empty();
}
ACLDataX509 * *
ACLCertificateData::clone() const
{
/* Splay trees don't clone yet. */
return new ACLCertificateData(*this);
}
=== modified file 'src/cf.data.pre'
--- src/cf.data.pre 2015-05-22 09:42:55 +
+++ src/cf.data.pre 2015-05-26 08:50:23 +
@@ -,45 +,45 @@
acl aclname rep_mime_type [-i] mime-type ...
# regex match against the mime type of the reply received by
# squid. Can be used to detect file download or some
# types HTTP tunneling requests. [fast]
# NOTE: This has no effect in http_access rules. It only has
# effect in rules that affect the reply data stream such as
# http_reply_access.
acl aclname rep_header header-name [-i] any\.regex\.here
# regex match against any of the known reply headers. May be
# thought of as a superset of browser, referer and mime-type
# ACLs [fast]
acl aclname external class_name [arguments...]
# external ACL lookup via a helper class defined by the
# external_acl_type directive [slow]
acl aclname user_cert attribute values...
# match against attributes in a user SSL certificate
- # attribute is one of DN/C/O/CN/L/ST [fast]
+ # attribute is one of DN/C/O/CN/L/ST or a numerical OID [fast]
acl aclname ca_cert attribute values...
# match against attributes a users issuing CA SSL certificate
- # attribute is one of DN/C/O/CN/L/ST [fast]
+ # attribute is one of DN/C/O/CN/L/ST or a numerical OID [fast]
acl aclname ext_user username ...
acl aclname ext_user_regex [-i] pattern ...
# string match on
Re: [squid-dev] [PATCH] support custom OIDs in *_cert ACLs
On 26/05/2015 9:00 p.m., Tsantilas Christos wrote: Hi all, This patch allow user_cert and ca_cert ACLs to match arbitrary stand-alone OIDs (not DN/C/O/CN/L/ST objects or their substrings). For example, should be able to match certificates that have 1.3.6.1.4.1.1814.3.1.14 OID in the certificate Subject or Issuer field. Squid configuration would look like this: acl User_Cert-TrustedCustomerNum user_cert 1.3.6.1.4.1.1814.3.1.14 1001 This is a Measurement Factory project +1 anyway. Dont like the extra leak-ish part though. Does TidyPointer make sense there? Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] support custom OIDs in *_cert ACLs
On 05/26/2015 12:10 PM, Amos Jeffries wrote: On 26/05/2015 9:00 p.m., Tsantilas Christos wrote: Hi all, This patch allow user_cert and ca_cert ACLs to match arbitrary stand-alone OIDs (not DN/C/O/CN/L/ST objects or their substrings). For example, should be able to match certificates that have 1.3.6.1.4.1.1814.3.1.14 OID in the certificate Subject or Issuer field. Squid configuration would look like this: acl User_Cert-TrustedCustomerNum user_cert 1.3.6.1.4.1.1814.3.1.14 1001 This is a Measurement Factory project +1 anyway. Dont like the extra leak-ish part though. Does TidyPointer make sense there? No. It is not a memory leak. The OBJ_create just adds the OID in internal openSSL database of valid fields. Even if the OID is not used after a reconfigure, still remains in this database. This is not a real problem unless someone add some thousands of these OIDs. But I do not believe that this is a real problem... Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [PATCH] support custom OIDs in *_cert ACLs
On 26/05/2015 9:26 p.m., Tsantilas Christos wrote: On 05/26/2015 12:10 PM, Amos Jeffries wrote: On 26/05/2015 9:00 p.m., Tsantilas Christos wrote: Hi all, This patch allow user_cert and ca_cert ACLs to match arbitrary stand-alone OIDs (not DN/C/O/CN/L/ST objects or their substrings). For example, should be able to match certificates that have 1.3.6.1.4.1.1814.3.1.14 OID in the certificate Subject or Issuer field. Squid configuration would look like this: acl User_Cert-TrustedCustomerNum user_cert 1.3.6.1.4.1.1814.3.1.14 1001 This is a Measurement Factory project +1 anyway. Dont like the extra leak-ish part though. Does TidyPointer make sense there? No. It is not a memory leak. The OBJ_create just adds the OID in internal openSSL database of valid fields. Even if the OID is not used after a reconfigure, still remains in this database. This is not a real problem unless someone add some thousands of these OIDs. But I do not believe that this is a real problem... Ah, okay. No problem then. This can go in whenever you wish. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
