本博客正式支持HTTPS/SSL浏览(powered by Let's Encrypt)

今天起,本博客已经正式启用https/ssl,页面上链接已经更新为https链接。

使用的是Let's Encrypt提供的免费ssl证书服务。

Let's Encrypt服务优势

免费、支持多域名、国际化,并且服务商是Linux基金会成员,可信度高。

目前主流浏览器都支持该证书的,参看官方的“证书兼容列表”

负面影响评估

以GA上最近1万(准确数字是10523)次会话作样本做评估,GA只计算“人”的访问,而不计蜘蛛,这更符合现实。(可以认定,主流的搜索引擎蜘蛛应该是支持该证书的,这个影响按理可以忽略。)

按网友的经验IE6是不支持的,经过虚拟机下windows 2003里IE6测试证实了这一点(手上没带IE6的xp)。样本会话中共计10次IE6,9次IE7;由此IE6占比不到0.1%即使带上IE7,也不到0.2%. 因此旧版IE可以忽略。

Safari 4.0以下无访问。

 

Let’s Encrypt HTTPS证书申请部署与自动续期/免费ssl,nginx,centos

一年半以前曾经买过一个廉价的https/ssl证书,部署在本博客blog.path8.net上,时间大概在 2015-5-17,然而并没有正式启用,以至于过期也都没有注意。前几天想于把这个事情搞起来。以前的经验是,廉价ssl证书都是只对一个域名有效,但竟然发现Let's Encrypt的免费证书,还是多域名的。近一年的新文章里,有不少人对之大加赞扬;于是准备试试。同时也发现了腾讯云也有免费ssl证书,单域名的,免费一年,试用了一下,签发速度比较快,部署到本站上。不过还是决定使用Let's Encrypt。下面是简单记录。

vps环境CentOS 6.x, niginx

花了半天时间研究Let's Encrypt的相关文章(基本都是中文博客),另外尤其仔细读了其官方网站,开始实际操作,发现真的很简单。

ssh登录到服务器上操作,并且操作需要需要root权限。

1. 自动部署脚本需要epel源,如果之前没有安装先安装之 yum install epel-release

2. 在线获取签署脚本(按自己的习惯保存到合适目录)。签署脚本官方称之为客户端,有多个版本,这里使用的官方推荐的 certbot

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

3. 运行签署脚本。脚本里注意两人参数 -w, -d,分别是一个web目录及该目录对应的域名;多组目录就多次指定。这里只是获得证书文件,不做自动部署。(猜测是因为该脚本不支持nginx的自动部署,毕竟nginx不在centos官方源里,不同服务器上安装方式 不一样)。如下所示。

./certbot-auto certonly --webroot \
-w /var/www/html/blog.path8.net/html -d blog.path8.net \
-w /var/www/html/www.path8.net/html -d www.path8.net -d path8.net -d fengyqf.com

4. 接下来会自动通过yum安装几个依赖包,同意即可。

5. 然后是几步交互式对话:邮箱地址、同意条款、照着操作即可。因为Let's Encrypt是自动签署,速度非常快,大概整个过程只花费了两三分钟(包括交互过程里等待用户操作的时间)。

letsencrypt_req_email

交互询问邮箱地址

按其他网友的文章所说,使用国内dns服务很容易引发域名解析失败;此次使用dnspod却是一次成功的。成功后消息如文后。

在目录里 /etc/letsencrypt/live/{your.domain.ext}/ 得到四个文件:cert.pem chain.pem fullchain.pem privkey.pem  。简单理解,前两个是给Apache用的,后两个是给Nginx用的。(注意 privkey.pem 这个文件是私钥,内容千万要保密!)

事实上这四个文件是到/etc/letsencrypt/archive/{your.domain.ext}/ 下文件的符号链接。从结构上看,更新证书时,会自动更新符号链接目标。

按脚本执行的输出,运行日志记录在 Saving debug log to /var/log/letsencrypt/letsencrypt.log

下面是签署脚本成功执行后的消息。

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/blog.path8.net/fullchain.pem. Your cert will
   expire on 2017-01-14. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot-auto again. To
   non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to f***@gmail.com.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

6. 部署证书文件到nginx上。主要是ssl_* 的行,指定为证书目录。

    server {
        listen 80;
        listen 443;
        ssl on;
        ssl_certificate  /etc/nginx/ssl/blog.path8.net_cert.crt;
        ssl_certificate_key  /etc/nginx/ssl/blog.path8.net.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        location / {
                index  index.html index.htm index.php;
                # from nginx.org rewrite rule
                # This is cool because no php is touched for static
                try_files $uri $uri/ /index.php;
        }
    ......
    }

7. 重新加载nginx配置,或者重启 nginx -s reload  ,然后测试https访问。记得iptables放行443端口。

8. 如果需要,将80端口301重定向到443.

9. 配置定时任务以自动更新证书。重新签署证书及加载证书,将脚本加入到定时任务中,/path/to/certbot-auto renew --quiet  . 重新加载nginx配置以应用新证书的脚本如  nginx -s reload

天啊,SSL潜在重大危机:CNNIC CA:最最最严重安全警告!

CNNIC CA:最最最严重安全警告!

转于:http://autoproxy.org/zh-CN/node/66

由 WCM 于 星期一, 2010-02-01 20:00 发表

各位,虽然此事与 AutoProxy 无关,但它对所有(也包括 AutoProxy)用户都是一个非常严重的安全威胁。我,WCM,AutoProxy 作者,以个人名誉强烈建议您认真阅读并采取措施。

背景知识

网上传输的任何信息都有可能被恶意截获。尽管如此,我们仍然在网上保存着很多重要的资料,比如私人邮件、银行交易。这是因为,有一个叫着 SSL/TLS/HTTPS 的东西在保障我们的信息安全,它将我们和网站服务器的通信加密起来。

如果网站觉得它的用户资料很敏感,打算使用 SSL/TLS/HTTPS 加密,必须先向有 CA (Certificate Authority) 权限的公司/组织申请一个证书。有 CA 权限的公司/组织都是经过全球审核,值得信赖的。

发生了什么事

最近,CNNIC——对,就是那个臭名昭著的利用系统漏洞发布流氓软件的、就是那个使劲忽悠 CN 域名又突然停止域名解析的 CNNIC (中国互联网络信息中心),它——偷偷地获得了 CA 权限!在所有中文用户被隐瞒的情况下!

意味着什么

意味着 CNNIC 可以随意造一个假的证书给任何网站,替换网站真正的证书,从而盗取我们的任何资料!

这就是传说中的 SSL MITM 攻击。以前这个攻击不重要是因为攻击的证书是假的,浏览器会告诉我们真相;现在,因为 CNNIC 有了 CA 权限,浏览器对它的证书完全信任,不会给我们任何警告,即使是造假的证书!

你信任 CNNIC (中国互联网络信息中心) 吗?你相信它有了权限,会安守本分,不会偷偷地干坏事吗?
我对此有3个疑问:

  1. 某 party 对 GMail 兴趣浓厚,GFW 苦练 SSL 内功多年,无大进展。如今有了 CA,若 GFW 令下,CNNIC 敢不从否?
  2. CNNIC 当年利用所谓官方头衔,制流氓软件祸害网民。如今有了 CA,如何相信它不会故伎重演?
  3. 为了得到指定网站的合法证书,其它流氓公司抛出钱权交易,面对诱惑,CNNIC 是否有足够的职业操守?

影响范围

基本上所有浏览器的所有用户均受影响!

行动第一步:立即安全防御

在此只介绍 Firefox 浏览器的防御方法,其它浏览器的用户请自行 Google,原理类似。

  • 菜单栏:工具/编辑->首选项->高级->加密->查看证书->证书机构(Authorites)
  • 这是一个很长的列表,按照字母顺序,你应该能找到一个叫着 "CNNIC ROOT" 的记录,就是这个东西,告诉 Firefox,我们不信任它!
  • 选中 CNNIC ROOT,点击下面的“编辑”按钮,弹出一个框,应该有3个选项,把所有选项的勾都去掉!保存。
  • 还没有完,狡兔有三窟。
  • 接着往下找,有一个叫着 Entrust.net 的组,这个组里应该有一个 "CNNIC SSL" (如果没有,访问一下 这个网站 就有了)
  • 别急着下手,这回情况不一样,这个证书是 Entrust 签名的。我们信任 Entrust,Entrust 说它信任 CNNIC,所以我们就被迫信任 CNNIC SSL 了。找到 "Entrust.net Secure Server Certification Authority" 这一条,同上面一样,把3个选项的勾都去掉,保存(提示:取消了对 Entrust 的信任以后,可能会没法打开它签名的某些正常网站。至于哪个网站用了它的签名,随便试了一下,没找到例子)。
  • 最后,让我们验证一下。重启 Firefox,打开 这个这个 网站,如果Firefox 对这两个网站都给出了安全警告,而非正常浏览,恭喜,您已经摆脱了 CNNIC CA 的安全威胁!

行动第二步:治标还需治本

几天前听到这个消息的时候,我简单地、轻蔑地将 CNNIC 删除了事。可是这个周末,我忽然觉得这样很不好。因为只要它存在,始终会有大部分的用户受到威胁。和写 AutoProxy 时同样的想法:如果大部分人都处于安全威胁当中,一个人苟且偷安又有什么意义?如果不能将自由与安全的门槛降低一点点,所谓的技术又有什么好侥幸的?

所以我呼吁大家,贡献一点时间和知识,团结起来说服各浏览器取消 CNNIC 的 CA 权限。这种事不可能有公司来推动,只有我们社区。

首先推荐的是 Firefox,作为一个公益组织 Mozilla 的决策过程更为开放、更愿意听取社区的声音。Bug 476766 记录了事件的全过程。Bug 542689Mozilla.dev.security.policy 进行着现在的讨论(注意,你可以把自己添加到 Bugzilla 的 CC List 以表达你对此事的关切。但是不要随便说一些不靠谱的话,免遭讨厌。强调政治、GFW 的之类的不管用,必须就事论事。比如它在申请过程中采取欺骗、隐瞒的手段,或者申请成功后的某些行为违反了 Mozilla 的 CA 政策;比如它的属性和过往行为表明它不会忠于自己的职责,而(帮助)做出 MITM 这种 CA 共愤的事情)。

其次是 Entrust,它说它信任,导致了我们也被迫信任 CNNIC SSL。不妨 告诉 Entrust 此事很严重,因为它 错误地信任了 CNNIC,大量用户不得不删除它的 CA。如果能找到使用 Entrust 证书的网站更好。给这些网站写信,因为此次事件我们不得不删除了 Entrust 的 CA,请求他们另选别家认证。如果反响强烈,势必给 Entrust 造成很大压力。

除此之外,来 投个票吧结 果统计)!

最后,强烈建议大家,发现证书警告的时候最好直接关掉,不要轻易添加例外。证书的信任体系是一级依赖一级的,一不小心你可能就会连带信任一个不想信 任的 CA。上面用于验证的两个网站,不妨定期(每周/每月)测一测,如果哪天你发现其中的任何一个网站没有证书警告,就要注意了!

各位:
DNS 劫持已然成为常态,不要让 SSL 劫持再次普及!此事刚刚发布,尚有评议空间。待时间流逝,你我皆成温水中之青蛙!