HTTPS通信过程详解

我们知道普通的Http协议通信是没有对传输数据进行加密，数据在传输过程中很容易被窃取，特别是敏感信息，为了造成不必要的损失我们可以采用HTTPS协议。首先介绍我们的网站怎么启用HTTPS

Nginx配置HTTPS

默认情况下ssl模块并未被安装，如果要使用该模块则需要在编译时指定–with-http_ssl_module参数，安装模块依赖于OpenSSL库和一些引用文件，通常这些文件并不在同一个软件包中。通常这个文件名类似libssl-dev

生成证书

首先，进入你想创建证书和私钥的目录，例如：

cd /usr/local/nginx/conf

创建服务器私钥，命令会让你输入一个口令：

$ openssl genrsa -des3 -out server.key 1024

创建签名请求的证书（CSR）：

$ openssl req -new -key server.key -out server.csr

在加载SSL支持的Nginx并使用上述私钥时除去必须的口令：

$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key

配置Nginx

最后标记证书使用上述私钥和CSR

$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

修改Nginx配置文件，让其包含新标记的证书和私钥：

server {
server_name YOUR_DOMAINNAME_HERE;
listen 443;
ssl on;
ssl_certificate /usr/local/nginx/conf/server.crt;
ssl_certificate_key /usr/local/nginx/conf/server.key;
}

重启nginx。

这样就可以通过以下方式访问：
https://
另外还可以加入如下代码实现80端口重定向到443

server {
listen 80;
server_name ww.centos.bz;
rewrite ^(.*) https://$server_name$1 permanent;
}

service nginx reload (重新加载nginx服务)
netstat -lan | grep 443 (查看443端口)
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN (有看到这一行 就表示HTTPS已经在工作了)

Tomcat配置HTTPS

因为SUN公司提供了制作证书的工具keytool。

在JDK 1.4以后的版本中都包含了这一工具，它的位置

为

<JAVA_HOME>\bin\keytool.exe。

创建证书命令

keytool -genkeypair -alias "tomcat" -keyalg "RSA" -keystore "f:\tomcat.keystore"

执行该命令会提示你输入口令密码

以上命令将生产一对非对称密钥和自我签名的证书f:\tomcat.keystore.

将证书保存到你要存放的地方，我的保存在

D:\Tools\Web\ssl\tomcat.keystore

注意：“名字与姓氏”应该是域名，输成了姓名，和真正运行的时候域名不符，会出问题

配置Tomcat

定位到tomcat的安装目录，找到conf下的server.xml文件

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="D:\Tools\Web\ssl\tomcat.keystore"
keystorePass="tomcat"
ciphers="tomcat"/>

clientAuth：如果设为true，表示Tomcat要求所有的SSL客户出示安全证书，对SSL客户进行身份验证

keystoreFile：指定keystore文件的存放位置，可以指定绝对路径，也可以指定相对于

<CATALINA_HOME>

（Tomcat安装目录）环境变量 的相对路径。如果此项没有设定，默认情况下，Tomcat将从当前操作系统用户的用户目录下读取名为“.keystore”的文件。

keystorePass：指定keystore的密码，如果此项没有设定，在默认情况下，Tomcat将使用“changeit”作为默认密码。

sslProtocol：指定套接字（Socket）使用的加密/解密协议，默认值为TLS，用户不应该修改这个默认值。

ciphers：指定套接字可用的用于加密的密码清单，多个密码间以逗号（,）分隔。如果此项没有设定，在默认情况下，套接字可以使用任意一个可用的密码。

可能遇到问题

启动tomcat报错

java.lang.Exception: No Certificate file specified or invalid file format

解决方案

将protocol=”HTTP/1.1”替换为protocol=”org.apache.coyote.http11.Http11Protocol”，问题得以解决；

APR给Tomcat的性能提升起到很大作用，建议配置APR方式，这样就可以了

https简介

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图



1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务端解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

作者：朱祁林

出处：http://zhuqil.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

用一句话简单概括是公钥、私钥在服务端通过RSA生成，私钥一直在服务端用于解密，公钥传给客户端用于对对称加密的随机值进行加密，而数据传输是用随机值进行加密的，由于随机值只能用服务端的私钥进行解密，所以别人窃取了你的数据也束手无策。

加密算法

SSL介于应用层和TCP层之间。应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头

我们用Fiddler获取headers报文如下：

HTTP/1.1 200 Connection Established
FiddlerGateway: Direct
StartTime: 14:32:54.612
Connection: close
EndTime: 14:33:04.968
ClientToServerBytes: 643
ServerToClientBytes: 3833
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
To view the encrypted sessions inside this tunnel, enable the Tools > Fiddler Options > HTTPS > Decrypt HTTPS traffic option.
A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
SessionID:  empty
Random:     80 97 5C 75 FD 6E 56 87 6F 85 26 62 A5 E9 67 14 CB 91 AE F6 96 BB 81 16 FE 46 86 FB 0C 32 5B 3E
Cipher:     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [0xC030]
CompressionSuite:   NO_COMPRESSION [0x00]
Extensions:
renegotiation_info  00
ec_point_formats    uncompressed [0x0], ansiX962_compressed_prime [0x1], ansiX962_compressed_char2  [0x2]
SessionTicket   empty
ALPN        http/1.1

一般的HTTPS连接只在第一次握手时使用非对称加密（RSA），通过握手交换对称加密密钥，之后用对称加密（随机值）

注：RSA性能是非常低的，原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下：

1.浏览器将自己支持的一套加密规则发送给网站。

2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

3.浏览器获得网站证书之后浏览器要做以下工作：

a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

4.网站接收浏览器发来的数据之后要做以下的操作：

a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

b) 使用密码加密一段握手消息，发送给浏览器。

5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

这里说的其实和我上面简单的概括的一句话是一个意思，只是更详细了些。

这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：

非对称加密算法：RSA，DSA/DSS

对称加密算法：AES，RC4，3DES

HASH算法：MD5，SHA1，SHA256