从HTTP到HTTPS必须知道的一些概念

HTTPS，可以简单理解为HTTP加Secure（SSL/TLS）。

概念上，无论从HTTP还是SSL/TLS出发，都可以延伸到一个很广的范围。 本文只记录一些与常用证书相关的概念。 把一个网站从HTTP，配置成HTTPS，了解这些概念就够了。

HTTPS相关名词解释 ¶

其它还有.p7b、.p7c、.p13、.pfx等格式的证书文件，详情参见X.509。 本文不涉及这些，因为孤没用到。

HTTP到HTTPS ¶

从HTTP到HTTPS，逻辑上相当于在应用层和传输层之间，额外增加一个安全层。 这个安全层就是SSL/TLS，负责加密、解密HTTP的明文报文。

对一个Web应用、网站来说，从HTTP到HTTPS，它本身可以不做任何修改。 仅仅修改Nginx、Apache、Tomcat这个层级的应用服务器，就可以完成转变。 如果有多层，比如Nginx反向代理一个Tomcat，那么在任意一层都可以添加SSL/TLS。

应用层可以完全不知道、不在意底下是否有一个安全层。 当然，如果有必要，也是可以知道的。

HSTS ¶

虽然HTTPS可以认为是安全的，然而HTTP的访问方法仍然存在。 用户仍然可以通过HTTP的方式访问网页，而不是HTTPS。 而且，在地址栏直接输入域名的情况下，浏览器也是默认以HTTP来补全URL。

有两种策略，可以解决这个问题。

一是禁用HTTP，只允许通过HTTPS访问。 这种方法安全性高，但会造成用户的困惑。 绝大多数普通用户，是不会在意网址的Scheme是什么，也不会手动切换的。 网页访问不了，用户就直接流失了。 所以，这种方法在绝大多数情况下，不能使用。

二是把所有HTTP的请求，全部重定向到HTTPS去。 这种方法在普通用户毫无感知的情况下完成跳转，用户体验一级棒。 可惜，不完美的是降低了安全性，有了被SSL剥离攻击的可能。

HSTS可以用来抵御SSL剥离攻击。 SSL剥离攻击是中间人攻击的一种，由Moxie Marlinspike于2009年发明。 他在当年的黑帽大会上发表的题为《New Tricks For Defeating SSL In Practice》的演讲中将这种攻击方式公开。 SSL剥离的实施方法是阻止浏览器与服务器创建HTTPS连接。

HSTS通过在HTTPS的头字段里添加一段，强制浏览器在很长的一段时间内，比如一年，必须使用HTTPS直接访问。 时限等相关信息，保存在浏览器的Cache中。 如果连接安全不能被保证，比如证书不能被识别，HSTS不允许用户忽略警告。

HSTS也不是没有缺陷。 从以上描述就可以看出，HSTS无法保护首次访问。 而且，无论是换浏览器、清理Cache、无痕浏览、重装机器等因素，都可以让用户重新『首次访问』。

To address this, Google maintains a “HSTS preload list” of web domains and subdomains that use HSTS and have submitted their names to https://hstspreload.appspot.com/. This domain list is distributed and hardcoded into major web browsers. Clients that access web domains in this list automatically use HTTPS and refuse to access the site using HTTP.

显然，Google这种维护一个强制使用HSTS列表的方案，是很麻烦的。 企业级用户也许还愿意去试试，而个人用户就望而却步了。 并且，这个网站在中国还有访问问题。 所以，这个问题只能先这样了。

SSL与TLS ¶

SSL是TLS的前身，由网景公司（Netscape）在1994年首次推出，为HTTPS加密。 SSL虽然一共发展了1.0、2.0、3.0这样的三个大版本，但总体来说都是不安全的，现已全面被TLS取代。 TLS的v1.0，相当于SSL的v3.1。

2014年10月，Google发布在SSL 3.0中发现设计缺陷，建议禁用此一协议。 攻击者可以向TLS发送虚假错误提示，然后将安全连接强行降级到过时且不安全的SSL 3.0，然后就可以利用其中的设计漏洞窃取敏感信息。 Google在自己公司相关产品中陆续禁止向后兼容，强制使用TLS协议。 Mozilla也在11月25日发布的Firefox 34中彻底禁用了SSL 3.0。

但是，由于SSL成名早，而TLS只是继承与发展，所以在很多场合，SSL与TLS同义，都代表HTTPS的那个S。 比如，SSL证书，就不是只有SSL能用而TLS不能，是通用的。

更多详细信息，可以查看维基百科：https://en.wikipedia.org/wiki/Transport_Layer_Security

一堆文件后缀 ¶

目前的公钥证书的格式与机制，都是源于X.509标准。 私钥一般都是.key，而签发的证书文件则有两类。 一类是DER格式，另一类是PEM格式。

DER是二进制文件，文本读取为乱码。 Java程序、Windows服务器等，倾向于使用DER格式的证书。

PEM是文本文件，以BEGIN CERTIFICATE开头、END CERTIFICATE结尾， 内容为Base64加密后的DER二进制数据。 Apache、Nginx等软件、以及Unix系的服务器，倾向于使用这种证书。

以下为PEM文件样例：

-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END CERTIFICATE-----

.cer与.crt通常是DER格式的，与.der等价。 但由于文件后缀名可以随意改，在某些混乱的环境中（如孤所在的这家公司），有时也可能会是PEM格式的。 最简单的鉴别方法，就是直接用文本查看器，查看其内容。 可读的就是PEM，不可读的就是DER。

当然，利用file更有效：

$ file example.pem
PEM certificate
$ file example.der
data

证书转换 ¶

DER格式与PEM格式，区别只在于是否加密，所以可以互相转换。

DER转PEM：

openssl x509 -outform der -in example.pem -out example.der

PEM转DER：

openssl x509 -inform der -in example.der -out example.pem

注意，如果PEM文件包含一些额外的信息，转换过程会丢弃。