升级到MovableType 6.2.4

这个安全维护版本其实在2月24日就发布了,不过在我使用的MovableType 6.2.2的后台,并没有相关的消息提示,直到刚才特意去官网看看有什么变化才了解到。
根据新版的 release notes,这是一个安全维护版本,中等等级的。

Medium: An issue involving XSS on the new upload dialog has been fixed. This issue occurs on 6.2.x versions only.

同上传媒体文件的对话框有关的。

升级的过程乏善可称,就简单截图介绍了。
1) 下载安装包 MT-6_2_4.zip
文件包大小为15,016KB。我是登录到其 jp 用户站点,在自己的账号下下载的。为便利我这里也提供一个下载点。
下载前,必须阅读授权并同意才能下载。
http://ul.to/d6x88130

2) 解压缩,并复制所有文件覆盖原来的安装目录。
当然事先要做好备份,包括所有文件的备份和数据库的备份。

3) 打开浏览器,并输入MovableType的目录。比如 https://example.com/mt6/
就会自动显示升级完成的消息,也就是它自动的检查了升级文件并自动完成了升级。
2016-03-17_224205.png

4) 接下来点击并登录到网站后台就可以了。

如何验证 AMP 页面

验证 AMP (Accelerated Mobile Pages) 是非常容易的一件事,因为 AMP 页面是自带验证的,具体做法如下。

如何检查你的页面是否是合法的 AMP?

AMP 验证器是包含在 AMP JS 库里面的,所以验证的方法就是:

  1. 打开浏览器 Chrome
  2. 输入你的 AMP 页面的网址,并且在最后加上 "#development=1"
    https://seo.g2soft.net/AMP/2016/03/03/google-2.html#development=1
  3. 然后打开 Chrome DevTools console,查看验证结果。

如果页面是合法的,结果是这样的。

amp-validation-success.png如果页面是有验证有错误的,会显示这样的结果:

amp-validation-errors.png如何修复错误呢?

大部分验证结果中的错误都很容易找到原因以及修复的方法。比如上图中的错误,很快可以定位并修正它。

什么是 AMP?

AMP 的全称是 Accelerated Mobile Pages。 是一种为快速展示静态内容而制作网页的计划。

其起源是基于发布者和技术公司之间的研讨,改善移动内容的状况,包括发布者,消费平台,内容创建者和用户。它是一种开源计划。

使用 AMP 的好处是什么呢?

就是为能够提高静态内容的载入速度。研究表明,如果一个页面要10秒钟才能载入,那么其弹出率会高达58%。而使用 AMP 技术后的页面,能让用户更有兴趣投入到页面内容中。

Accelerated Mobile Pages 是如何工作的?

AMP 是另一种 HTML 页面,但是只允许使用有限的功能,这些允许的技术在开源 AMP 计划中都指明了。AMP 文件可以在所有的现代浏览器中打开。AMP所使用的技术确保了页面在载入的时候是速度优先,以提供更为快速的用户体验。

另外,AMP 文件还会被缓存到云端,以减少内容分发到用户的移动设备的时间。使用AMP格式,内容发布者允许第三方云端缓存内容,Google已经宣布它会提供缓存给任何人而不收取费用,所有的 AMP 都能被 Google 缓存。其它公司也许会跟进。

AMP 计划的时间表

2015年10月7日,AMP Project 宣布最初的技术细节,放在了 GitHub 上.

何种内容最适合使用 AMP?

目标是所有的发布内容,从新闻故事到视频,从 blog 到照片和 GIF图片,都可以使用。

一个对比测试

这是本站的一个页面,分别有两个版本,一个是普通的自适应页面,可以在不同的设备上正确显示内容的页面;另一个就是其AMP版本,页面的主体内容都一样。

对比的结果是很明显的。当然是 AMP 快,而且是非常的快。

404错误中看到的收获

本站有使用Awstats的网站日志统计,所以可以看到有哪些404错误的网址,刚才看了一下,按照错误出现的次数排列,挑出下面这些。
/3.gzip
/3.zz
就是各种 3 开头的压缩文件,不知道哪位使用 3 做压缩包,找到这里来的。还有很多以 2 开头的压缩包请求。

/plus/mytag_js.php
这估计是织梦系统的一个漏洞,可是本站没有用织梦系统。

/utility/convert/data/config.inc.php
这是Discuz! X系统的某个版本的漏洞所在,所以就有来查看看是否有问题了。

/module/action/param1/$(@phpinfo())
这是 ThinkPHP 框架的某个漏洞,也是来扫描漏洞的。

/nagiosxi/index.php
扫描服务器监控程序?

/resource/
/admin/
/conf
/log
/backup


自从去年开始,或者更早一点,网络传输的安全问题就成为了站长的一个考虑要点,因为有太多的情况会出现数据被修改,中间人攻击,监听,等等的因为网页是明文传输而受到的伤害。

Google作为业界领先的搜索引擎服务商,在2014年,就开始把加密网页,就是 https 页面,加入到搜索排名因素中去了。

http 与 https 只是不同的传输方案,一个用端口80,另一个用端口443。

现在 Google 已经决定,默认是收录加密网页。

如果一个网页,既有 http,也有https的外部链接网址从其它网站指向它,Google会抓取两种网址,不管哪种方式的链接更多都会相同的去抓取页面,如果Google发现所抓取的页面内容是相同的,只是纯粹的用了不同的端口,那么Google会收录https的网址。当然这也有一些先决条件:

  1. 网页不包含非安全的内容;
  2. 没有用 robots.txt 阻止抓取内容;
  3. 没有把用户重定向到非安全的网页;
  4. 网页代码中的 rel="canonical" 链接不是指向 http 页面的;
  5. 网页代码中不含有 noindex 的 meta 标签;
  6. 没有链接到普通的 http 网址;
  7. sitemaps 文件中包含的是 https 网址,而不是 http版本的网址;
  8. 当然,必须要有有效的证书。

网站迁移

鉴于服务器的整理,又在 DigitalOcean 新增加了一个VPS。
本站也迁移到新的服务器了。

如果可以看到本文,那么就表示已经完全同步了。

三月是一个新的开始。

从去年初就开始有越来越多的网站开始使用SSL加密了,但仍然有很多网站的站长因为担心SSL的性能问题而没有动手,他们倒不是担心成本问题,毕竟一个证书也没有多少费用,何况现在已经有了免费的证书可以使用。
那么这个对于SSL性能低下的担心是否是存在的呢?

他们担心的是因为采用SSL而造成网站的载入速度过慢。那么这里DavidYin就来探讨一下,就现有的网站优化技术来说,这个影响有多大,就算是对于那种大公司,比如Google,SSL的对于网站性能也只有非常有限的影响,比如对于网络所传输的数据来说只有不超过2%的增加,而对于CPU的负载更是小于1%。相对于SSL加密传输所带来的益处,这完全是不可比拟的。

当然要做到这么小的影响,而不是某些网站因为采用SSL,且没有做好优化措施,而带来超过几倍的性能影响,就要仔细的看看下面 SEO 网站优化给你的SSL性能优化建议了。

1) Session Resumption 会话重用

这是一种缓存技术,有两种做法,一种是在服务器端,把 session ID 缓存在服务器,客户同服务器比对 session ID,就不用来回多次验证了;还有一种做法是 Session ticket,相对而言,这比session ID 更好,开销小,并且服务器压力夜宵。

2) 采用 Elliptic Curve Cryptography 椭圆曲线加密算法

椭圆曲线加密(ECC)是一种加密技术,实现了以较小的密钥得到比较高的加密密级。ECC已被大多数的浏览器和服务器所广泛支持,但是必须要使用ECC的证书。

3) 启用 HTTP/2

之前可以用SPDY,现在就是要启用HTTP/2了。关于HTTP/2的益处这里就不赘述了,就是一定要用,就算现在不能在服务器上实施,也要时刻记得,只要服务器可以用,就马上配置上。它算是只有好处而没有坏处的技术了。

4) 证书启用 OCSP Stapling

这是用来向证书签发者验证SSL证书的有效性的技术,一般是浏览器需要额外向证书签发者请求验证,而 OCSP Stapling就可以省去该步骤,把有效性验证结果储存在服务器,直接返回给用户了。

SSL证书的相关知识

今天要写的是关于SSL证书的几个知识点,即是更新学习,也是与众分享。
1) SHA-1 与 SHA-2
SHA是散列算法,较早期的是 SHA,后来当SHA-2出来后就被称为SHA-1了。后来还有SHA-3等等。
其实在更早的时候,还有SHA-0,随着计算机技术的进步,现在SHA-0已被淘汰,SHA-1正在淘汰中,仍然有使用但越来越多的人开始使用SHA-2算法了。
通常现在常用的SHA-2其实是SHA256。
在SSL证书签发的时候,有一个签名散列算法,会用到这个,建议只用SHA256,而不要用SHA1算法。

2) ECDHE-RSA 与 ECDHE-ECDSA
这两个是密钥交换和协商算法,非对称加密算法。在SSL连接建立的一开始,有一个密钥交换和密钥协商的过程,这个过程中用到的算法有许多,这两个是现在用的比较多的两个。因为它们具有远期保密能力,或者是完美远期保密,Perfect Forward Secrecy。
完美远期保密使用的是一次性的密钥,不能从服务器的SSL密钥推算出来,也就意味即使SSL密钥日后被盗取,过去和将来的HTTPS通讯仍然安全,窃听者无法解密通讯内容。

这两个里面其实都各自包含两部分,第一部分是一样的,ECDHE,称之为 Elliptic Curve Diffie-Hellman key Exchange,是密钥交换协议,第二部分RSA与ECDSA是加密算法,RSA是非对称加密算法,由三个提出该算法的人的姓氏首字母命名,而ECDSA是Elliptic Curve Digital Signature Algorithm,是椭圆曲线数字签名算法。在服务器同浏览器协商的时候,用RSA还是ECDHA主要由SSL证书决定,如果证书是RSA算法的CSR (Certificate SigningRequest)签下来的,那么就是RSA证书,如果用的是ECC(椭圆曲线算法)算法的CSR,签下来的就是ECC证书。服务器上安装的证书并且正确的配置之后,当然用户浏览器也支持的话,就会得到相对应的算法。

3) SSL 与 TLS
可以把它们看成是一回事,都是加密传输中的重要协议。
SSL是安全套接层,现在已经被TLS(传输层安全协议所替代。因为SSL协议已经不再安全,SSL 从 1.0,2.0到3.0,现在已经被TLS 1.0,1.1,以及TLS1.2所替代,最新的安全协议是TLS 1.2。

4) AES_128_GCM
这是加密协议,是传输的数据所用到的加密方法。现在比较流行的就是这种了。被TLS1.2以及TLS1.3所支持,是被认为安全的加密协议。RC4是另外一种,已经被认为是不安全的,已不被使用了。 AES就是AES块加密算法的意思,128就是128位的密钥,GCM是 Galois Counter Mode,是AES的一种认证模式,被普遍认为延迟小,快速的方式。

所以现在要签发一个证书给web服务器,最安全的方法是这样:

上次有介绍了六个移动友好测试工具,今天再来介绍一个是微软出品,Bing搜索。
在站长工具集里有一个 Mobile Friendliness Test Tool。
首先打开工具网页,该网页网址是 https://www.bing.com/webmaster/tools/mobile-friendliness

然后输入要测试的网址到输入框,点击 Analyze ,稍等一会儿,就可以得到结果,主要测试了5个项目。

1) Viewport配置是否正确

2) 页面内容是否符合移动设备的宽度

3) 页面文字的大小是否适合阅读

4) 链接或者按钮是否足够大,大到可以用手指点按

5) Zoom设置,就是放大缩小是否允许。

另外,如果某些资源被 robots.txt 禁止也会报告出来。

bing-mobile-test.png如果综合看各种移动测试工具的测试标准,你也一定会得出自己的结论,有哪些是必定要的,哪些是可以尽量做到的,哪些是可有可无的。

全部文章归档