>>>> 2. I can't see any possible way that matching a single component could >>>> create security holes that would be eliminated by matching multiple >>>> components, but I'm more skeptical about the other direction. What >>>> about the old DNS hack where you create a DNS record for >>>> example.com.sample.com and hijack connections intended for example.com >>>> made by people whose default DNS suffix is sample.com? There may be >>>> reason to believe this isn't a problem, but matching less seems like >>>> it can't possibly be a bad thing. >>> Right, but that's all about being careful not to give out certs like >>> "*.postgres.*". >> >> Errrr...no. The point is that if you've hacked sample.com's DNS >> server, you might have a cert for *.sample.com, but you might NOT have >> a cert for example.com. > > Oh, now I see. Yes, it would break on that. But I don't really see the > problem: > > * If you have a cert for *.sample.com, you trust sample.com > * All you can do is direct traffic *to* sample.com, which is trusted. > > But I guess it could be a potential issue with global CAs, if you just > blindly add them to the trust list.
Well, that's true, in a way, but sample.com isn't a unified entity. The idea of hacks like this is that if sample.com is a large company with a lousy IT department and example.com is, say, a financial web site where people enter their social security and pin number to log in, you can, by hijacking the traffic intended for example.com, and collect personal information. I'm not quite sure how germane this is under SSL because there may be tight enough restrictions on the way that host names are interepreted that it isn't an issue - but things like this were major sources of security holes back in the early nineties when I was last dealing with these sorts of issues. In any case it seems you've chosen to keep this simple for now, which means that it isn't necessary for either of us to understand where the pitfalls might be in some more complex approach. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers