煎蛋今天有人发文《研究者称部分 Android 应用有严重安全漏洞》：
http://jandan.net/2012/10/22/massive-encryption-faults.html 。
感觉翻译老是不准，后来找到了原英文报道：
《Android apps used by millions vulnerable to password, e-mail theft》“Researchers uncover faulty encryption in apps available in Google's Play Market”（翻译：《google play市场上百万装机量的安卓应用存在密码和email被盗的漏洞》“研究者披露google play市场中各种应用使用的错误加密方式”）。：
http://arstechnica.com/security/2012/10/android-apps-expose-passwords-e-mail-and-more/
这篇英文报道相对清晰点，主要是探讨安卓应用开发中使用HTTPS/SSL不当引发中间人攻击问题。文章还附送了研究原文和链接：《Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security》（为什么Eve和Mallory会喜欢攻击安卓：关于android中应用SSL的安全研究）
http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf
（Eve和Mallory的解释请见此：http://zh.wikipedia.org/wiki/%E6%84%9B%E9%BA%97%E7%B5%B2%E8%88%87%E9%AE%91%E4%BC%AF）
至此，总算找到原出处。简单翻译此研究文档如下：
（一）研究人员开发了一个在Androguard工作的扩展MalloDroid，用于静态提取和分析反编译后的app
（二）抽取样本为13,500个在google play市场上受欢迎的应用
（三）MalloDroid在这13,500个应用中提取到195,405个有效且实际使用的URL，合计25,975独立域名。
从应用统计来讲，5,810个应用(占43.0%)根本没有使用https url；6,214个应用(占46.0%)中既存在https url也存在http url；只有111个应用(占0.8%)全部使用https url。
（中间其它统计略，请看原paper，好多...）
静态分析表明，1,074个含有SSL/TLS代码的应用(占8.0%)存在潜在的中间人攻击可能。
（至于那5,810个应用，不是研究者的范围，估计是觉得不上https的应用都不是高价值应用吧，囧...）
（四）研究人员在三星Galaxy Nexus（Android 4.0）上手工审计100个存在潜在漏洞的手机应用，攻击方式为wifi SSL代理中间人攻击，其中SSL代理中的证书有两种，一种是自签名证书（不受信任证书），另一种是CA签名（受信任证书）、但和app要访问的域名不相关。
测试发现，共有41个应用中招，其分类的中间人攻击漏洞如下：
（A）信任所有证书（Trusting All Certificates）
21个应用中招。当SSL代理中的证书为自签名证书时，应用仍然通过访问，导致中间人攻击生效，传输的信息泄露。
（B）信任所有域名（Allowing All Hostnames）
20个应用中招。假设应用要访问的是https://www.paypal.com，但SSL发过来的证书所签发的域名是some-domain.com，那么仍然通过访问而不验证证书签发的域名，导致中间人攻击生效，传输的信息泄露。其中杀毒软件部分比较有趣，就是通过这个漏洞，在升级时既可以清空病毒库（关闭杀毒功能的高招啊），又可以将自己的特征码恶意添加进去，导致自己报自己为病毒。
这部分的漏洞，报道（无论英文原文报道还是煎蛋翻译）都只报道了这部分漏洞。
（C）恶意SSL内容篡改（SSL Stripping）
2个应用中招。这个问题的起源是，有部分应用是通过打开http页面，然后通过此页面转入https流程的。那么在http传输的过程中，将https链接或者请求相关的内容全部篡改成http（或其它可以接受信息的url），那么就可以得手敏感信息了。这部分在android浏览器应用普遍存在，但也影响使用webkit.WebView的应用。
（D）没有采用SSL pinning（Lazy SSL Use）
这个SSL pinning不知道怎么翻译（证书绑定和校验？），而且理解也不是很到位。大意是说，如果没有采用SSL pinning，那么当手机导入了自定义根证书时，那么应用就不会再检查服务器发过来的证书，从而导致漏洞产生。
这部分选取了20个应用进行独立测试，选取标准为明显不容易实施在之前提及的中间人攻击。结果只有两个通过。
解决方法是，进行SSL pinning，确保服务器发过来的是就是你的证书。
（E）提示和反馈缺失（Missing Feedback）
这个更多似乎是个漏洞或者是bug集合：
提供了SSL连接设置但实际不生效；
某邮件app的默认选项不是使用HTTPS连接，而且用户并不知情或者说没有引导；
采取https登录获取登录凭据以保护密码，但后面采取http传送登录凭据，导致可以实施重放攻击；
某框架采取http明文传输远程代码并调用dalvik.system.DexClassLoader运行，实施什么攻击你懂的；
有53个应用不受中间人攻击，不过期间提示信息不明确或者直接崩溃，有6个应用则提示了证书相关错误，但仍然无法提示用户正在遭受攻击，只有facebook官方应用的错误信息显示是研究者推荐的（这这这......我可以祭出“用户体验”反驳么？）
（五）研究者还做了个在线调查，其主题关于android浏览器中的证书警告和https可视化安全指示。结果表明，754个受访者中有一半不能正确判定他们的浏览器是否受到SSL/TLS保护。
（六）研究者最后提出了自己的建议
（但是很晕的是，建议都是针对OS层面和市场层面来讲的，对应用开发的建议......都！没！有！汗......）
==============================
好了，此文还是值得平台开发者、手机开发者留意一下的......