Comments

Tim R • June 1, 2006 12:24 PM

Pat: I resemble that remark!

Seriously, in my short time on this Earth (I’m a thirty-something), I’ve found this attitude is far to prevalent, not only in security, but every day life. America’s obsession with not wanting to rock the boat became a little skewed after a while.

We saw this same behavior during the latest major rounds of intellectual property legislation, specifically changing from a first-to-invent to first-to-file. I can’t begin to count the number of times I heard the phrase “we’re bringing our laws in line with the way the rest of the world’s laws are”.

Whatever happened to this country’s spirit of paving the way. We’ve gone from a nation of leaders to a nation of passive-aggressives. This is probably the same reason why students in other countries are constantly outscoring and outachieving their US counterparts.

Anonymous • June 1, 2006 12:29 PM

Additionally, from their own site:

“To help protect the information that you enter into your computer’s browser before the secure connection is established (such as your Access Number, User ID and Password), we highly recommend that you install the following security software on your personal computer (PC): anti-virus software, a firewall and spyware detection software.”

AG • June 1, 2006 12:39 PM

Once again.. the only person who cares about your information is YOU.

Bruce’s last post the “Aligning Interest with Capability” until each person owns their own personal data and they can Charge Usage of it there will be no reason to protect the data.

bob • June 1, 2006 12:57 PM

@Tim: …and why US students, after a lifetime of having the hurdles lowered when they fail to clear them, shoot up the school when finally presented with an adversity they have to clear with the mental tools they accumulated in their lives to that point and dont have a clue.

Mike • June 1, 2006 1:01 PM

What is the attack here, Sniffer attack or phishing? Since when does https prove who is on the other end? It doesn’t. All it can do is protect against sniffer attacks, which is a good thing, but only half the battle.

Angry Taxpayer • June 1, 2006 1:06 PM

@Bob:

I think you’ll find a more common attribute of those school shooters is a history of being bullied, marginalized, ridiculed, and ostracized, rather than an inability to cope with a challenging situation after years of molly-coddling.

I can think of examples where a history of being granted “a passing grade” has led ultimately to a flameout of world-historical proportions once the beneficiary no longer could count on a bailout, but right now Washington, D.C. rather than Columbine, CO comes to mind for some reason.

Pat Cahalan • June 1, 2006 1:10 PM

@ Mike

The issue is not George Ou’s overall critique of Navy Federal. George’s rant isn’t really intended to be a thorough analysis of their security processes (or if it is, as you point out, his analysis is lacking in depth). Regardless, the particular bit of the blog entry that is interesting is the “everybody else is doing it” defense.

It’s not so much that George Ou does or doesn’t understand the implications of SSL and the actual level of security that it provides, but the fact that the bank’s security processes are boneheaded 🙂

David • June 1, 2006 1:14 PM

@Wumpus

SANS did a survey of this very thing a while back. U.S. Banks faired well in most respects, but European banks were damm near perfect.

As to “most banks” do this, according to the SANS survey, most of them require HTTPS on the sign on page, only a few holdouts still don’t.

You can see the poll here: http://isc.sans.org/poll.php?pollid=91&results=Y

John • June 1, 2006 1:24 PM

Actually it could be “safe” but you would have to look at the HTML for the form being filled out to see if the action is “https”. If it is, then it is safe. The real problem is that browsers do not show you what forms connect securely and which ones don’t. In fact, just because a page displays as secure does not mean the forms in the page have secure actions! That is probably even worse!

John • June 1, 2006 1:29 PM

Decided to check that bank sign-on home page and sure enough, they are actually “safe”. The form’s action does use https to transmit the sign-on info. I wish browser’s could somehow highlight that the “submit” button for a form is secure – maybe put the lock symbol on the button???

jmr • June 1, 2006 1:45 PM

I had the same fight with Bank of America before they upgraded their login system. I pointed out the same things and got the same responses. I was pretty upset.

James Blanding • June 1, 2006 1:53 PM

@John:
Well, it’s true the form submission is encrypted, but SSL offers more than just encryption, namely identification. A good Certificate Authority requires companies to prove at length they are who they say they are before issuing a cert. That way, when you view the details of a cert in your browser, you can trust the details are correct. (Nothing is perfect of course, but the idea is relatively sound.) So I believe the main issue being raised here is that users are asked to enter their credentials without having the ability to confirm the identity of the requestor.

Bank of America does this as well on their front page. If you dig around a bit you can find a signon page that loads entirely through SSL (which I have bookmarked at home).

Yahoo also recently started doing this.

I can see the motivation an IT manager might have to try to cutdown on server overhead, but it is sad to make such a significant sacrifice in security for that cause. It’s unfortunate the practice is becoming more common.

Carmudgeon • June 1, 2006 1:54 PM

@John

I think you are missing the point that, because the initial page is not encrypted, it is subject to hijacking through a “man-in-the-middle” attack. What you see may not be the real initial page. And, therefore, even though the site you connect to from that page may be encrypted, it may not be the bank’s encrypted page. Instead the spoofed initial page may direct you to a spoofed encrypted page.

Kevin Davidson • June 1, 2006 2:06 PM

SSL in and of itself is not proof that you are on the site you believe you are on. All the Padlock icon tells you is that SSL protocol is being used (assuming the web site isn’t spoofing the padlock in one of several ways this can be done). And depending on the version (bug level) of your browser it may tell you if the URL in the address bar matches the certificate.

While Bank of America doesn’t SSL its home page, you cannot enter your password on that page–only on the SSL page that comes up next. Further, their SiteKey seems to me a very effective and easy way for the consumer to know if they are on the real Bank of America site or not. SiteKey may be an option, but one everybody should invoke.

Pat Cahalan • June 1, 2006 2:16 PM

@ James Blanding

SSL offers more than just encryption, namely identification. A good Certificate Authority
requires companies to prove at length they are who they say they are before issuing a cert.

SSL does not, in fact, offer identification, at least in practical terms. There are so many stories about circumventing CA’s policies on the internet that I personally would regard no CA as a trusted party. Not to mention the fact that it would be trivial to create a signed web site with a real certificate purchased by a dummy company, and man-in-the-middle someone to the dummy site. If they think it’s Bank [foo]’s website, they’re not going to bother to check the certificate.

SSL is good for encrypting a communication session, nothing more.

jmr • June 1, 2006 2:28 PM

@Kevin, James Blanding

My comments were regarding prior to the Sitekey implementation. Prior to the Sitekey implementation you could only type in your password on a Non-SSL encrypted page, unless you knew some magic Google incantation that showed you a state-specific login page that was itself SSL protected.

The new Sitekey system seems pretty good to me, too.

I haven’t used Mozilla yet. Does it let you white-list SSL encrypted site certificates? That way, of you’re on an SSL site you don’t ordinarily use (a possible phishing imlementation) it might flash angry things at you saying you don’t really know if this is the site you’re looking for.

Not a perfect idea, but most people only regularly use a small number of sites that contain important personal or financial information or abilities. Like, your online banking, online trading, your usual online shopping locations?

Swiss Connection • June 1, 2006 2:50 PM

This issue about Certificate Authorities that can be compromised to issue SLL certificates to anonymous rogues comes up again and again.

Does anyone know the legal situation? If I get screwed by a phisher claiming to be my bank who uses a class 3 Verysign certificate, can I sue Verysign for the loss?

I should, considering the price I pay for those class 3 SSL certificates.

Andrew2 • June 1, 2006 3:32 PM

“SSL does not, in fact, offer identification, at least in practical terms. There are so many stories about circumventing CA’s policies on the internet that I personally would regard no CA as a trusted party. Not to mention the fact that it would be trivial to create a signed web site with a real certificate purchased by a dummy company, and man-in-the-middle someone to the dummy site. If they think it’s Bank [foo]’s website, they’re not going to bother to check the certificate.”

Actually, as long as the CAs don’t sign a certificate for the incorrect party of an already existing secured website, then a user can be reasonably sure of its validity. You just have to make sure you type in a full https://www.bankofwhatever.com address (or use a trusted bookmark to it) and that you get a padlock on the other end.

If you, instead, rely on an insecure redirect, or an unauthenticated logon page, no matter what security is used beyond that point, you cannot be sure of who you are talking to anymore. The problem is, very few users are capable of understanding this. Most people working on computers seem to get lost thinking that anything that works is good enough.

Kevin • June 1, 2006 3:47 PM

It is true that lots of banks are switching to login prompts on non-SSL pages, but at least the information is still transmitted over an SSL connection. Of course, you won’t be in a position to inspect the certificate until after you’ve sent the data.

But, saying banks are “failing to use SSL authentication” is only true for the login page. When the secure session is established, then authentication is done.

I really have to take issue with this blogger’s tone, however. His outrage causes him to use a sarcastic tone and inflammatory remarks (like calling them and other American banks ignorant, and mentioning legal action). Nobody’s going to want to listen to your remarks, however legitimate they might be, if you come off sounding like a raving lunatic. Security won’t happen if the people you need to cooperate stop listening to you because you have no tact. Saying they’re failing at security miserably and all this other hyperbole just detracts from this blogger’s credibility. That’s the kind of judgement I’d reserve for a bank that didn’t use SSL at all for sensitive information. We need cooperation from these others in the security game, remember?

Andrew (the other one) • June 1, 2006 4:57 PM

Banks are very cost conscious. They are highly secure with their money. They are less so with yours.

SSLDoesAuthentication • June 1, 2006 5:31 PM

@Mike, Pat, others

SSL provides two major things, an encrypted channel and server authentication. Server authentication is critical, because without it, encrypting the channel makes no sense whatsoever.

If the client can’t verify the authenticity the server on the other end, it is simply wasting time encrypting the data, since it could be encrypting the data for the very one it is trying to prevent seeing the data.

To say that SSL only provides encryption indicates a lack of understanding of SSL and security.

As for SSL certificates, the CA’s have certainly contributed to creating a less than ideal trust environment for SSL certificates. But that is not to say that all is lost. There are reputable CA’s that are issuing trusted SSL server certificates.

If phishing occurs via a fraudulent website that was secured using a fraudulent SSL cert, the CA that issued the cert should be publically outted, with their reputation clearly brought to task (with the ultimate result that the CA is put out of business). People need to be better aware of CA’s that are issuing trusted certificates.

On Pat’s remark about banks that “don’t get it” by using domains other than their bank’s trusted domain name for Internet Banking, I have not seen this firsthand. I have seen where a bank will use a different HTTPS domain for the username/password credential submission, but this was on a login page that was secured using a HTTPS domain that is the bank’s trusted domain name. So even though the credentials are submitted under a domain that is different, it is on a secured page from the bank’s verifiably trusted domain. This is most likely due to the bank using a third party processor that is providing the bank’s Internet Banking services.

antibozo • June 1, 2006 5:52 PM

The argument that because CAs have been flummoxed into issuing certificates to the wrong people therefore SSL provides no authentication is complete bull. That’s like saying that because locks have been picked they are useless.

The usual solution I employ to the non-SSL login page is to go ahead and click on “login” without filling in any credentials. In most cases this bounces you to an equivalent SSL login page with the warning that your credentials were no good, where you can then enter the real credentials after checking the URL.

Derick • June 1, 2006 5:55 PM

I agree with blogger although he is a bit of the “raving lunatic”. A gentler tone would probably win more hearts. And I agree that you still have to be careful with SSL, it doesn’t always guarantee you are not on a phishing site. But I think this is another topic. Signing on via an SSL page solves most of the problem.

There is, however, as easy workaround to this problem. Just hit the “sign on” button without entering anything. This should bring you to an SSL page telling you your username / password is invalid and please re-enter. Now you have confirmed you are on the correct site and can safely enter your username password. I have yet to encounter a site where this doesn’t work (including Navy Federal).

Pat Cahalan • June 1, 2006 7:36 PM

@ antibozo, SSLDoesAuthentication

that’s like saying that because locks have been picked they are useless.

On the contrary, it’s nothing like saying that because locks have been picked they are useless.

Picking a lock successfully gives you access to one lock.

Getting a CA to give you a cert gives you credibility to the world, if the world automatically trusts the CA. It’s a built-in class break.

I’m not saying that SSL is a bad thing, mind you, and I’m not saying that a CA-issued cert isn’t an indicator that the the web site is more likely to be legitimate. I’m saying that the idea that the web site has a CA-issued cert means that everything is by default to be trusted is bad bad bad.

If the client can’t verify the authenticity the server on the other end, it is simply wasting
time encrypting the data, since it could be encrypting the data for the very one it is
trying to prevent seeing the data.

The client cannot verify the authenticity of the server at the other end. The CA does that. The client refers to the CA (I’ll not bring up that clients have to know how to parse a CRL for “real” authenticity).

The client can only tell you, “This cert was signed by this CA, and this CA says this cert is okay”.

Irregardless… people don’t check the certs they get. Many people will just accept a self-signed cert offhand. You can get a self-signed cert, or a bogus CA, onto a client’s machine or browser using a multitude of techniques. If your security process relies upon trusting a certificate to be from the entity it claims to be from, you have a weak point.

Assuming that the SSL connection is always providing you with encryption between you and a destination point is currently mathematically supportable. Assuming that SSL always authoritatively identifies the legitimate owner of the remote host is not mathematically supportable.

On Pat’s remark about banks that “don’t get it” by using domains other than their bank’s
trusted domain name for Internet Banking, I have not seen this firsthand.

You’re right, that was a bad post. Change “bank” to “financial transaction handler”. If you buy stuff on the web, often you’re redirected away from the host domain.

antibozo • June 1, 2006 10:56 PM

Pat Calahan> it’s nothing like saying that because locks have been picked they are useless. Picking a lock successfully gives you access to one lock. Getting a CA to give you a cert gives you credibility to the world, if the world automatically trusts the CA. It’s a built-in class break.

Uh, no it isn’t. It’s exactly like picking one lock–it gets you to access to a single protected pathway. If the break is discovered, the cert can be revoked, just as the lock can be replaced. A class break would be discovering the CA’s private signing key.

Pat Calahan> Irregardless….

Presumably you mean “regardless” or “irrespective”.

Pat Calahan> Assuming that SSL always authoritatively identifies the legitimate owner of the remote host is not mathematically supportable.

Very few statements about reality containing the word “always” are “mathematically supportable”.

The assumptions regarding SSL authentication that people make justifiably are:

  1. Someone at the CA made any effort at all to authenticate the certificate requestor. This alone factors out the vast majority of attacks since most attackers don’t even bother with SSL. They rely on end users’ being ignorant of good security practices anyway, so why take a chance at tipping off the financial institution that your about to conduct a phishing attack against their customers?
  2. Someone PAID for the certificate. Again, this narrows the field dramatically.

If you want to talk about mathematics, then let’s do some counting:

A. How many phishing attacks have been conducted?

B. How many phishing attacks have involved fooling a CA into issuing a certificate for a financial institution to the wrong party?

Estimate these, and calculate B/A. Doesn’t that kind of look like “mathematical support”?

Thomas • June 2, 2006 3:27 AM

I think one problem is that users do not understand digital certificates. To make people understand and require this it must be used commonly on more sites.
Why does for instance Microsoft Passport (a.k.a. “Live ID”) have an unsecure login page? There are quite a few Hotmail users and they commonly access their account on unsecure machines.
I cannot tell my mother to “Always look for the ‘lock’ icon before you enter your password” because there are so many commonly used sites where this advise doesn’t work. Too bad not even big companies like Microsoft can get this right.

Skail • June 2, 2006 5:01 AM

Most shocking quote:

“Please note: Navy Federal can only take steps to establish a secure, encrypted connection after you click on the “Sign On” button.”

so….. “we refuse to provide secure login, we only provide security once you’ve already logged in. If someone ‘man-in-the-middle’-s you, we really don’t give a hoot.”

fabulous attitude.. I applaud you.. listen to the sound of my butt-cheeks slapping together.. It is an expression of my admiration..

Jungsonn • June 2, 2006 7:23 AM

SSL certificates can be generated on the fly, like openssl. Commonly certs really say nothing about being “secure”.

D V Henkel-Wallace • June 2, 2006 9:10 AM

“Everybody does it” is a longstanding justification for business security; it’s hardly new. Actually it’s usually phrased the opposite way: companies do no more than the “industry best practice”, and woe betide any security company who tries to raise the bar (I know, I tried back in the early ’90s). Two examples:

We visited Unnamed Financial Exchange. In the same building was Unnamed Financial Company, and the two were on the same (thinnet) ethernet! When I pointed out that everybody could see everybody else’s traffic, the response was “don’t tell upper management because then we’ll have to change things, which will cause huge disruption at an inconvenient time and take time away from the stuff we’ve been asked to do”. I.e. they knew, but didn’t care.

Case two: Visiting Unnamed Chip Companies (hmm, let’s call ’em I and M): you had to have your bag inspected when exiting and the covers of any documents shown to indicate they weren’t confidential to the respective companies. They looked specifically in briefcases and backpacks, and that was all. at UCC “I” I asked my escort (once past security) “what about floppies? I could have one in my pocket.” The answer was that security just took “reasonable steps” to protect IP; you can’t stop everything so if (when?) something leaks the company only has to be able to tell its shareholders that it did “industry best practice” — after all it couldn’t just tell people not to take anything out or do strip-searches or fluoroscopy.

So the lesson for security companies with new technologies is: once you get a “thought leader” to publicly adopt your approach, you’re great: everyone else in that industry will have to switch too. But until then, it’s an uphill battle.

Arguing over SSL certificates is a waste of time: none of those companies has to care so none of them will (well, my bank does and frankly it’s a pain). And this is why, for example, all those laptop thefts seem to have no real effect.

Paeniteo • June 2, 2006 9:31 AM

@jmr: “I haven’t used Mozilla yet. Does it let you white-list SSL encrypted site certificates? That way, of you’re on an SSL site you don’t ordinarily use (a possible phishing imlementation) it might flash angry things at you saying you don’t really know if this is the site you’re looking for.”

Indeed, there’s an extension exactly for this purpose.
Alas, I forgot the name…

Paeniteo • June 2, 2006 9:40 AM

@John: “The real problem is that browsers do not show you what forms connect securely and which ones don’t.”

In fact, they do (Mozilla and MSIE, at least).
You will receive a warning, when submitting a form to a non-encryptet connection (at least when the method is “POST”, don’t know about “GET”).
Just because you clicked the ‘never bother me again with this kind of warning’ checkbox (or left it checked, don’t know about the defaults) it doesn’t mean it isn’t there.

For Mozilla/Firefox, you can go to “about:config”, search for the “security.warn_submit_insecure” property and set that to true (it most probably will be “user-defined” set to “false”).
I did this before previewing this post and indeed got the warning again.
There are also warnings when entering/leaving SSL connections and much more, but one usually deactivates these soon.

Xellos • June 2, 2006 12:10 PM

–“Picking a lock successfully gives you access to one lock.”

Unless it’s a master or grandmaster, in which case picking a single lock can potentially let you open tens or hundreds (or occassionaly even thousands) of other locks…

Pat Cahalan • June 2, 2006 1:31 PM

@ antibozo

It’s exactly like picking one lock–it gets you to access to a single protected pathway.

Picking nits, I suppose. They are two different attacks entirely, though -> picking a lock is breaking a security barrier to gain access to a single location. Getting a legitimized but bogus SSL certificate is basically the same as getting a fake license to do business. One is a B&E crime, the other is forgery. In the first, you’re trying to get access to one thing/place. In the second, you’re trying to convice an audience that one thing/place is a trusted place. In the first, you get to steal one thing (or, if you like, you can steal things behind those types of lock, but you have to move around and find other locks like it), in the second you just have to convince people to come to your trusted place.

The second is a much more scaleable crime 🙂

Presumably you mean “regardless” or “irrespective”.

My wife is a week overdue for delivery, so the ol’ gray matter is operating at suboptimal levels, apologies 🙂

WRT SSL overall, you’re correct. If every site that handled sensitive information had a cert signed by a trusted third party, that would improve things, since not all of them do now, and getting a signed cert is a barrier to entry to commit phishing. I’m certainly not arguing that banks shouldn’t get SSL certificates signed by a CA. And you’re also correct that most phishing attacks don’t rely on SSL now.

However, if/when all financial transaction handlers do indeed have CA-signed certs and browsers have taken steps to ensure that the end-user presentation makes the lack of such a cert a easily discernable to the end user (bright red frame and a “WARNING: INSECURE”), you’re still going to see these attacks occur -> the bad guys will get bogus CA-signed certs, or they’ll create elaborate scenarios to fool the user into thinking they have CA-signed certs, or they’ll hack the browser to not display the warning, etc.

I guess my point is/was, “don’t think that if every financial institution gets a CA-signed cert this problem is going to go away”. It’s not.

Jess Austin • June 2, 2006 6:16 PM

There seem to be a variety of CAs in operation. Has anyone done an analysis of these? In other words, is there an authority to which I can refer, to figure out which CAs I should have configured in my browser and which I should remove? It seems that the FireFox people have put together a built-in list, but for political reasons that list might be more inclusive than I’d like. If a particular CA doesn’t consistently follow its security guidelines, for example, I wouldn’t want to trust it, but I don’t have a way to know that…

Longwalker • June 2, 2006 8:31 PM

@Paeniteo:

A ‘warning’ that cries wolf as often as the insecure forms warning is completely useless. For a warning to be useful, the rate of false positives must be minimized. Users can’t be expected to derive useful security information from an alert that pops up every time they do something as trivial as use a search engine.

The fault here lies with the banks, not the client software.

Chris Davies • June 3, 2006 6:34 AM

The article is completely ridiculous, and I can’t believe you posted it.

The bank isn’t saying they don’t use SSL, they’re just trying to reassure customers that their details are encrypted in transit to their server, despite their homepage not being a HTTPS url.

Both authentication and encryption are present. As you well know, the SSL/TLS handshake takes place before any data is sent, so if you submit the form and get a certificate validation error dialog, pressing cancel will cause no data to be sent. If you don’t get one, well, who checks valid certificates anyway? It all comes down to making sure you went to the correct URL.

The bank is trying to trade off security and ease of use. They need to put the login form on the home page, but it would tax their servers unduly to make the whole site HTTPS.

This is nothing but ignorant and sensationalist journalism.

Tim Vail • June 4, 2006 8:55 AM

Chris…

You ought to read this article:
http://news.netcraft.com/archives/2005/08/23/banks_shifting_logins_to_nonssl_pages.html

Yes, we all know that SSL authenticates the server before sending the information. But the problem is that in the HTML, you have a login form that has something like
form method=”post” action=”https://mybank.com/login.php”

Since this code was sent through HTTP, it is possible for someone to change the action as follows:
action=”https://evilguyssite.com/mybankLogin.php”

And then assuming you have a valid certificate from the CERT for evilguyssite.com, the SSL certificate would authenticate just fine! It would just be authenticating the WRONG site. The only way to guarantee that the login form action data is not altered in transit is to send the login page over SSL.

-Tim

antibozo • June 6, 2006 8:21 PM

Tim> Since this code was sent through HTTP, it is possible for someone to change the action as follows: action=”https://evilguyssite.com/mybankLogin.php”
Tim> And then assuming you have a valid certificate from the CERT for evilguyssite.com, the SSL certificate would authenticate just fine!

It’s simpler than that. You just make your fake bank login page submit to a CGI that logs the credentials and then redirects to the real bank login page. The logging CGI doesn’t have to do SSL at all.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.