采用 postfix 发送邮件，默认没有采用 TLS 加密传输，对方的服务器有可能会提示告警（例如 gmail）。另外，邮件传输采用明文，如果不加密，也存在被人窥视的风险。因此建议修改 postfix 的配置，默认采用 TLS 加密。当然，这需要对方的服务器也支持加密，目前绝大多数邮件服务器都支持 TLS 传输。
修改 /etc/postfix/main.cf 文件，增加以下一行配置即可：
smtp_tls_security_level = may修改了配置文件，使用命令重启 postfix：
sudo systemctl restart postfix
由于Debian 7已经被无情地终结了生命周期，因此不得不将部分生产环境升级到Debian 8。总体上还比较顺利，在mercurial库方面遇到点问题，记录如下：
这是Python脚本编码的问题。一个好的py脚本，应该在脚本起始处就标明编码方式，可惜mercurial的很多脚本没有这么做。Debian 8采用Python 2.7.9，默认是ascii编码，需要修改为默认utf-8编码。注意，Debian 8安装了多个Python版本，首先要确认默认版本号：
python -V
接着修改“/etc/python2.7/sitecustomize.py”文件（如果没有的话，可以手工创建一个），在文件起始处添加以下代码：
import sys
reload(sys)
sys.setdefaultencoding('utf-8')
Bitbucket网站禁止了有缺陷的TLSv1，TLSv1.1加密方式，奇怪的是mercurial为什么没有根据协商采用SSL或者TLSv1.2？ 修改方式也简单，强制mercurial禁止掉TLS。修改“/etc/mercurial/hgrc”，增加以下内容：
[ui] tls=False
DNS污染可能是一个比较普遍的问题，主要表现在：（1）DNS查询返回的IP地址根本是错误的。“错误”意思是IP地址要么根本不存在，要么就是个和域名完全无关系的地址。（2）IP地址虽然可能是对的，但是其他参数被莫名修改，例如TTL参数等。
测试了各类DNS服务器，例如阿里DNS、DNSPod（鹅厂）、Google DNS等。无一例外，最终的结果都或多或少被一些看不见的手给修改、甚至屏蔽了。从技术角度上讲，DNS协议本身非常随意、非常粗糙，是典型的互联网蛮荒时代的产物，比如面向UDP、无加密、无鉴权等，因此网络上任何一只手都有可能修改DNS的查询结果。网络进化到IPv6阶段，当然能解决这个问题，不过既然目前绝大部分设备还只支持IPv4协议栈，因此我们还是不得不修修补补来解决这个污染问题。
最根本的解决方法就是加密DNS查询。目前有些DNS服务商提供了私有的加密DNS方式，不过不太通用，需要私有的客户端程序配合。实际上可以不用搞这么复杂，自己建立加密通道，传递DNS消息即可。例如，参考下图的拓扑逻辑：
在这个网络中，有两个关键程序：dnsProxy和dnsAgent。
dnsProxy顾名思义就是个Proxy，本身并不负责DNS协议的解析，也不保存DNS的查询结果等信息，只是单纯地将DNS消息传递给真正的DNS服务器，并返回相应的结果即可。dnsProxy另一个功能是对外提供加密的数据连接，例如TLS、SSL加密等，甚至可以只是简单地对数据包进行自定义的异或运算即可。另外就是对外提供非标准连接接口，这点非常重要。DNS采用标准UDP53接口作为DNS服务器接口，网络上那些看不见的手，往往就是扫描并篡改53接口的数据包。这个小程序跑在境外（大家都懂的）的一台VPS设备上，推荐采用DigitalOcean，专业的云计算服务商，采用SSD硬盘，价格公道，我们一直用TA，如果你有兴趣的话，请点击这里自行了解细节。
dnsAgent是另一个小程序，主要负责建立与dnsProxy的加密连接，接收普通设备的DNS请求并将其传递给dnsProxy，同时返回DNS结果给普通计算设备。对于网内设备而言，dnsAgent就是个伪装的DNS服务器。同样，dnsAgent其实也不需要关心、也不需要解析DNS协议细节。在我的网络中，dnsAgent跑在一台常年吃灰的树莓派上（还是第一代的）。
实现这些仅仅需要一点UDP、TCP的网络知识，甚至不需要了解DNS协议的细节，无需对DNS数据包做修改。完成后可以愉快地打开很多以前打不开的网站。当然，有些网站始终是打不开的，这是另一个与DNS无关的话题了。
最近查看log，感觉有些无聊人士尝试干扰或者攻击FTP服务器，因此有必要将FTP服务修改为加密方式。最简单的方法就是采用TLS进行传输（即FTPS），确保传输过程是加密的。
目前系统为Debian7，已部署pureFTPd作为FTP服务器。打开TLS支持方法比较简单，请参考pureFTP over TLS文档。主要步骤如下（假定pureFTPd已经部署）：
执行命令：
echo 1 > /etc/pure-ftpd/conf/TLS
设置TLS为1，运行采用overTLS以及普通不加密方式。如果要求必须使用TLS加密方式，则应设置TLS为2。实际部署中，建议设置为2。
使用openssl创建即可：
openssl req -x509 -nodes -days 7200 -newkey rsa:2048 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem
会提示各项信息输入，照着填写即可。同时，修改pem文件的属性：
chmod 600 /etc/ssl/private/pure-ftpd.pem
完成上述配置后，重启pureFTPd即可：
service pure-ftpd restart
在FileZilla的站点管理配置中，“通用 – 加密”项必须配置为“要求显式的FTP over TLS”，如附图所示即可。
从startSSL申请了证书并成功加载到apache，这些都是通用步骤，具体可以直接参考startSSL的说明文档：http://www.startssl.com/?app=21
然而由于密钥文件是采用访问密码保护，因此重启apache时，读取密钥文件会要求手工输入密码，例如以下提示信息：
Some of your private key files are encrypted for security reasons. In order to read them you have to provide the pass phrases. Enter pass phrase:
这样非常不方便，因此需要将密钥的访问密码告诉apache，并自动输入该密码。
以下步骤都是以root身份进行，系统为Debian 7。
创建shell文件：vi /etc/ssl/apache_pass.sh，并输入以下内容，用于输出访问密码：
#!/bin/sh
echo "1234" <-- 这个是密钥文件的访问密码
出于安全的考虑，将这个文件设置为可执行，并且只能由root访问：
chmod 400 apache_pass.sh chmod +x apache_pass.sh
接下来就是修改/etc/apache2/mods-available/ssl.conf文件，将SSLPassPhraseDialog由默认的builtin修改为以下值（其实就是执行上述shell文件）:
SSLPassPhraseDialog exec:/etc/ssl/apache_pass.sh
完成上述步骤后，重启apache2，将自动输入密钥文件的访问密码，不再需要手工操作。
由于工作上的需要，最近两天折腾openssl来实现一些信令加密解密的事情。总体来说，openssl是个很不错的库，也是个很不错的工具。使用openssl做tls客户端编程没有太大问题，而实现tls服务器端则有些地方需要注意。
首先要注意的一点就是：在握手之前（SSL_accept），绝对不能采用非阻塞方式。握手成功之后，才可以将socket修改为非阻塞方式，否则握手不会成功，服务器总是会向客户端返回“Engypted alert”消息并结束握手。
如果是在windows环境生成证书和密钥，建议使用SimpleCA工具，很好用。同时要注意：（1）客户端应安装或者使用该工具生成的根证书，例如ca.crt。（2）服务端需要使用生成的服务端证书和密钥，即.crt和.key文件。（3）生成证书时（无论是根证书还是服务端证书），Common Name都必须要设置为当前服务器的IP地址或者主机名，否则双方握手时，可能产生”certificate name mismatch”等错误。（4）如果需要将证书导入windows系统，必须导入为“受信任的根证书颁发机构”类型。
如果是Ubuntu等linux系统，可以直接安装使用openssl生成证书，如以下命令：
生成根证书： openssl genrsa -out ca.key 4096 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt 生成服务端证书和密钥 openssl genrsa -out server.key 1024 openssl req -new -key server.key -out server.csr openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
理论上来说，可以将.crt和.key文件合并在一起，设置为.pem文件。不过实践证明，openssl的API是要求SSL_CTX_use_PrivateKey_file函数来加载密钥文件的，否则握手还是会出问题（当然，也可能是需要另外单独的设置）。