mailing list archives
Re: Ncat Wildcard Matching rules
From: David Fifield <david () bamsoftware com>
Date: Wed, 17 Jun 2009 12:03:03 -0600
On Sat, Jun 13, 2009 at 02:35:54PM +0530, venkat sanaka wrote:
I have been working on to add wildcard matching support
for ncat so that it can accept wildcard ssl certificates aswell.
But i have a problem in implementation of matching rules
as there are different RFCs (like RFC 2595,RFC 2818,RFC 4513)
saying different matching rules.
Moreover the browsers and other ssl clients also had their own
wildcard matching rules without following any of the RFCs.
The slide No.5 of this presentation explains these differences
in wildcard matching rules very briefly.
I have two proposals:
1. Don't do any wildcard matching at all, which is what we do now.
2. Follow the most restrictive subset of the rules in the various RFCs.
This means that you only get one *, and it has to be the leftmost
name. So *.example.com is good but *.*.example.com and a.*.com are
not. *.example com would match a.example.com but not a.b.example.com
and not example.com. The RFC 2818 example of f*.com is a mistake. I
think we should add the additional restriction that there have to be
at least two elements to the right of the *, so that * and *.com are
How common are these wildcard certificates in practice? Does anybody run
an SSL site with one of them?
We decided to find out first how common is the usage
of wildcard certifiates and thereby either leaving this completely
or making it a low priority if there aren't many.For this we thought
of having a SSL certificate retrieval NSE script which scans
10,000 SSL web servers and see what they have in their certificates.
An NSE script to retrieve server certificates would be cool, and not
hard technically. That would allow us to get some real numbers.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org