可信网站验证（可信身份认证系统）

可信网站验证(可信身份认证系统)

为什么HTTPS比HTTP更安全？安全可靠的通信应该包含什么？我将在本文中尝试解释清楚这些细节。

与爱丽丝·鲍勃的通信

我们用爱丽丝和鲍勃之间的一段对话来贯穿全文。起初，它们都是用明文在 *** 上传输通信内容。

嗅探和篡改

如果黑客出现在他们的通信链路中，由于通信内容都是明文可见的，黑客可以嗅出并看到这些内容，或者篡改这些内容。

微信官方账号的文章之前有很多人被绑架，篡改内容，插入广告。

加密和解密

既然明文有问题，就要对明文加密，让中间人看不懂内容，就要把原来的内容变成看不懂的内容，这就叫加密，反之亦然。本质其实是一种数学运算的逆运算，类似于加减法。比如发送方可以把abcd…xyz的每个字母+1映射到bcd…yza，这样就使得原文的字母变成了无法理解的序列，而接收方只需要把每个字母-1还原成原来的序列。当然这种做法的规律太容易* *了，后面还会有案例图。

对称加密

如果两个二进制数A和B进行异或得到结果C，那么C和B的异或会再次返回A，所以异或也可以作为加密和解密。

操作数A作为明文，操作数B作为* *，结果C作为密文。可以看出，加密和解密用的是同一个**B，同一个* *方法叫做对称加密。

可以看到简单的XOR加密/解密操作，要求* *与明文位数相同。为了克服这个缺点，我们需要对其进行改进，将明文分组。每组长度与* *相同。我们可以分别通过异或运算得到密文片段，然后合并在一起得到密文。

不过这种简单的分组方式也很容易找到规律。从下图可以看出，中间采用了DES对原图的ECB模式加密(也就是上面说的简单分组模式)

显然，加密后原始图像的某些特征仍然暴露，因此需要改进。总的思路是把上一次分组操作的结果/中间结果牵扯到下一次分组操作中，使其更具随机性和迷惑性，难度更高* *。以下图片来自 *** :

改进后，如果Alice和Bob能提前得到一个对称加密的* *就可以对明文进行加密，保证他们说的话不会被黑客看到。

不对称加密

只是引起了另一个问题。怎么才能把这个对称加密用的* *告诉对方呢？如果在真实数据传输之前传输* *的话，黑客还是可以嗅到的，然后就没有秘密了。所以还有另一种手段:

这是不对称加密。任何人都可以通过获得Bob的公共公钥对内容进行加密，然后只有Bob自己的私钥可以解密和恢复原始内容。

RSA就是这样一种算法，数学证明它很难被大素数相乘和费马小定理分解。与之前的对称加密相比，需要乘法和模除，性能效率比对称加密差很多。

由于非对称加密的性能较低，我们可以先用它协商对称加密，再用对称加密来提高整体性能。

证明

虽然上面已经解决了* *发货的问题，但是中间人还是可以欺骗双方。只要Alice向Bob要公钥，黑客就把她的公钥给Alice，Alice不知道这件事，以为Bob一直在和她通信。

你现在怎么证明Bob给了公钥？在危险的 *** 环境下，这个问题还没有得到解决。

现实生活中我们一般怎么证明鲍勃就是鲍勃？一般 *** 给我们每个人发一张身份证(假设身份证不能伪造)。只要我看到鲍勃的身份证，就证明鲍勃就是鲍勃。 *** 也可以做到这一点。如果有一个大家都信任的机构，CA，给大家一个证书，那么爱丽丝只要拿到这个证书，检查是不是CA做的鲍勃证书，就可以证明鲍勃就是鲍勃。所以这个证书里面有两个重要的东西:Bob的公钥+CA做的数字签名。

当使用公钥加密时，只有拥有私钥的人才能解密。数字证书有点颠倒:用私钥加密，用公钥解密。CA用自己的私钥加密Bob的信息(包括Bob的公钥)。由于Alice无条件信任CA，所以她已经提前知道了CA的公钥。当她收到Bob的证书时，只需要用CA的公钥解密Bob的证书内容，就能知道是否能成功解密(完整性仍需检查)。此时意味着Bob就是Bob，之后使用证书中Bob的公钥走前面的流程，就解决了中间人欺骗的问题。这种方法也是一种反否认方法。让对方对消息进行数字签名。我一收到消息，就用对方的公钥成功解锁并验证签名，也就是说消息一定是对方发给我的。对方不能否认这种行为，因为只有他有数字签名的私钥。

其实CA是多级关系，最顶层有一个根CA。只要他信任B，B信任C，C信任D，那么我们基本可以认为D是值得信任的。

完整

基本上上面已经解决了机密性和认证，还有一个完整性没有保证。虽然黑客还是看不懂内容，但是黑客可以随意篡改几个比特的通信内容。这时候Bob在解密的时候可能会看到一个很乱的内容，但是他不知道这是Alice实际发的内容还是别人偷偷改的。

单向哈希函数可以把输入变成固定长度的输出字符串，其特点是无法从这个输出中还原出输入内容，不同的输入几乎不可能产生相同的输出。就算要专门去找，也很难找到这样的输入(防撞)。所以Alice只需要对明文内容做一个哈希运算得到一个哈希值，一起加密传给Bob。即使黑客篡改了内容，Bob解密后发现获取的内容和对应计算的哈希值与交付的不一致，说明这个包的完整性被破坏了。

安全可靠的通信。

综上所述，安全可靠的保证:

对称加密和非对称加密解决:保密性

数字签名:认证和不可否认性

单向哈希算法:完整性

来一个完整的画面:

Https握手摘要:

1.客户端发起HTTPS请求

2.服务器的配置

使用HTTPS协议的服务器必须有一套数字证书，可以是自制的，也可以是CA证书。不同的是，自己颁发的证书需要客户端验证后才能继续访问，而使用CA证书时不会弹出提示页面。这组证书实际上是一对公钥和私钥。为别人加密公钥，为自己解密私钥。

3.发送证书

这个证书实际上是一个公钥，但是它包含了很多信息，比如证书的颁发机构，过期时间等。

4.客户端解析证书

这部分工作由客户端的TLS完成。首先，它将验证公钥是否有效，如颁发机构、过期时间等。如果发现任何异常，会弹出一个警告框，表示证书有问题。如果证书没有问题，那么生成一个随机值，然后用证书加密随机值。

5.传输加密信息

这部分传输的是证书加密的随机值，这样服务器就可以得到这个随机值，以后客户端和服务器之间的通信就可以用这个随机值进行加密和解密。

6.服务段解密信息

用服务器的私钥解密后，得到客户端发送的随机值(私钥)，然后用这个值对内容进行对称加密。所谓对称加密，就是通过某种算法把信息和私钥混合在一起，这样除非知道私钥，否则无法获取内容，而客户端和服务器都知道这个私钥，所以只要加密算法足够坚韧，私钥足够复杂，数据就足够安全。

7.传输加密信息。

该信息由服务段的私钥加密，并且可以在客户端恢复。

8.客户端解密信息。

由Ad提供动力。加

客户端用先前生成的私钥解密由服务部分发送的信息，从而获得解密的内容。

PS:即使第三方监控了整个握手过程的数据，也是无可奈何。

摘要

为什么HTTPS是安全的？

在HTTPS握手的第四步中，如果站点的证书不可信，将显示以下确认界面，确认站点的真实性。另外，第六和第八步，使用客户端的私钥进行加密和解密，保证了数据传输的安全性。

HTTPS和HTTP的区别

1.https协议需要向ca申请证书或自制证书。

2.http信息是明文传输的，而https是带安全的ssl加密。

3.http直接用TCP传输数据，而https要经过一层SSL(OSI表示层)，使用的端口不一样。前者是80(需国内备案)，后者是443。

4.http连接简单，无状态；HttpS是SSL+HTTP协议构造的 *** 协议，可以加密认证，比HTTP协议更安全。

请注意，https加密位于传输层

Https消息在封装成tcp消息时是加密的，https的头域和体域都会加密。

使用tcpdump或wireshark等tcp层工具抓包时，得到的是加密的内容，而如果使用应用层抓包，使用Charels(Mac)和Fildder(Windows)抓包，就清楚了。

PS: HTTPS本身就是为了 *** 的传输安全。

例如，使用wireshark捕获数据包:

Http，可以看到catch是纯文本的:

Https，可以看到抓的是密文:

附录

HTTPS常用的加密和哈希算法如下:

非对称加密算法:RSA、DSA/DSS

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

哈希算法:MD5、SHA1、SHA256

Http:三次握手:

现在这个社会，我们离不开 *** 。那么互联网的工作流程是怎样的呢？从http发起到完成， *** 为我们做了什么？今天主要分析http请求的过程:Http工作之前，Web浏览器通过 *** 与Web服务器建立链式连接，连接是通过Tcp完成的。这个协议和Ip一起构成了互联网，著名的Tcp/Ip协议族，所以互联网也叫Tcp/Ip *** 。Http是比Tcp更高的应用层协议，一般Tcp接口的端口是80。

Web浏览器向Web服务器发送请求命令，其中包含:

Web服务器向Web浏览器发送响应数据，包括:

然后Web服务器关闭连接。

这些是基本的http请求。在这个过程中，http建立连接，Tcp经过三次握手。先说三次握手的具体过程。首先，我们来看一张图:

1:客户端向服务器发送一个带有SYN的Tcp消息，这是三次握手的开始。表示客户端希望与服务器建立连接。2:服务器收到客户端的请求，返回客户端的消息，用SYN和ACK标记，询问客户端是否准备好了。3:客户端再次用ACK响应服务器，表示我准备好了。

那么为什么要三次握手呢？有人说握两次手就好。的确，为什么？这个可以从电脑 *** 来回答。举一个例子:无效的连接请求消息段。客户端发送了之一个连接请求消息。但是由于 *** 不好，这个请求并没有马上到达服务器，而是停留在一个 *** 节点，直到一定时间才到达服务器。本来，这已经是一条无效消息了。但是，在收到这个请求消息后，服务器仍然会向客户机发送一个确认消息，表明它同意连接。如果不使用三次握手，只要服务器发送确认，新的连接就会被连接，但实际上这个请求是无效的。客户端会忽略服务器的确认信息，不会向服务器发送确认请求。但是，服务器认为新的连接已经建立，并一直在等待客户端发送的数据。这样服务器的很多资源都没有浪费。三次握手用于防止这种情况发生。服务器将知道客户端没有建立连接，因为它无法接收确认消息。这就是三次握手的作用。

当协议终止时，tcp进行了四次握手。这四次握手是怎么回事？

因为Tcp连接以全双工方式工作，所以每个方向都必须单独关闭。这个原理是，当一方完成发送其数据时，它发送一个FIN来终止这个方向的连接。收到这个FIN意味着这个方向没有数据流，TCP连接收到这个FIN后可以发送消息。执行关闭的之一方将主动关闭，而另一方将被动关闭。1: TCP发送FIN关闭客户端和服务器之间的连接。2:当服务器收到这个FIN时，发回一个ack，确认收到的序列号是收到的序列号+1。像SYN一样，一个鳍会占用一个序列号。3:服务器向客户端发送FIN，服务器关闭客户端的连接。4:客户端发送ACK消息进行确认，确认的序列号为+1，关闭完成。

那么为什么要挥手四次呢？可能有人会奇怪，为什么我和tcp握手的时候ACK和SYN是一起发的？为什么挥手就分开发？原因是TCP的全双工模式。接收FIN表示没有发送数据，但是可以继续发送数据。

3次握手过程的状态:listener:这个很好理解，就是服务器的一个套接字处于监听状态，可以接收连接。

Syn _ SEND state执行connect时，先发送SYN消息，所以也进入Syn_send状态，等待服务器发送的消息。syn_send表示客户端已经发送了syn消息。Syn_rcvd:这个状态类似于Syn_SEND状态，表示已经收到SYN消息。这个状态是建立tcp连接的三次握手中服务器端套接字的一个中间状态，非常短暂。当客户端收到ACK消息时，表示连接已建立，并进入建立状态。

4波的状态:FIN_WAIT_1:这个状态需要好好解释一下。其实FIN_WAIT_1和FIN_WAIT_2状态的真正意义是在等待对方的FIN消息。这两种状态的区别在于，FIN_WAIT_1状态实际上是指当SOCKET处于建立状态时，想要主动关闭连接，并向对方发送FIN消息。此时，套接字进入FIN_WAIT_1状态。当对方响应ACK消息时，进入FIN_WAIT_2状态。当然，在实际正常情况下，对方应该会立即响应ACK消息，所以FIN_WAIT_1状态一般很难看到，而FIN_WAIT_2状态往往可以被netstat看到。(主动方)

FIN_WAIT_2:这个状态已经在上面详细解释过了。其实FIN_WAIT_2状态的SOCKET就是半连接的意思，也就是一方要求关闭连接，但也告诉对方我暂时还有一些数据要传输给你(ACK信息)，以后再关闭连接。(主动方)

TIME_WAIT:表示已经收到对方的FIN消息，ACK消息已经发送，2MSL后可以返回关闭可用状态。如果处于f in_WAIT_1状态，当收到对方同时带有FIN标志和ACK标志的报文时，可以不经过FIN_WAIT_2状态直接进入TIME_WAIT状态。(主动方)

关闭(比较少见):这种状态比较特殊，实际情况下应该很少见，所以属于比较少见的例外状态。一般情况下，当你发送FIN报文时，先收到(或同时收到)对方的ACK报文，再收到对方的FIN报文是合理的。但是关闭状态表示你发送FIN报文后，没有收到对方的ACK报文，但是你也收到了对方的FIN报文。什么情况下会出现这种情况？其实仔细想想，不难得出一个结论:如果双方几乎同时关闭一个SOCKET，那么就会出现双方同时发送FIN消息的情况，即会出现关闭状态，表示双方都在关闭SOCKET连接。

CLOSE_WAIT:这个状态的意思其实就是你在等待关闭。怎么理解呢？当对方在关闭一个SOCKET后给自己发送FIN消息时，你的系统无疑会给对方一个ACK消息作为响应，然后进入CLOSE_WAIT状态。接下来，其实你真正需要考虑的是，看自己是否还有数据要发给对方。如果没有，那么你可以关闭SOCKET，向对方发送FIN消息，也就是关闭连接。所以当你处于CLOSE_WAIT状态时，你需要做的就是等待你关闭连接。(被动方)

LAST_ACK:这个状态比较好理解。就是一方被动关机，最后在发送FIN消息后等待另一方的ACK消息。收到ACK消息后，可以进入关闭可用状态。(被动方)

关闭:表示连接。

#####################################################################################################

和HTTP/TCP/IP有区别吗？

TPC/IP协议是传输层协议，主要处理数据在 *** 中如何传输，而HTTP是应用层协议，主要处理如何封装数据。WEB HTTP协议作为应用层协议封装HTTP文本信息，然后TCP/IP作为传输层协议发送到 *** 。

下图试图显示不同的TCP/IP和其他协议在原始OSI(开放系统互连)模型中的位置:

PS:表格来源于网上资料。

什么是CA证书？

CA(Certificate Authority)是负责管理和颁发证书的第三方权威机构，受到所有行业和公众的信任和认可。

证书是由CA颁发的证书，可用于验证网站是否可信(针对HTTPS)、文件是否可信(是否被篡改)等。一个证书也可以用来证明另一个证书是真实的，顶层的证书称为根证书。除了根证书(证明自己是可靠的)，其他证书都得靠上一级证书来证明自己。

HTTP三次握手

HTTP(超文本传输协议)是互联网上使用最广泛的 *** 协议。因为信息是以明文传输的，所以被认为是不安全的。HTTP的三次握手实际上是用三次TCP握手来确认一个HTTP连接的建立。