咬人的疯狗

数日前,我的QQ邮箱在短短2小时中不断收到多达2000多垃圾邮件,这些多是以Discuz论坛为主的各类网站的注册确认邮件。这甚至超过我从2008年底启用此邮箱后收到的、除已被删除的邮件数量总和。从发送速度来看一定是软件所为,其原理与”短信轰炸机*1“如出一辙。

我敢肯定近2年多以来我没在网络上结识仇人。换言之,我不认识任何知晓我的E-mail地址且有动机对我进行『邮件轰炸』的人。

而这次事件持续时间很长,长达12小时,看来并不像恶作剧*2。于是我倒回刚开始收到垃圾邮件的时间点,果不其然发现了一封由126邮箱发来的电邮,内容是一人的身份证正反面照片。

我没有任何理由收到这样的邮件,加之我的QQ邮箱是<一串数字>@qq.com,因此对方很有可能是输错了数字导致这封邮件被发至我的邮箱。而他对我『邮件轰炸』的目的,大概是为了”淹没”这封由于他的失误或会导致泄露他人个人信息的邮件,或者令这封邮件和那些垃圾邮件一并被我删除。

我向此人发送邮件说明我并未保存这两张图片,并已将其删除,希望其停止当前行为。但是他给我的回复如下:

你怎么证明你没留存?!!!
如你不能证明我不会停止!!!

每句话后面的三个叹号足以看出此人气急败坏。而他对我的要求,就像”证明你妈是你妈”一样,是一个不可能证明的问题——即便我把我邮箱的登陆凭据给他,让他亲自看,他还可以诡辩——我把照片保存到我的计算机了……

他的邮件地址无法提供任何有效线索——也是一串数字,但既不是手机号码,也不是QQ号(至少不是主显帐号)。根据这封误发送的邮件内容,我猜测他服务于某个需要用户实名认证的企业,身份证上的人很可能是其客户,同时也是这家企业没做好信息安全工作的受害者。

两天过去,垃圾邮件不再涌入,看来暂时平息了……

事实上我也是一个没有任何过失的、无辜的受害者——如果我有过失,那也只能是使用了一个容易被”误输入”的邮件用户名……因此我将此事件形容为『疯狗咬人』。


总而言之,这个企业有许多不足,直接或间接导致了这场风波:

  1. 用电子邮箱传输敏感数据,且发送前不反复确认收件人地址
  2. 使用的电子邮箱没有『撤回邮件』功能*3
  3. 敏感信息通过互联网传输时没有加密——如果他用GPG加密了邮件,即便误发送也无虞
  4. 使用安全性能*4和使用体验*5极差的网易邮箱

而对于该企业的客户,也有如下不足

  • 没有在身份证照片上添加水印以减少以外泄露带来的隐患

^ *1.收集许多需要用手机号/邮箱注册的网站,模拟其注册时发送的POST包来让某个手机号/邮箱收到大量垃圾短信/垃圾邮件的软件,常被无良电商用作报复填写差评的用户.
^ *2.曾有报道因个人信息泄露,有人手机”被DDoS”——不断接到响一声来电使正常电话打不进来,后此人被勒索数百元赎金才可停止这种行为.
^ *3.许多邮箱,包括我使用的Gmail和QQ邮箱,都可以撤回已发送但对方未读的电邮.可以说的上是邮箱的标配功能.
^ *4.网易邮箱发送的邮件底部包含不可去除的广告,常被收件人的邮箱系统归档至垃圾邮件.
^ *5.网易邮箱宣称使用SSL确保信息安全,但仅是POST登陆凭据的URL使用了https,而登录页面为http.这种情况下攻击者只要在页面中插入一个恶意JavaScript便可获取用户名和明文密码.且网易邮箱并没有使用SSL或S/MIME来确保邮件在传输过程中安全.

编译安装Apache httpd

几周前遇到的一个问题,需要在Ubuntu VPS上编译安装Apache httpd,并满足如下要求:

  1. 覆盖由包管理器(Debian apt)安装的版本
  2. 使用非操作系统提供的OpenSSL
  3. 使用最新版本的nghttp2*1
  4. 可执行文件名称与Debian apt安装的一致,为apache2(默认编译后为httpd,与CentOS的一致)

有这样的需求是因为这台VPS上的一个VirtualHost需要支持RC4及3DES等过时的加密套件,而最新的OpenSSL 1.0.2k需要在编译时添加参数enable-weak-ssl-ciphers才能启用.在尝试多种方式均未果后*2,编译安装并覆盖原版Apache httpd.


安装APR

安装APR-util

安装PCRE

安装OpenSSL

安装nghttp2


安装httpd

起初我将所有模块(Modules)以动态(shared)形式编译:

如此安装后,试图启动apache2时却报了错,检索错误信息发现是没有加载mod_unixd导致的.用LoadModule命令将其加载后还是报错,这回变成配置文件中定义日志格式的LogFormat语句不能识别。

于是重新安装了包管理器提供的apache2,并对比/usr/lib/apache2/modules目录,发现自己安装的版本多出了5个文件:mod_log_configmod_logiomod_unixdmod_versionmod_watchdog,这5个模块本应被静态(static)编译,并不需要用LoadModule来加载。这解释了启动时报错的原因。

于是重新编译,将这5个模块静态编译

这次启动apache2时不再报错,但是用nmap扫描加密套件,发现仍无法启用3DES.似乎所指定的OpenSSL目录并没被使用.后来发现ivan ristic*3.的一篇博客文章[1]提到了--enable-ssl-staticlib-deps这个编译参数,且在其文章中,mod_ssl也被静态编译.于是又进行了新的尝试

由于mod_ssl被静态编译,不再需要用LoadModule加载,因此还要加这个语句注释掉

再启动apache2,没有报错,3DES的加密套件也可用.


^ *1.一个以C语言编写的http/2库,Apache httpd的mod_http2依赖于它.
^ *2.包括重新编译OpenSSL及在此前提下用apxs重新安装mod_ssl等.
^ *3.SSL配置教学书籍《Bulletproof SSL》的作者.
^ [1].https://blog.ivanristic.com/2013/08/compiling-apache-with-static-openssl.html

华而不实 为所欲为

近期,华为P10的”各种门”,包括闪存和内存被偷换为低规格的型号以及屏幕缺少疏油层,在网络上炒得沸沸扬扬。

关于偷换零件,华为官方声明为『不影响使用体验[1][2]』,并指责为友商抹黑[3],后又暗示国外供应商在供应链上”卡脖子”[9]所以才被迫使用不同规格的硬件。

关于疏油层,官方宣称『疏油层改变介电系数,影响电容式指纹传感器;且P10使用康宁大猩猩5代玻璃作为屏幕面板,足够耐磨与抗摔[1]』。而没有疏油层的影响是油脂(和水渍)易残留于屏幕,影响透光率


对于前者的声明,对硬件稍有知识的人便能看出,这是不可能的。就好比两台计算机其他参数完全相同但分别使用SSD与HDD,使用体验不可能相同.

而对于后者,官方的解释可谓是”驴唇不对马嘴”。况且粗粮在4月19日发布的新品采用与P10相同的指纹解决方案,却不存在『没有疏油层』的情形[4]

华为海军更是在”司令”(微博@HW前HR等)号召下倾巢出动进行洗地,其间水军也制造了一些可笑的事*1[5][6]。此外,前HR还对小米6进行了毫无证据的抹黑,宣称使用UFS2.1的小米6加载软件、拷贝文件都比使用eMMC的P10慢,却没有评测视频等支持此说法。还引用无法自圆其说的@奥卡姆剃刀*2关于MIG-25战斗机来论证所谓”系统科学”[7],毫不顾计算机系统中的”木桶效应”*3.还宣称”不欢迎”非华为手机用户与他讨论此事[8].


上一次手机行业中『厂商或产品受到消费者严重不满』的应该是2016年8月发布的、存在『爆炸门』的三星Galaxy Note7.如果将三星和华为做一个对比:

  • 相同点
    1. 引起了消费者强烈的不满
    2. 没有做到妥善处理,企图掩盖事实、让消费者闭嘴、淡化影响
      • 华为:水军洗地,”使用体验无影响”论,为自己开脱,态度傲慢不回应消费者质疑.
      • 三星:给”封口费”,威胁起诉不收封口费并曝光的用户.
  • 不同点
    • 华为:问题的产生是有意的,且官方在至少半年前就有所准备
    • 三星:问题的产生是无意的(恐怕不会有手机(或电池)厂商有意生产会爆炸的电池.)

为何说华为这次偷工减料,是从半年前就开始谋划的呢?

首先,eMMC与UFS的连接界面完全不同[10],前者使用并行总线,后者为串行总线。这意味着,早在2016年10月华为发布『麒麟960』SOC时,就计划让其支持两类闪存了。

此外,华为Mate9在发布时宣称使用UFS2.1,而有用户发现存在使用UFS2.0的Mate9。华为仓惶地在全球范围撤下Mate9宣传网页上”使用UFS2.1高速存储”字样[11].


[1] http://weibo.com/1100856704/EFkQcBbEY
[2] http://weibo.com/1100856704/EFlle0mtg
[3] http://weibo.com/3032210184/EFeV64vhC
[4] http://weibo.com/1796445350/EFo5lxCSz
[5] http://weibo.com/ttarticle/p/show?id=2310474098710077363582
[6] http://weibo.com/1637739707/EFECSBwtv
[7] http://weibo.com/3626485974/F0Mmcd9KD
[8] http://weibo.com/3626485974/F1pyLvP8F
[9] http://finance.sina.com.cn/roll/2017-04-21/doc-ifyepsea9916387.shtml
[10] http://www.elecfans.com/consume/509662.html
[11] http://www.expreview.com/53673.html


*1.使用搜索引擎搜索”XXY41902″——此为华为海军识别”友军”所使用的代码,推测含义为”信息员4月19日第2组”。几乎所有在余承东微博下发表洗地评论的大V(认证用户),都在其微博首页上发表过包含这类前缀的微博。类似的还有”尖锐湿疣”等.
*2.实为石家庄军械工程学院张弛,对通信行业略知一二,对信息技术可以说不甚了解;曾企图冒充北京邮电大学教授;其所做的数篇文章,包括关于”奥运会举重运动无用论”、”传统手机是用指纹解锁的风险”(实为华为Mate 9的软广告.)、”批评国际标准化组织阻挠推广WAPI”、”手机银行客户端在不安全网络下的安全性”等,被人指出有严重漏洞后,死角蛮缠、出口成脏,更宣称”只有粉丝10W以上的大V有资格和他辩论”
*3.一个典型例子是为老旧计算机添加SSD后能极大程度提升软件和操作系统加载速率.

强化SSL密钥交换与性能优化

为强化SSL的密钥交换,我们或会考虑使用4096位的RSA证书、384位的EC(DSA)证书和384位的ECDH密钥交换;但性能需要被考虑进其中。

以下一组数据使用openssl speed命令在我的VPS上测出。

其中可看出,强化密钥交换后的配置性能大大降低,有时甚至达一个数量级。而现在认为,RSA-2048与的EC-256*1(包含用于签名的ECDSA和用于密钥交换的ECDH,下同)已经足够安全,没必要使用RSA-4096与EC-384*1

但对于个人网站(的并发访问量),即便是用RSA-4096与EC-384,也不至对服务器的性能需求增高。

综上,更需要安全性可以考虑强化密钥交换。但许多证书链中的CA证书都是RSA-2048或EC-256,域名证书使用RSA-4096或EC-384似乎并无意义.*2


*1.EC-256等效于RSA-3072;EC-384等效于RSA-7680
*2.如CA证书私钥被暴力破解,攻击者可以用于(未经授权地)签发任何域名的证书.因而,安全性高于CA证书的域名证书『似乎并无意义』

考虑停用HTTP/2

近期访问本站,经常会出现421 Misdirected request的错误码,究其本源,是由于HTTP/2的某些特性和多域名(多SAN*1)证书冲突造成的.

Google以下这个421错误码+Apache的关键字,找到官方解释:

https://httpd.apache.org/docs/2.4/mod/mod_http2.html

Multiple Hosts and Misdirected Requests

Many sites use the same TLS certificate for multiple virtual hosts. The certificate either has a wildcard name, such as ‘*.example.org’ or carries several alternate names. Browsers using HTTP/2 will recognize that and reuse an already opened connection for such hosts.

While this is great for performance, it comes at a price: such vhosts need more care in their configuration. The problem is that you will have multiple requests for multiple hosts on the same TLS connection. And that makes renegotiation impossible, in face the HTTP/2 standard forbids it.

So, if you have several virtual hosts using the same certificate and want to use HTTP/2 for them, you need to make sure that all vhosts have exactly the same SSL configuration. You need the same protocol, ciphers and settings for client verification.

If you mix things, Apache httpd will detect it and return a special response code, 421 Misdirected Request, to the client.

译:多(虚拟)主机和错误定向的请求(问题)

许多站点为多个虚拟主机(vHost)使用同一个TLS证书。这个证书要么包含通配符,比如”*.example.org”;要么包含多个SAN(译者注:即可用于多个域名)。支持HTTP/2的浏览器会辩认出这点(多个vHost使用相同证书)并为这样的主机复用已建立的(TCP)连接。

这对(提高)性能来说是极好的,但也有代价:这类vHost的配置需要更多的关注。问题在于你对(多个)不同的vHost的不同请求是通过同一个TLS连接所发送的。这将造成无法重协商(renegotiation),而且是HTTP/2标准导致其无法完成(重协商)。

所以,如果你有多个使用相同证书的vHost且打算让它们支持HTTP/2,你需要确保它们具有完全相同的SSL配置——相同的(TLS)协议、相同的加密套件和客户端验证设置(编者注:用于双向验证,一般站点不需要)。

如果有混合(多种)配置,Apache httpd会检测到这种情况并给客户端(浏览器)返回一个特殊的HTTP状态码——421 Misdirected Request

我没有使用多种SSL配置,所有站点的SSL配置(TLS协议、加密套件)均是由mod_ssl的配置文件决定的,不存在『使用同一证书的多站点SSL配置不相同』的情形,但这个421 Misdirected Request就是出现了。

HTTP/2中的TLS会话复用似乎是为了提高性能,而我使用多SAN的证书则是因为要考虑站点对老旧的、不支持SNI*2的浏览器的兼容性。


*1.SAN:Sub Alternate Name,子可选域名.多域名证书会包含多个SAN.
*2.SNI:Server Name Indication,服务器名称指示.支持SNI的浏览器可以在服务器发来多个TLS证书时,找出与所请求域名匹配的证书.