Gnome 3 还好

我把Ubuntu 从11.04 升级到了11.10 的开发版。(令我感到意外的是——尽管升级过程并不顺利(强迫重启了2次),但升级后的新系统记过一些调整后却很似乎很稳定,没见到太多的软件包本身的bug,比之前从10.10 升级到11.04 alpha 轻松多了。)

升级后,我并没感到Unity 桌面环境有什么大的改进。相反,对于新的ctrl+tab 的功能设置我实在无法接受,我以前都用它切换浏览器标签的。。。

11.10 的一个好处是GNOME shell 可以和Unity 共存,所以我又安装了GNOME shell,这东西比我想象中的要好。最主要的就是响应速度上了,比那个基于糟糕compiz 的Unity 好太多了。举个例子,在GNOME shell 和Unity 环境中分别按下Windows 键,GNOME shell 几乎是立即就弹出那个Acitivites 界面了,而Unity 底下往往得卡个一两秒钟。。

GNOME shell 另一个明显强于Unity 的地方就是屏幕左边那个“panel”了。使用Unity 时,鼠标往屏幕左边移动时都得很小心,以防止把那个panel 给激活了;而在GNOME shell 中则是无需担心的,屏幕左上角才是用户需要“担心”的。

目前就这点感觉吧。。。

Nginx with SSL

因为有了StartSSL 这样的可以免费申请SSL证书的机构,所以我觉得把自己的一些站点放到https 下还是值得去做了的。(至少,总还是会有一部分人会对在非SSL加密下的登录页面感到不舒服吧)

SSL 的性能问题

SSL 增强了安全,但它有些问题。它会导致服务器的资源消耗比http 大(但对现在一般的机器来说似乎已经不再是个问题了)。很多情况下人们对于https 的链接还是有一个感觉——慢,准确点来说应该是初次连接到服务器时会感觉慢,而一旦连接建立后,速度上感觉是与明文的http相差无几的。这主要是因为本地浏览器与服务器端初次建立连接握手时需要进行(非对称)密钥交换,密钥交换的协议和密钥的加密算法、长度都会对这个时间有影响。但是连接建立后,内容是以密钥长度短得多的对称加密的方式在传输,而且现代的浏览器同样也能对https链接的内容进行缓存等操作,所以也就感觉不到什么差别了。

因为慢,所以要对它作些调节。但知道了原因后也就好办了。

  • 密钥交换协议的选择。可以在Nginx 配置文件的ssl_ciphers 指令中添加“!kEDH”禁用先对耗时更长的DH 密钥交换机制,而使用RSA【1】。从1.0.5 版本开始,Nginx 默认的SSL ciphers是“HIGH:!aNULL:!MD5”,我们可以把它改为“HIGH:!aNULL:!MD5!kEDH”。应该看到如下变化:


使用DHE_RSA 进行key 交换

更改后的使用RSA key交换机制

  • 服务器公钥长度的选择。长度越长的服务器公钥一般来说是越安全的,但建立连接的时间也会越长,所以这就需要作些取舍了。像Google 和Facebook 这两家规模巨大但提供了许多全程加密的web 服务的公司就使用了相对“弱”的1024位公钥(openssl s_client -connect domain.com:443 查看),这也许降低了建立连接的安全性,但更重要的是降低了连接建立时间。(BTW,Google 还在传输过程中对Chrome 浏览器使用了比HTTP 更快的SPDY 协议,并且key exchange 机制也是RSA 的。)

其它还有要注意的地方有服务器ssl_session_cache, ssl_session_timeout, keepalive_time 等指令的使用等。

——

一些有用的链接:

【1】. http://matt.io/technobabble/hivemind_devops_alert:_nginx_does_not_suck_at_ssl/ur

http://nginx.org/en/docs/http/configuring_https_servers.html

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

Iptables default DROP 策略和hitcount

记一下。当使用了默认为DROP 的策略时,iptables 限制连接次数的脚本应该可以这么写:

[sourcecode language=”bash”]
#!/bin/sh

# Flush all existing rules.
iptables -F

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i $INET_IF -p tcp -d $INET_ADDR –dport 22 -m state –state NEW -m recent –update –seconds 300 –hitcount 5 -j DROP
iptables -A INPUT -i $INET_IF -p tcp -d $INET_ADDR –dport 22 -m state –state NEW -m recent –set -m state –state NEW,ESTABLISHED -j ACCEPT

[/sourcecode]

使用default DROP 策略时,–update 应该是要位于–set 之前的。因为之前把iptables 和PF 有些记混了,记成了iptables 也是“最后匹配”的,所以写成了先–set, 然后–update 的顺序,结果测试发现根本就无法达到限制连接数的作用。
PS:之所以限制SSH server 端口的连接次数只是为了让auth.log 简洁一点,算不上什么安全策略。确保SSH server 安全正确的做法应该还是禁止密码验证方式吧。