On Sep 5, 2007, at 4:34 PM, Daniel Rall wrote:
> Redirecting to the right place...
>
> Section 4.3.3 seems somewhat relevant, and does seem in line with
> Firefox's behavior, with one possible exception -- if DNS information
> exists for a subdomain, the wildcard is not applied for that
> particular subdomain, or any its subdomains. It's not immediately
> clear to me how this exception could be applied to SSL certs.
> Firefox's behavior seems fairly reasonable to me, if not the norm.
It does not seem to me that the DNS rfc is the key here, but rather
something about security. Sure, DNS supports wildcarding, and sure, a
certificate of this sort explicitly refers to such wildcarding. But
is it secure to grant such wide permissions, that's the question.
Matt has already suggested that there is no loss of security. I'm
responding to this thought. I'm trying to be really really really
careful about this, because I'm rather monumentally prejudiced here
(disclaimer): CollabNet Enterprise Edition is built around DNS
wildcarding, and we have a continuing problem with pretty much all
our sites over this. So I have powerful reflexes to jump and shout
for joy when some browser or other client starts respecting certs
generated for wildcard addresses. But. I want to be sure we're
doing the right thing, not merely the convenient thing, and I think
the CollabNet experience might be about as thorough an exploration of
this as any, and so a worthwhile basis for thought. So, here we go.
First: what is the effect of what I'll call "the current state":
rejecting such certs because the hostnames don't match. How secure
is this? Well, actually very very very not secure, since it
conditions the user to acknowledge any security alert they meet
without reading. Yeah, THAT's behavior worth teaching: ignore
security alerts! Not. ;-( Possibly worse, I do not actually know how
much checking has actually been done in these cases: if my client
tells me "hostname mismatch," is it necessarily also telling me "...
but everything else checks out"? There are, after all, other
considerations, such as whether the mismatching hostname is, at
least, properly certified by known root authorities. For all I know,
some clients are doing all those checks while others aren't. Even if
they all are (or aren't), since I don't know, I can't be an
intelligent consumer of this notifier: once again, we're back to
ignoring security alerts. Bad policy. Bad. Bad.
So when Matt alleges "there's no lost security," I'm strongly
inclined to read that as "there's no security here to be lost"! (Not
sure he meant it quite that strongly, but ... well ... there it is!)
Conversely: if the client agrees to match hostnames by wildcard
rules, where are we? The "all the other checks" question is now
answered: if the client doesn't complain about, say, unknown root
authorities, then they're OK, that's how this stuff is supposed to
work. The question of whether accepting, say, subversion.tigris.org
as a match for *.tigris.org seems a bit trickier. But in the end,
that's clearly what was meant when someone generated that
*.tigris.org key. The worst that can possibly be said is that this
transfers some of the responsibility onto the key-generator person's
shoulders ... but, frankly, those shoulders already bear a great
weight of responsibility, what with securing access to their means of
generation and so on. So trusting the person who's in charge of site
security seems fairly reasonable. And vastly more reasonable than
ignoring security alerts.
So, I don't know whether I'm "convinced" or "justified," but I like it!
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
Received on Thu Sep 6 02:01:37 2007