强化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证书时,找出与所请求域名匹配的证书.

使用acme.sh签发并使用Let’s Encrypt的EC证书

acme.sh是一个国人编写的、基于ACME协议的第三方的Let’s Encrypt证书管理工具.使用它签发EC证书较为简单.

1.使用Webroot模式签发证书

  1. 此方法依赖于运行中的http服务器(e.g. Apache httpd/Nginx),运行脚本前不要停止http服务器.
  2. Web根目录要对你当前登陆ssh的用户可写,因为acme.sh要在-w指定的目录下创建.well-known/文件夹并在其中创建文件,以验证域名所有权
  3. 可以通过多个-d指定多个域名,签发多域名证书
  4. ★重要:如使用此方法签发多域名证书,上一条所述的多域名在http服务器的vHost中必须设置相同的Web根目录,且为-w所指定的路径.一般而言,如同时签发domain.tld和www.domain.tld时可以这样做;而domain.tld和mail.domain.tld则不能,因为其不在同一个vHost下。

2.使用Standalone模式签发证书

  1. 对于单域名或多个Web目录相同的域名也可这样签发证书.
  2. 运行前务必停止[包括但不限于http服务器]的任何监听80端口的服务;如不确定80端口是否被占用,可使用netstat -lp|grep 80查看.
  3. 无需使用-w指定Web根目录.
  4. 所有由-d指定的多域名都需要解析到运行acme.sh的主机.

另注:-k能指定的所有公钥类型:

  1. -k {2048|3072|4096} 使用2048/3072/4096位的RSA密钥对.
  2. -k {ec-256|ec-384} 使用256/384位的EC密钥对.

继续阅读“使用acme.sh签发并使用Let’s Encrypt的EC证书”

“矫情”

七八年前,小学时的事,回忆或许并不很完整。

记得我上小学的时候学生间流行三种文具,但其实都并不实用

  1. 自带(Built in)密码锁的日记本(在女生中更常见)
  2. 多功能铅笔盒(在男生中更常见)
  3. 具有十几种颜色的『多色圆珠笔』

班里有个女生用这种带密码锁的日记本,并坚信其具有高安全性。

某日我碰巧看见她的”Highly Secured Diary”,发现其密码锁实际上只有6个按键,每个按键只有两种状态——”按下”和”未按下”,并且密码不能更改。换言之,这个日记本的密码仅有26=64种可能性,偷窥者只需要『暴力破解』即可无痕迹地偷窥其日记。

我向她提出这一点,她并不相信,并告诉我:

超市的导购都说了这本子绝对安全……

随后我用3分钟演示了『成功的暴力破解』,却没想到她却开始大吵大闹,说”我偷看她日记了”什么的,实际上我仅是解开了密码锁而并没有翻开那日记本丝毫。后来她向班主任”哭诉”此事,说什么”我恶意获取她的密码且其不能更改”云云,无病呻吟的功夫简直了得!

她的”哭诉”导致我几乎被班主任怒斥一下午,她的申诉老师全当真,不加丝毫考证;而我的辩解则全被当作”撒谎”……

2017,不知这博客还会继续存在与否

离2017年2月14日——这个博客建立三周年已经不到一个月了,虽然准确些说是2月16日*1

三年间博客上将

  1. 未公开的文章
  2. 没写完的文章
  3. WordPress安装时就存在的文章(世界,你好!)
  4. 已发表的文章

一并计入其中共有104篇,如果除去上述前三者恐怕还不足100篇。

我不得不扪心自问,我建立这个博客后对它投入了多少时间与精力,又有几何真正用于写作,书写这个博客建立初衷中所提到的那些东西——生活见闻与内心感想?

而发表的文章起初(2014年初)还以生活见闻为主,再后来重心逐渐偏向技术类,这在我的博客的介绍页面(关于小站)中也有所提及:

2014年6月 ……同月,博客主要内容开始由在校与日常生活转为技术话题.同时开始尝试修改CSS与学习PHP.

我的博客不应该作为一个技术型社区或是某软件Manual或Document的替代品,诚然我也并无这般水平。

有人说『互联网精神』之一是共享,我的个人博客中尽是这些内容,很正常,很好。我对此持不同观点——如上文所属,技术指南应该参见官方的Documents,因为这永远是相对全面且更新及时的,至少相比我发表的文章中所描述的『搭建生产环境的过程』是这样的。

也许因为从2016年6月底我的一系列关于大学、未来与前途的错误决断*2,让我的世界充满各种阴暗与负面的事物,且我不打算将我的博客当作发泄『负能量』的垃圾堆,也许这是这个博客里本应存在的东西出现的频率走低甚至完全不复存在的原因。

同时,这也暴露了我投入到这个博客上的时间具体的去向,2016年10月弃用虚拟主机而转用Personally-Managed的VPS,得到更多选择自由的同时也变得更加time-sucking。投入到博客的时间,具体言之,投入到了如下方面:

  1. 对付进行破坏行为(发表垃圾广告评论/暴力破解密码)的无聊人士*3
  2. 优化Web服务,e.g.:
    • 在Qualys SSL Labs上取得A+评价
    • 部署HTTPS Public Key Pinning(失败,且由于HSTS的存在让部分用户在清除缓存前无法访问)
    • 建立Gravatar的镜像
    • ……
  3. 折腾各种在虚拟主机上无法体验的新鲜事物(e.g. PHP7.1)

博客存在的目的便是写作,或是记录。时间近乎全都投入到技术领域,博客意义何在?若无法重拾初衷,此博客便无存在之意义了。


*1.2月16日:2014年2月14日我购入主机与域名,但因域名信息填写不完整而无法解析,故博客真正建成是在2014年2月16日。
*2.关于大学、未来与前途的错误决断:简而言之就是高考志愿填报失误所带来的一些列后续影响。
*3.此类无聊人士的行为是我在2016年10月不得不将博客搬家到VPS的原因,在博客因故再次搬家中有所提及。