A typical attack could be set up using a fake open WiFi service. I'd say it's quite realistic to expect people to try to connect to open WiFi networks they can find when sitting in a pub, or any similar situation.
Especially on mobile devices, warning messages seem to be even more obscure and ignorable than on desktop software (in addition, in a pub, a bit of alcohol in the user's bloodstream may encourage warnings to be even more ignored). It would also be quite realistic to assume that some apps may poll their server regularly, even when the device is in the user's pocket: badly programmed applications could very well leak credentials or other information this way.
A recent BBC News article (Android apps 'leak' personal details) points to this paper: Why Eve and Mallory Love Android:
An Analysis of Android SSL (In)Security.
Blaming Android this way sounds a bit alarmist, but it does reflect the state of a number of applications indeed, unfortunately. Android's situation is probably coming from the Java legacy, where host name verification isn't done by default, and where you need your own code if you're directly using an
The situation may be a little bit better in the iOS family, because it seems that Apple rejects apps that disable certificate verification (I don't have any personal experience with this). I'm not sure whether anonymous cipher suites are allowed, though, which could be inconsistent with such rejection policy.
I think developers tend to consider certificates as being complicated, maybe not everyone, but at least a sizeable number of developers. Admittedly, certificates are a bit of a pain to deal with, but if you manage their use properly, it's not much harder to set up a test CA for development than it is to set up other forms of dummy data for unit tests (let's just assume you don't need CRL/OCSP in a test environment, although you'd ideally have that too).
Whether you'd want to blame the library or the developers is arguable.
Not all libraries are equal, and not all target the same categories of users/developers.
One of the big reasons why SSL/TLS stacks don't verify the host name by default is that the host name verification mechanism depends on the application protocol used on top. One of the most common certainly is HTTPS (RFC 2818, Section 3.1). This has often be used a reason not to implement host name verification there.
Things are changing though: RFC 6125 attempts to unify the host name verification method across all protocols. It's not widely implemented yet, but it's not very different from the HTTPS behaviour anyway.
In addition, Java 7 now has a way to verify the host name with specific
SSLParameters (enabling an
X509ExtendedTrustManager) which makes it a bit more convenient to switch on host name verification, even when using an
SSLSocket directly (without extra layers of
The same reason shouldn't apply to higher level library, such as those that provide HTTPS access. Unfortunately, some users will want to disable certificate verification one way or another anyway. (It's also unfortunate that some libraries don't seem to want to fix the problem.)
In my experience on StackOverflow, there are a number of questions that are about ignoring certificate errors (here is one today, again). Some answers that suggest disabling any trust management altogether get accepted and sometimes rather highly upvoted. (Sometimes, you even get downvotes for suggesting to do the right thing, although admittedly, this doesn't quite answer the question indeed.)
I'm not sure whether a better default library behaviour would help in this case, since those who ask just want to ignore the errors. Considering the Java example, most people complain about the error that happens when they get an exception because the remote host isn't trusted. There are far fewer questions about how to verify the host name (which isn't done by default when you use
I'm not sure how representative the SO community is, but some people just want a quick fix, at least to get going with the rest of the application. My guess is that even in the cases it stays on the "fix-before-release" list, since it's then silent, it never actually gets fixed in some cases (especially because the box "is using SSL/TLS" is still ticked).
Certainly, the pressure for early release combined with a seeming lack of understanding about certificates contributes to having this sort of problems.
Not all players in the field are helpful (e.g. some major Certification Authorities). If you're a developer who doesn't know much about certificates and try to learn from the documentation you get from a CA's site, it's often difficult. (The classic one is that most CAs imply that they provide certificates that perform 256-bit encryption, which is misleading at best. Others have FAQs that are full of mistakes and/or misleading information. Others let you buy "an SSL" (see bottom of page).)