I just read the Department of Homeland Security's "Foreign Travel Threat Assessment: Electronic Communications Vulnerabilities". Bottom line, they recommend you leave your electronics at home when you travel.

I decided to search for some of the terms in the paper. The site that caught my eye was that of the United States Department of Agriculture (USDA). The USDA travel pages are really fun to read. They include sections with great titles, such as:

• You Are the Target
• Country-Specific Threat Updates
• Avoiding/Recognizing Intelligence Interest
• Bugging Hotel Rooms

In all fairness, the USDA credits the Overseas Security Advisory Council (OSAC) for much of their information, lest you think foreign spies were only out to get information on US tomato technology.

I just finished reading a report titled "U.S. Dept of Defense Open Technology Development roadmap" published at http://opentechdev.org/.

It says, among other things:

OSS and open source development methodologies are important to the National Security and National Interest of the
U.S. for the following reasons:

• Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.
• Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
• Adoption recognizes a change in our position with regard to balance of trade of IT.
  
• Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
• Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.

I'm glad to see more uptake of this philosophy, and glad to see it in print. 

I recently obtained an original manual for the M-325 converter, an American encryption machine used between 1944 and 1946.

There isn't a lot of information about the M-325 compared to more famous machines like the Enigma. Part of the reason may be that the machine did not work well in the field. It looks positively fragile.

I transcribed and scanned the manual, and posted it here. I've only seen the M-325 in person at the National Cryptologic Museum.  Speaking of which if you have not been there and like this sort of thing, it's worth the trip.

The Wikipedia article on the M-325 has a little information, and Jerry Proc's page has some additional photos.

If you have additional information on this device, drop me a line.

The times are changing for the cryptography in your browser.

As many of you know, the SSL2 protocol has been superseded by the SSL3 protocol, and the TLS 1.0 and 1.1 protocols. As a result, we're working to remove the SSL2 protocol from the Mozilla clients. We'll be able to send the SSL3 hello message to the server when starting an SSL connection. The SSL3 hello will allow us to support a new type of cryptography, called Elliptic Curve Cryptography (ECC). It will also allow us to support Server Name Indication (SNI). [See this page for more information.]

Also, a number of ciphersuites with short (weak) key lengths (40-bits and 56-bits) have fallen out of vogue. They are just too weak to be trusted. So we're working to turn them off as well.

Microsoft is working on the same goals. Here is one of their blogs:
http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx

Here is the page we're using to track the few remaining SSL2-only sites that matter:
http://wiki.mozilla.org/Necko:SSL_v2_Sites

And here is Gerv's blog on the same subject:
http://weblogs.mozillazine.org/gerv/archives/2005/09/ssl2_must_die.html

If you run a web site that uses only SSL2, or one that only uses weak ciphers, it's time for you to upgrade your site!

As an aside, we're continuing to work on "mod_nss", an Apache web server module that allows administrators to use the NSS crypto libraries rather than OpenSSL. See here for more information:
http://directory.fedora.redhat.com/wiki/Mod_nss

I read a lot of articles about phishing. People write and talk about how you can protect yourself, cite stats on the number of attacks per month, and the cost to the economy.

But I don't hear one really important question: Why does phishing exist?

One reason is that your bank, broker, and favorite online stores fail to use SSL throughout their site. If sites that hold my important data and have access to my money used SSL everywhere on their site, I'd be able to tell if I was at the right web site by looking at the lock icon. (And yes, phishers would move to SSL, but then we'd have a chance to catch them, and to improve the CA issuance processes as a bonus!)

Another reason phishing exists is that companies outsource their marketing to third parties. In doing so, major companies mimick all the major elements that point to phishing. They make it impossible for even a security-aware individual to tell phishiers from real companies. Again, it's not that phishers are acting like real companies, it's that major companies are acting like phishers.

Here's a great example. I got an email today that claimed to be from the organizers of the RSA Security Conference. It wants me to sign up for an online class. That sounds fine, but look at the URL I'll go to when I visit the web site:


(Click to enlarge)

The URL that I'm about to click on looks like this:
https://rsasecurity1.rsc03.net/servlet/cc5?jkHQUYSUQUVI
I've never heard of this rsc03.net before. It's certainly not the same as rsasecurity.com. So can I trust it?

I clicked on the link, and was indeed brought to an SSL-enabled web site. The site then proceeded to ask me for lots of personal information. That's pretty suspicious.

Then I decided to look at other URLs in the email to see what I could find. Here's what the footer says:

RSA Security respects your online privacy. This email is being sent to people who've recently inquired about RSA Security products, services or events. You can view our e-mail policy here: http://www.rsasecurity.com/node.asp?id=2470

But when I click on the link, it takes me to
https://rsasecurity1.rsc03.net/servlet/cc5?jkHQUYSUQUVIthj
It claims it will take me to a domain I trust (rsasecurity.com), but actually takes me to a domain I've never heard of before (rsc03.net). It must be a phishing attack, right?

The sad thing is that I'm pretty sure this is a real email, and not a phishing scam. (The clumsy mail verification link at the top of the page gives me very little confidence.) But given all the clues to the contrary, it's a real gamble. Sadly, when companies start to act like phishers, they inadvertently train us to not look at the lock icon, to type our passwords into pages with no SSL, to not inspect the URLs we're about to visit. And when the organizers of the worlds biggest security conference make these mistakes, how can I reasonably hold my online bookseller to a higher standards?

I'm ready for a change.

According to this article on searchsecurity.com, Yahoo Business email subscribers were left unprotected when they logged in.  Normally the login page would post names and passwords using SSL to protect the transmission. In this case, the login page posted that information over HTTP rather than HTTPS.  My guess is that this is not the first time a site has bumped into this mistake.  It's hard for QA engineers to catch silent errors like that unless they explicitly look for them.

Many web sites choose to leave the login page unprotected, and only protect the page that receives users' names and passwords.  As I've said before, this approach is works if your threat model is "people are tying to eavesdrop on my connection to the web site". 

But that's not the only threat these days. Given the rise in phishing attacks, sites should use SSL on both the login page, as well as the login submit page.  In fact, businesses that use SSL for any purpose should strive to make SSL ubiquitous throughout their entire web site.

The cost of making SSL universal on a site in terms of hardware and support is small compared to the damage than can be done when a programmer forgets to type "https://" and instead types "http://".

When I ask people why they don't use SSL on the login page, I get a answers that can be boiled down to "SSL is too expensive". When I dig deeper, I find more complexity than I expected.

Performance

First, let me address the issue of raw SSL performance. There was a time when it was simply too expensive to contemplate SSL for very many tasks. SSL operations were performed on the same CPU that was used to perform database lookups, generate HTML, and a variety of other functions. The expensive RSA private key operations caused a significant drain on the servers.

But things are different now. Web farm architectures are far more sophisticated than they were in 1997. And between Moore's Law and performance tuning in the SSL libraries (like the open source NSS crypto libraries) we now see very high performance number for SSL connections, even in software. We were recently doing some performance tests for a project, and while we had all the measurement tools fired up, we decided to see how many SSL-based logins we could get per second. On a $5,000 Dell box, we were able to get about 1,000 logins per second, which translates to 3,600,000 logins per hour. Depending on how we defined "login" (the ratio of RSA handshakes to SSL restarts), we could hit 5,000,000 logins per hour. Assuming you want a little breathing room for peak loads, you could throw another $5,000 box into the mix. Or toss in 10 and spread them around the country. Or you could buy SSL accelerators (either PCI cards, or as front-end balancers), though I doubt they are necessary these days given these numbers for software-based SSL.

The other complaint which I used to hear in 1998, but have not heard in the past several years, is that modems cannot compress SSL sessions, which means that customers on modems will see worse performance on an HTTPS page than they will on an HTTP page. That fact remains (you can't dramatically compress properly encrypted data) but given the slide in modem usage, this is less and less of a problem over time. And now that AOL is raising rates on modem users, that trend will accelerate.

Bottom line: In 2006, SSL is super cheap. You have to plan for SSL performance, but it's not going to be a major task compared to the complexity of the rest of the web farm architectures that exist out there. And it's not going to cost much at all. For companies that are worth billions of dollars, I think they can easily find room for a few $5,000 boxes to improve security.

Politics

Knowing that, why do companies still not deploy SSL as widely as they should? That's the second, and more surprising part of the story. The reality is that these companies are segmented into divisions, each of which has its own goals, budgets, and problems. There's often a "login team" that is responsible for providing a single-sign-on scheme so that other divisions don't have to manage their own account/password databases and cookie-passing scheme. Then there's the team that deals with the front page. Then there's the team that deals with the primary service (banking, trading, mail, or whatever their core app is). Then there are groups that deal with the aftermath of fraud, like phishing.

These divisions are not connected as cleanly as they might be. There is little incentive for the login team, for example, to help the Front Page team use SSL correctly. They are there to provide SSL when you hit the "Login" submit button and that's what they do. Meanwhile the Front Page team believes that they cannot afford to put SSL on their portion of the site on their own. And the fraud team's main charter is to help customers who have been victimized, not to stop the problem in the first place.

Every survey since 1492 about computer security and the Internet has shown that CEOs, politicians, consumers, and dogs believe that "Security is the #1 issue facing us today". And yet, as far as I can see, there is a real failure of leadership at the senior-most levels of these companies to connect the dots and to put SSL on every page. This is especially true of the financial companies.

And the terrible part is that it's the consumers who pick of the tab of phishing attacks, not just in dollars, but in time and stress as well.

It's 2006 and there is every reason for a company in the financial world to implement a coherent site security strategy that involves SSL on every page. Wells Fargo did it! SSL is cheap, security expertise is widely available, and customers are under attack on a daily basis.

In my last entry, I said that some of the biggest names in banking were guilty of teaching their customers that it was not necessary to check for the lock icon in the browser before they typed in their account names and passwords. Let's look at some specifics.

As of this writing, Washington Mutual, Bank of America, Bank of the West, and Chase Bank all accept name/password login from their home page, a page which is not protected by SSL. (I just picked those at random; the problem is more pervasive: see http://www.cs.biu.ac.il/~herzbea/Shame.html for more information) So does AOL. Yahoo always uses SSL, but only when you click on the submit button. MSN sends passwords in the clear unless you click on the link titled "Sign in using enhanced security". And when I did that, I got certificate errors because they botched the SSL configuration.

Beyond the bad security practices, Washington Mutual's help page says

Non-secure Web pages. Clever thieves can build a fake Web site that looks nearly identical to an authentic one. They can even alter the URL (the Web address) that appears in your browser window. Watch out for non-secure Web pages that ask for sensitive information (secure sites will typically display a lock in the status bar at the bottom of your browser window).

And yet their site does exactly the reverse. It asks for customer names and passwords without a lock! This is a great example of a real web site acting like a phishing site.

Speaking of locks, many of these financial institutions work hard to break the user's mental model of security. They actually put an icon of a padlock in the HTML next to the login fields! But since anyone can put a lock icon into HTML, it adds nothing but the illusion of security.

I'm not the first to notice that banks have undone the user education that we promoted so heavily. From http://www.antiphishing.org/Phishing-dhs-report.pdf

Financial institutions have widely deviated from the guidelines they have disseminated for distinguishing phishing messages from legitimate communications, undermining the educational messages they have distributed. In particular, many financial institutions use unexpected domain names similar to the names a phisher would use, do not use SSL in a user-verifiable way on a login page, include clickable links in email communications, and so on.

Not all of the major sites do it wrong. Wells Fargo does it better than any other site I could find. Their entire site is protected by SSL. That's exactly the right approach to reduce the chances that people are fooled by phishing scams. There are no edge cases. Even their pages which offer generic information, like the ATM locator pages, are protected with SSL. The rule is simple: if you don't see the lock icon on every page, you are not on the Wells Fargo web site. Bravo!

Other sites that include SSL on the login page include the Gap and Ebay. So there are sites that understand the issue, but I'm starting to conclude that they are in the minority.

Next time: Poor excuses for not using SSL.

I've been poking around various web sites and have noticed that major on-line services often fail to use SSL to protect their login pages. I'm not talking about sites where they don't need, or don't care enough to use SSL. I'm referring to major sites that use SSL, but only after you hit the Submit button. From a password security standpoint, this is sufficient. You don't actually need to protect the page that says "Type in your user name and password". It does not matter if hackers see that page, as long as they cannot see your name and password when you submit it. At least it didn't used to matter.

The problem today is that phishing has added some complexity to the security analysis of this situation. When phishers send out emails, they tell the victims that there's been some sort of problem, and they need to login to the web site to clear things up. They provide a link in the email which would normally take the victims to the real web site, but in the case of these attacks, they take the victim to a web site that is under the control of the phishers. These phishing emails and web sites are getting very good. It may not be possible to tell just by looking at the web page itself if it's your bank's web site, or the phisher's.

Why does this attack work?

In the early days of Netscape, we spent a lot of time and energy to train the press and customers that they should never type any personal information into the browser unless they saw the lock icon. Long before the word "phishing" was coined, we knew bad people might do something which would be thwarted if users followed this advice. And it worked for quite some time. In fact, we had usability testing which showed that this training worked.

Sadly, things have changed. Many major companies have implemented their web sites so as to undo this user training. Users now have no way of knowing what's real and what's not real because their banks, travel agencies, and merchants have taught them through repeated experience that it's OK to type their account information and passwords into pages where there is no lock icon. And because in most cases, nothing bad happens, people got used to it.

It's really disturbing that so many of the biggest sites with the biggest brand names fail to put SSL on their login pages. In many ways, they have unwittingly created the environment that allows phishers to thrive.

In my next few posts, I'll explore the banking situation, some myths around SSL, and some best practices I'd like to see all financial institutions follow.