Making Sense of Mismatched Certificates? 322
Ropati writes "I bank with capitalone.com. Recently I went to log in to my credit card account, and my browser reported that the site certificate didn't match the web site I was on. [Expletive.] I'm wondering if I am getting a poisoned DNS URL. I have to log in and do my banking, so I accept the mismatched certificate. The banking site is complete, my transactions are listed but that doesn't mean there isn't a man in the middle attack here. I am still curious how much I have exposed my banking assets." Read on for more, and offer advice on how to interpret what sounds like a flaky response from the bank.
Ropati continues "On the Capital One login page, there is a Verisign link on the page to check that the website is suppose to match. So I click on the verification icon and I am rewarded with a link to Verisign. They report that this web site certificate is for onlinebanking.capitalone.com not the servicing.capitalone.com where I log in. Is this the mismatch my browser reported. I know nothing about certificates.
I call Capital One and ask them to fix the problem. If this was a browser issue on my part, then the Verisign link should match. The tech support supervisor, Joe — XRT413, said he couldn't do anything about it and he couldn't escalate the problem to someone who could.
So my questions are: Are the certificates a mismatch or is my browser bellyaching for nothing? Is the certificate mismatch a security hazard? If someone poisoned my local DNS routers would it be obvious in the URL? How would I prevent such a thing? If everything was working correctly, would the certificate alert me to DNS poisoning, or is this just cosmetic security?"
A few things about SSL (Score:5, Interesting)
The first thing to note is that SSL covers the host-to-host connection and is ignorant of higher-level protocols. There are a couple of things which can cause SSL mismatches:
1) SSL cert is set up to one hostname that the machine services, but site is on another. The SSL negotiation happens prior to the host headers being processed. This could be solved by browser controls (i.e. do a rDNS lookup on the cert's host and make sure it matches the IP you are connecting to), but this ends up causing other, more serious issues, because different sites on the same server could be controlled by different parties. Hence if you have a shopping cart, I could re-use your cert on my shared site on the same box, spoof your page, and steel credit card numbers. So the browser behavior is correct.
2) The SSL cert could have been accidently re-used (unlikely).
My general rule is that if the hostname's TLD matches with the cert (capitalone.com), but the most host-specific portion does not (servicing vs online banking), this is reasonably (though not completely) safe to ignore. Revoked certs should ALWAYS be treated with suspicion because you don't know why it was revoked. Expired certs.... Well, it depends. There are other things that can cause certs to be improperly shown as expired so that demands more careful consideration.
Re:Looks fine to me (Score:5, Interesting)
Exactly. They were stupid. They gave a server an alias, and didn't realize that it will throw an error to the clients. It probably worked fine in their dev environment though, where they probably accepted the wrong cert and saved the exception because they got tired of clicking the link. :)
Being that he ignored the error, didn't view the cert to see what it was really assigned for (and continued on to give his login information), it proves that most users don't really care, and will provide their security credentials regardless if they've been warned that there is a problem or not. The cert could have been for bad_haxor_inc.ru, but since he didn't look, he doesn't know.
We have to assume that it's a mixup with the servicing.capitalone.com and onlinebanking.capitalone.com hosts, but we don't know.
Why didn't they just buy a wildcard cert? They're so much easier to work with. :)
Re:Not nothing. (Score:3, Interesting)
This will become a greater issue as unicode domain names come into prominence. I believe that right now while Firefox "decodes" any unicode so that the characters look like the underlying hex (or something) so that a non-english character can NOT be confused for a real one.
For instance in certain fonts lowercase "L" (l) looks EXACTLY like an uppercase "i" (I). In others it doesn't. Now in your example that can't happen, but what about www.travelocity.com or www.traveIocity.com? (I used a capital "i" in the second) You can see how this can be an issue. It gets worse with other character sets that ARE different characters, but again look identical, thus bypassing any automatic "lowercase" that a browser probably does.
If you see a mismatch, unless the banking needs to be done in less time than it takes you to get to an actual local branch, do NOT do it.
Browser issue (Score:4, Interesting)
Banks? Seriously? (Score:5, Interesting)
I don't really understand why any individual with regular "banking" needs would use a bank today. Credit unions are non-profit, and generally, because of their structure, are run much better than banks are. My credit union has been impacted 0% by this banking mess stuff. I'm earning 4% on my PERSONAL CHECKING account, and not paying any fees. I also have all of my business accounts, and my mortgage with my local credit union.
Credit Unions: Like banks, but cheaper, non-profit, less corrupt, no over-paid executives, and not out to screw you over.
Re:Not nothing. (Score:5, Interesting)
Also, lets not forget that a while back some children hacked into Comcast's DNS registrar with nothing more than an unsophisticated Social Engineering ploy.
If the capitalone domain registration ever became compromised, 'hijackeddomain.capitalone.com' would have the same 'root' domain as capitalone.com, but could be pointed at a hackers server in timbuktu.
Just because the domain is 'capitalone.com' does not necessarily mean that everything set up with a vanity off of it is hosted, owned, or operated by capitalone (or more importantly; that they're not owned and operated by someone who possesses malicious intent, be it a disgruntled capitalone employee or otherwise).
Last, the aforementioned domain registration social engineering end-around could theoretically be pulled to obtain a legitimate SSL Certificate. Maybe not specifically by targeting Verisign (at least, not as easily as other companies, I'd venture a guess), but any number of the other more generic and less valuable companies like GeoTrust are all plausible to target with this sort of ploy.
Re:Complaining is kind of pointless. (Score:5, Interesting)
WARNING: RANT...
I hate to say it, but I agree that you'll never get anything fixed by a call center. I've worked in call centers and the people who work there generally have no way to speak to anyone who can fix a problem, even in a "tech support" call center. Also, since they either get paid per call, or at least get docked pay if they aren't actively answering incoming calls, then they have no incentive to fix anything. In fact, they have a big disincentive against fixing anything since it will take away from their pay check and they likely hate the company too much to do it on their own time.
Also, I've been on the other side doing development and it's a similar problem there. It's very easy to make a simple typo or other mistake and never know the difference. No one in the call center ever tells you that the customer is having a problem, so you don't know that something needs to be fixed. So even though it might be a 1 minute fix for you, you'll never know that it needs to be done. There was a bug in this one software that had been there for 3 years, and the workarounds were even in the documentation to train new call center employees. Once a developer finally got it, it took seconds to fix. The customers suffered for 3 years for a few seconds of someone's time. Now I realize you can't fix every bug, all the time, but if the right people don't know about it, then it will never get fixed.
The real problem, IMHO, is that large companies treat their support/customer service departments like they are a drain on the company rather than a way to increase your reputation, thus outsourcing, low pay, strict rules, etc.
Because of this I prefer to do business with smaller companies or, even better, in person. If you're a "real person" standing in line at a bank, the teller is more likely to fix a problem than if you're just a number on a screen and a squeaky voice on a phone. But in-person is so inconvenient in this world of constant multitasking.
Re:Not nothing. (Score:3, Interesting)
Perhaps it would help--for some of us, at least--if browsers indicated how many sections of the domain matched (with the comparison performed from right to left)? After all, the browser won't be fooled by such trickery.
In the submitter's case:
Cert: onlinebanking.capitalone.com
Site: servicing.capitalone.com
2 sections match, this is probably safe (but proceed cautiously)
In the parent's case:
Cert: onlinebanking.capitalone.com
Site: onlinebanking.capitalone.com/login/.tsdk.cn
Danger! 0 sections match. This is probably not safe!
(Pretend that the bolded portions are also highlighted in bright red, or something.)
Re:Complaining is kind of pointless. (Score:3, Interesting)
Derivatives contracts (Score:3, Interesting)
The simple fact is, these companies didn't even think about what would happen if AIG couldn't cover all the swaps. Because nobody could cover all those swaps. Let AIG fail. As far as the banks who are counterparties, let them go into receivership, wipe out the shareholders, and sell off their assets to pay off as many debt holders as possible. That's what the FDIC is for; maybe we should use it for something other than a moral hazard provider.
mod parent up!!! (Score:3, Interesting)
Self-signing is the only sensible way to use certificates.
CAs should only be used in the same way that USians use notary publics. The certificate should be treated like a notary's seal. (And priced the same.)
But the CAs can't even behave like notaries until they get proper time stamping implemented.
The standard itself was never debugged, and every purveyor of snake oil fudges whatever part of the standard that gets in the way of their patent formula.
Sorry to be negative, but it gets kind of fatiguing, watching the other guy making all the money doing everything wrong. Yeah, that's part of believing in freedom, but it would help if the other believed in it enough to at least try to do it right.
Re:Complaining is kind of pointless. (Score:3, Interesting)
...I've been on the other side doing development and it's a similar problem there. It's very easy to make a simple typo or other mistake and never know the difference. No one in the call center ever tells you that the customer is having a problem, so you don't know that something needs to be fixed....
I ran into this problem when I worked for Digital Equipment Corporation, and came up with a solution. I was the one from our software development group who went to Colorado Springs to train the telephone support troops. I developed a rapport with them, and they allowed me read-only access to their call logs for the product. I would pass bug reports to the rest of the development group. In addition, I was able to provide feedback to the support people about incorrect or incomplete responses to customers.
Re:Not nothing. (Score:3, Interesting)
I don't know why anyone has their money in large banks anymore. Move it to a local credit union and let those large bank fuckers die out.
If you check your routing numbers, you might just find that those local credit unions, and other local banks, are clients of the "big banks". My credit union is/was a client of Wamu.
Whois Databases And One-time Passwords (Score:2, Interesting)
Whenever I run into a cert mismatch, I check the site IP (fairly straightforward in FF). Then I do a search on the IP against whois databases (ARIN, RIPE). If I see, that the IP is registered to the organization that is supposed to be serving me (and not just an IP reseller), I grant a temp exception and send an email to the staff of the service provider (the whois databases usually have that info) and tell them they've screwed up.
For online banking, I have one-time passwords, issued by the bank (it's a two-phase process). But I've never run into a cert mismatch on a banking service yet.