Hi Jack,
Jack Repenning wrote:
> 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!
>
>
I'm not sure I understood all your thoughts, but heres my logic:
I understand the issues with DNS wildcarding, about how that can cause
problems with DNS, but I think the situation is very different for SSL
certificates because any certificate can be generated and used for a
connection from the IP/server resolved, irrespective of any other
domains, as it only accesses the IP provided, and it's up to the client
side rules to check the age, issuer, etc and also the common name (CN)
of the certificate to make sure it matches the domain accessed.
When I mean there is "no lost security" I meant that the holder of the
main domain domain.com has complete control of all delegation to other
subdomains and anyone that trusts domain.com, implicitly trusts
xxx.domain.com and hence yyy.xxx.domain.com, because they are all
controlled and decided by the holder of domain.com, and so forth into
subdomains.
It is widely accepted that *.domain.com means xxx.domain.com, but not so
clear that this also means yyy.xxx.domain.com, but in my view, this is
the same as it follows DNS delegation in both instances (of the
implied/inherent trust that is dictated by DNS).
Looking at the issue from another angle, the person who has access to
the server(s) at yyy.xxx.domain.com could place a certificate with a CN
of yyy.xxx.domain.com on the server, and hence the client would
completely accept the certificate since it fully matches the domain.
Alternatively, the person could place a certificate *.xxx.domain.com on
the same server, and again be completely accepted by all clients as this
is also widely accepted. However, if the person decides to place a
certificate *.domain.com on that same server, then the client would
receive a warning in the current implementations of subversion, which to
me is quite strange, and should not occur, since following this logic,
the person clearly intended this to be accepted.
So, as my logic follows, in my view, it would be much more efficient to
allow *.domain.com to apply to all levels because it would not change
any level of security at all (of a specific domain, due to the implied
delegated trust), and would motivate more people to use SSL certificates
in the first place (so increasing the number of SSL sites and the
security of websites in general) as they wouldn't need to buy as many,
bettering the entire Internet/world.
Best regards,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 6 23:32:44 2007