服务器与客户端的通讯安全 服务器与客户端之间的数据交互过程

详解https是如何确保安全的？？

（多文字预警）

10年积累的网站制作、成都网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先建设网站后付款的网站建设流程，更有禅城免费网站建设让你可以放心的选择与我们合作。

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL

下面就是https的整个架构，现在的https基本都使用TLS了，因为更加安全，所以下图中的SSL应该换为SSL/TLS。

下面就上图中的知识点进行一个大概的介绍。

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。

常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）；并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。

数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

数字签名的过程如下：

明文 -- hash运算 -- 摘要 -- 私钥加密 -- 数字签名

数字签名有两种功效：

一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。

二、数字签名能确定消息的完整性。

对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。

用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥签名)。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。

浏览器默认都会内置CA根证书，其中根证书包含磨唯了CA的公钥

1、2点是对伪造证书进行的。3是对于篡改后的证书验证，4是对于过期失效的验证瞎尺培。

SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3。0版本。

SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩困银、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

用于两个应用程序之间提供保密性和数据完整性。

TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL与TLS握手整个过程如下图所示，下面会详细介绍每一步的具体内容：

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

客户端需要提供如下信息：

服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端。这里的随机数是整个过程的第二个随机数

服务端需要提供的信息：

客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。

客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。

服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

后续客户端与服务器间通信

确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID

session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。

session ticket

客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。

总结

https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。

收录自| 原文地址

如何在iis上实现网站服务器与客户端之间的安全通信

服务器监听。客户连接到服务冲差器后，死循环里READ并处理 那个连接，不要断开，同时可以发送散弊皮信息. 服务器里 做处理信息. 这东西如果你从SOCKET开始做很复杂。你不但要了解套接字网络连接方法，还要了解套接字阻塞机制，还有读写阻塞机制.还要处理读写超时处理，防DDOS攻击处理，还要了解异步处理SELECT或POLL。而且这卜旁种底层的程序用C#做很不值得，。.如果你想从底层做，并且做的很好.就用C写，并且要求效率。 如果不要求高效率那就直接用IIS做成WEB服务，配合数据库做，然后用客户端调用WEB服务..

TLS安全通信

TLS其实是SSL，可能更正式的说法已经不用SSL了。TLS是一套基于非对称加密算法的安全传输协议，更严格来说，TLS先是通过非对称加密方式交换对称加密秘钥，然后采用对称加密算法进行安全传输。

非对称加密是这样的一把锁，有两把钥匙，任意一把钥匙可以把锁锁上，只有另一把钥匙才能将锁打开。这两把钥匙是成对的，可以互相解密。其中一把是公开的公钥，另一把是服务器持有的私钥。

任何人都可以用公钥加密一段消息发送给服务器，做到安全发送。另一方面，服务器可以用私钥加密一段消息，将消息明文和密文发送给接收者，以此证明自己的真实身份，这叫做签名。当然，现实中，是对消息的摘要进行签名加密，因为摘要比较小。

TLS的第一步，就是让发送者持有服务器的公钥。通常获得服务器公钥的方式，都是向服务器进行询问，然后由服务器明文发送过来的。为了保证这一步的安全性，确保明文发送过来的公钥没有被串改，我们又发明了证书。

证书由服务器名称信息和服务器公钥组成，然后加上证书签发机构CA和签发机构对前面信息的签名。改用证书机制后，服务器以明文发送自己的证书信息，使用者用CA的公钥验证证书签名，核对相关的服务器信息，然后就可以信任服务器的公钥了。

至于CA公钥的传递方式，一般是内置的或者通过实体进行传递。

一般服务器是不限制使用者访问的，所以服务器配置了证书和私钥，让发送者能够安全的从第一步开始建立加密通信机制。即使使用李谈知者不验证服务器证书，TLS仍旧是以加密方式进行，虽然安全度不是最高，但是屏蔽掉无聊的阿猫阿狗访问已经足够了。

更进一步，服务器可以配置侍蔽双向认证，配置CA证书并要求认证使用者的证书。那么使用者在访问前就要配置由CA签发的个人证书和私钥，在第一步开始时把自己的证书和随机签名发过去让服务器进行认证。

使用双向认证的时候，通信的安全性已经足够高了：消息是加密的，并且不太容易在某个环节被串改，而使用者必须经过服务器用自己的CA签发授权证书后才能访问服务。

TLS的运用其实应该非常广，只要不是内网服务，而是向不安全的互联网公开的服务，并且在通信上没有使用任何加密手段，也没有特别有效的客户鉴权，都应该使用TLS。

比如有时候因为某种原因，不得不向互联网暴露mysql，redis或者其他开源软件的服务端口，这种大作死的行为，软件自带的脆弱的客户鉴权机制就跟杂草一样一踩就倒，已经是业界人尽皆知的情形。

如果能为这些开放的服务端口加哪消上TLS双向认证通信，基本能把侵害排除99%了吧。那如何给这些服务增加TLS安全通信呢？

首先， 把公开的服务改成内网服务 。

第二， 在服务器和客户端之间配置TLS tunnel ，通过tunnel转发客户端和服务器之间流量。有很多TLS tunnel客户端可以使用，这种方式也不会对原系统造成任何改动，所谓各司其职。

如何实现客户端安全和服务器安全

楼主您好：

我是专业IDC工作人员，我槐裂来帮帮您

服务器的安全主要几大块：

1.服务器的权限设置

2.服务器的端口设置

3.不用的服务的停用

4.注册表里的修改

5.各种软件，如ftp的密码设置，指明耐及数据密码的设置

6.安全策略的设置唯春

很高兴为您解答，海腾数据---中尉