Amazon CloudFront 已经支持椭圆曲线证书来连接源

  • Posted on | Updated on
  • by
  • in

在2016年,我有写过一篇有关 Amazon CloudFront 只支持有限的几个加密算法,来连接到定制源的问题。

当时是这样的:

Amazon CloudFront 要求的加密算法:

  • ECDHE-RSA-AES128-SHA
  • ECDHE-RSA-AES256-SHA
  • AES256-SHA
  • AES128-SHA
  • DES-CBC3-SHA
  • RC4-MD5

于是我就采用了双证书, RSA 和 ECC 两个证书的办法来解决。

最近发现我有添加 ECC 证书,Amazon CloudFront 没有出现 502 错误。于是我查看了一下 AWS 的最新说明。

从CloudFront 到你的源之间的通信,所支持的 SSL/TLS 协议和加密方式

CloudFront 要求源要支持下面列出的 ECDSA 和 RSA 加密套件,CloudFront 才能连接你的源服务器,并获取内容。

椭圆曲线支持 prime256v1 和 secp384r1

RSA 套件

  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • AES256-SHA
  • AES128-SHA
  • DES-CBC3-SHA
  • RC4-MD5

ECDSA 套件

  • ECDHE-ECDSA-AES256- GCM-SHA384
  • ECDHE-ECDSA-AES256-SHA384
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-ECDSA-AES128- GCM-SHA256
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-ECDSA-AES128-SHA

CDN 之比较 2018

  • Posted on | Updated on
  • by
  • in

原来想做一个 CDN 服务的比较的,甚至想包括国内的服务商,现在可能有变化,就先说一下我用过的几个好了。

首先说明一下,本站目前用的是 Amazon 的 AWS CloudFront CDN 服务。利益相关说明一下更好。

AWS CloudFront

cloudfront_logo.jpg

节点数量和布局

AWS 的内容分发服务网络,就到本文发布时,在18个地理区域有55个可用区。接下来,Amazon 计划在 巴林,香港,和瑞典再增设 12 个可用区和四个区域,并在美国设置第二个 AWS GovCloud 区域。

Amazon CloudFront 在 26 个国家或地区的 59 个城市中有 132 个接入点,用户在访问你在 CloudFront CDN 上的内容,实际上就是访问这 132 个节点中离你最近最快(延迟最小)的那一个。

免费服务部分

AWS 有个免费使用套餐,新的 AWS 客户在一年内每月均可以享受 50GB 的数据传输量和 2百万个 HTTP 和 HTTPS 请求。(这个免费套餐按月计,未用完的自动清零)

价格及收费

收费的基本方式就是按用户的数据传输量,和请求数量两个部分来计算。没有固定的平台费用,也无固定合约,绝对的是按使用量来付费。这里有个官方 AWS CloudFront 计费估算器

最低一档的 10TB 以内,US$0.085/GB 美国加拿大和欧洲,US$0.110/GB 非洲,US$0.170/GB 印度,US$0.250/GB 南美洲,US$0.140/GB 亚洲及澳洲。随着用量的上升,价格也会降低。请求数量的价格也是按照地区有所不同,从 0.0075/10K Requests 到 0.016/10K Requests,这是非加密的 HTTP 访问。如果是 HTTPS,价格则从 US$0.01 到 US$0.022 每一万请求数。

AWS提供两个账单,一个是收费账单,一个是使用量账单,可以很清楚的知道自己的账号下,哪些网站使用的量最大。付费是后付费,每月账单生成后,从信用卡扣款。

MAXCDN Stackpath

maxcdn.png之前我用过的 MAXCDN 已经被 Stackpath 收购,原先 Maxcdn 在 Wordpress 后台是非常容易添加使用的。现在原先的 Maxcdn 的用户仍然可以使用,维持原样。

节点数量和布局

StackPath 的全球网络在主要地区有45 个边缘节点,从布局来看也还可以,大致有美国东岸,西岸,以及中部,欧洲的九个主要城市,南美的两大城市,以及亚洲和大洋洲的的七个城市,当然中国只有从香港或者东京,首尔访问。

价格及收费,以及免费服务

Stackpath 所提供的 CDN 看上去也不错,每月10美元的价格提供高达 1TB 的流量,另外首月免费。觉得对于流量大的用户来说这是一个不错的选择。支持信用卡付款。

两个更新

今天对本站做了两个更新。

第一就是 Macmini OSX 发布了可用于 Movable Type 7.0 的 PostTwiOAuth 0.50。之前我有特地 Twitter 消息给他,请他更新,很快两周不到,他就发布了更新版。所以马上我就装上了。测试的 tweet 已经可以发出,现在发表新文章也应该可以的。

很奇怪,在编辑帖子的页面, PostTwiOauth 的那些相关信息都跑到页面的顶部,布局出现问题了。

这个插件的安装还是很方便的,下载,解压,然后上传到对应的目录,接下来登录到 MovableType 后台,在系统这里的 Plugins页面,启用该插件,然后到网站下,对该网站的 twitter 账号做一下配置。就可以了。

posttwioauth-enable.jpg

第二个更新,是MovableType 发布的补丁。这个补丁适用于 7.0 和 7.0.1。

百度搜索资源平台

  • Posted on | Updated on
  • by
  • in

先来说一下啊,住在加拿大多年,我已经没法使用国内的很多账号或服务,因为没有办法满足那些要求。

账号要求不合理

很久以前,就有申请使用百度站长服务,那个时候就是叫这个名字吧,现在叫做百度搜索资源平台了。最近登录的时候,看到要求完善账户信息,否则就没法做任何操作了。
都是必选项,必填项,真实姓名这没有问题;职务也可以;手机号,之前就已经认证过,用的是加拿大手机;邮箱也是可以的;QQ就很奇怪了,还有微信,这两个也算是必填项,很有可能没有啊,现在的小朋友就很少用QQ的,在国外的用这个的更少,微信用的还是很普遍的;最后一项是所在地,是一个下拉菜单选择,只有国内的省市直辖市,没有海外这个选项,对于海外站长,要不放弃,要不就是瞎选一个。

功能的有限性

在百度搜索资源平台的功能列表里,看上去功能很多,但大多华而不实,甚至有的必须要有熊掌号才能使用。

在数据引入部分:

链接提交,移动适配,MIP&AMP,死链提交,四项功能可以直接使用。
原创保护,就要有熊掌号才可以。

在数据监控部分:

索引量,流量与关键词,抓取频次,抓取诊断,抓取异常,Robots 都可以直接使用。

在搜索展现部分:

HTTPS认证,站点属性,站点子链,可以使用。

品牌词保护,无法使用。

在优化与维护部分:

链接分析,看上去正常,但没有任何数据。

网站体检,可以使用,但使用结果是推荐你使用百度云观测,而且很多内容它并不能检测到,而检测不到它就认为你这个没有符合要求。

网站改版,闭站保护,以及移动落地页检测,可直接使用。

Google 的移动优先收录策略

  • Posted on | Updated on
  • by
  • in

从今年三月份开始,Google 搜索就开始逐步改变其抓取,收录,排名系统,之前都是使用的桌面版的网站页面内容,而现在随着移动用户的增加,它开始转换使用移动页面的内容作为它的搜索索引依据。

根据官方的说明,来自 smartphone Googlebot 的抓取频率会明显的增加,这里我的判断就是,它还是会放出普通桌面的蜘蛛来抓取桌面版的内容。

使用了 Google Search Console 的站长们会收到 Email 通知,告知网站抓取收录的变化,如果轮到你的网站的话,因为这个变化,是一批批网站变化的。

对于一个有 AMP 版本以及非AMP 两个版本内容的网站,Google 还是倾向于移动版本的非AMP内容页面。
如果一个网站只有桌面版,那么也不用担心,桌面版内容页面还是会被正常抓取并收录的。

排名相关的问题

  • 移动内容收录会越来越多,但并不会因为是收录移动页面而排名更好;
  • 移动友好的内容在移动搜索结果中会排名较优;
  • 能够快速载入的内容对于移动和桌面用户来说,排名都会更好;
  • 在排名的众多因素中,相对于内容相关,移动友好,或者页面载入速度,都算是权重较低的因素。

mfi-email.jpg.png

Google Maps Platform 更新

  • Posted on | Updated on
  • by
  • in

收到 Google Maps Platform 的邮件,主要是通知新的价格和服务改变。
这次新变化是从今天开始。

  • 新的地图,路线,和地点功能。
  • 更新后的价格
  • 每个账号有每月200美元的免费使用额度。
  • 免费的24小时客服支持。
  • 更新的每秒查询限制
  • 新的 TOS

对于现有用户,如何应对这个改变,Google 有推出 面向现有用户的指南

过去,如果要使用 Maps JavaScript API 调用地图,可以使用无秘钥方式,就是不包含 API 秘钥或者客户端 ID 的请求,现在已经不再支持了,只会返回低分辨率的地图,并带有"仅用于开发"的水印,甚至只返回错误信息。

升级到 MovableType 7.0.1

  • Posted on | Updated on
  • by
  • in

在尝试了三次后,终于把 SEO 网站优化及网站推广,升级到最新的 MovableType7.0.1。
大概的介绍一下我升级的过程,以及遇到的问题。

首先在做任何系统升级之前,都要做好备份。

备份

在 MovableType 6 的管理后台,系统菜单,备份数据库,并下载到本地,这是整个 MovableType 的内容,包括所有的图片,上传的文件等等。

mt-database-backup.jpg在 MovableType 6 的管理后台,在本 Blog ,或者说子站之下,选择 Tools, Export Entries,导出所有的文章。同样的也导出模版样式文件。

mt-blog-export-entries.jpg然后,使用 phpmyadmin 工具,把整个数据库都备份下来。

最后的备份,就是 SSH 到服务器上,打包整个网站,包括各种文件和 MovableType 系统。

这样的备份算是非常完整了。哪怕此时系统崩溃,我也可以凭这些备份,重建系统的。

升级尝试

尝试升级的过程是这样,数据库方面,我是在 phpmyadmin 管理器中,把原数据库复制到一个新数据库,升级只升级这个新数据库。这样万一出问题,需要回到原来的数据库,也方便的很。

MovableType 程序文件方面,也是类似的操作,复制一份到新目录,先尝试把 MovableType 7的新文件覆盖原来目录,尝试升级,数据库升级没有问题,升级后可以登录新系统。

但是问题出现在原来的系统是由 5.x 升级到 6.x,而现在的 7.x 系统同之前有很大的变化,我又安装过不少的插件,先出现的问题是编辑器消失了,查看资源是缺少文件,而缺少的文件根本是在新系统和旧系统中都不存在的。所以呢这样无处下手,就放弃第一次的升级了。

第二次升级的过程是这样,我试着新装一套干净系统,然后把文章导入,就是用之前的文章备份来导入,导入时成功的,但是缺少了很多东西,我必须手工加入,比如模版,插件等等,包括系统层面的设置和网站层面的设置,都从原来的系统手工复制过来。之前已经把那些设置页面的主要内容,抄写在笔记上,模版主要是 URL 的设置,要保持一致。在添加 Page 时,出现了一个问题,出现的错误信息是:

Saving Entry failed: Undefined subroutine &Trackback::Entry::extract_domains called

TLS 1.3 标准

  • Posted on | Updated on
  • by
  • in

TLS 1.3 已经被 IESG 正式批准为建议标准了。

The IESG has approved the following document:
- 'The Transport Layer Security (TLS) Protocol Version 1.3'
  (draft-ietf-tls-tls13-28.txt) as Proposed Standard

最后被通过的版本就是 Draft-28,TLS 1.3 已经被讨论两年了,中间有过很多的变化。

提出 TLS 1.3,当然是为了更快更安全。而新通过的版本就是为此而来的。下面看看它同 TLS 1.2 相比有哪些变化。

TLS 1.3 vs TLS 1.2

更快的握手速度

使用 TLS 1.2 需要两次往返( 2-RTT )才能完成握手,然后才能发送请求。

TLS 1.3 增加了一个 零往返(0-RTT)的握手模式,在上一次连接中,握手完成之后,服务端会发送一条 ServerConfiguration 消息,在随后的客户端发起第一个 TLS 记录 ClientHello 过程中,直接附加加密的应用程序数据,该模式将会导致更加快速的访问体验。

更加安全的连接

为了兼容考虑,TLS 1.2 中还保留着很多不够安全的加密算法,而TLS 1.3 删除了那些被业界认为不安全的加密算法。

  • RSA 密钥传输 ---- 不支持前向安全性
  • CBC 模式密码 ---- 易受 BEAST 和 Lucky 13 攻击
  • RC4 流密码 ---- 在 HTTPS 中使用并不安全
  • SHA-1 哈希函数 ---- 建议以 SHA-2 取而代之
  • 任意 Diffie-Hellman 组---- CVE-2016-0701 漏洞
  • 输出密码 ---- 易受 FREAK 和 LogJam 攻击

TLS 1.3 的新加密套件将不能用在 TLS 1.2 之上,而且 TLS 1.3 的各个草案其加密套件也是不兼容的。唯有等待各个厂商的软件都到升级到最新的正式版后,就没有问题了。

除了加密算法的改进,还有下面这些提高安全性的措施。

  • ServerHello 之后的所有握手消息采取了加密操作
  • TLS 1.2 版本的重协商握手机制已被弃用,TLS 1.3 中重新协商变为不可行了
  • 相比过去的的版本,会话恢复在服务端是无状态的,使用了新的 PSK 交换
  • DSA 证书不再允许在 TLS 1.3 中使用

TLS 1.3 的一些测试工具

浏览器测试

测试你的浏览器是否支持最新的 TLS 1.3 Draft-28,Mozilla 提供的一个测试网站。
https://tls13.crypto.mozilla.org/
比如在 Firefox 61.0.1 下的测试结果:
mozilla-tls13-test.jpg如果测试不通过,会出现类似下面的错误信息:

mozilla-tls13-test-error.jpg

测试了一下 TLS 1.3 以及 Google 的 Brotli 压缩算法

  • Posted on | Updated on
  • by
  • in

在昨天简单介绍了 TLS 的变化和趋势之后,特别想看看基于目前的都是预发布版本或者测试版的情况下,TLS 1.3 的支持。
于是用了 Vultr 的 IPv6 only 的最低 2.5美元每月的 VPS,用于测试。该计划是 1vCPU,512MB 内存,20GB SSD 磁盘空间。

用的是位于Seattle,西雅图机房的 VPS,选择安装的是 Ubuntu 18.04 x64 版本系统。
编译 nginx 以及 openssl 有关的,基本上按照 Jerry Qu 的文章来操作。有区别的就是一个是我用了 nginx 1.14.0 版本,以及 openssl 最新的 1.1.1 pre9-dev 版本。
目前 openssl 的支持 TLS 1.3 草案,支持到 draft-26, draft-27, draft-28。
加密套件是:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_AES_128_CCM_SHA256

编译的过程没有什么问题,完成后,加上 Let's Encrypt 的证书。