部署HTTPS心得

部署HTTPS心得

以前都讲https是安全的，也知道有一个ssl层是在表示层的来完成安全。但总被一些公钥啊，私钥，证书什么的弄混，也对网站中表单的数据明文密文传输很迷，通过今天在自己的网站上部署了一个https的网站，才终于搞明白https究竟是怎么实现安全的。

Https的加密机制

在这一层主要是通过SSL来完成的，具体SSL四次握手在下面章节。本部分介绍步骤：
（1）：用户把自己的DES或者其他对称加密算法的密钥通过服务器的公钥加密后发给服务器，服务器用私钥解密，也获取了对称加密的密钥
（2）：两边通过对称加密体制的密钥进行传播
（3）：解决了维护不变的对称密钥的管理困难和安全问题，也解决了使用RSA的速度慢的问题

CA（证书颁发机构和数字签名和数字证书）

在原有的tomcat中，未被实现https的也有密钥，但可能会有中间代理的可能，所以每个网站都要申请一个由公信的权威机构颁发的证书（很贵），来避免中间代理假冒。
考虑当客户端在向服务器发送请求时（SSL第一次握手是明文），被其他恶意中间代理截获，将自己的公钥发给客户端，客户端误以为恶意中间人是服务器，就把自己的密钥（会话密钥（DES））发给中间商，导致信息泄露。为了应对这种情况，数字证书出现了：
由几个由公信力的机构为网站颁发SSL证书，（真的是太TM贵了，不过蹭了一个免费的，感觉还行），每个证书里面是一个私钥，只有服务器才有。服务器将服务器的信息和公钥通过HASH，生成信息摘要，然后用CA颁发的私钥对其加密，生成数字签名。之后将数字签名，（服务器信息和公钥）这三个东西合在一起发给用户，这三个东西合在一起叫做数字证书。

当证书被发到用户那里，用户HASH服务器个人信息和公钥得到一份摘要，然后用CA的公钥（这个东西因为CA就那几家，被嵌到浏览器里面了（内置CA列表））对数字签名进行解密，得到另一份摘要。两份摘要相同，服务器身份即得到确认。恶意中间人没有CA的私钥，不可能成功。

SSL层的四次握手

1：客户端请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。

2：服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
（上文的恶意代理商就是通过上面这两步干坏事，不过HTTPS要求证书了，就解决了安全问题）

3：客户端收到服务端的回复后（确认证书OK）利用服务端的公钥，加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密，发送给服务器。

4：服务端收到客户端的回复，利用已知的加解密方式进行解密，同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。