非对称加密是这样的一把锁，有两把钥匙，任意一把钥匙可以把锁锁上，只有另一把钥匙才能将锁打开。这两把钥匙是成对的，可以互相解密。其中一把是公开的公钥，另一把是服务器持有的私钥。
任何人都可以用公钥加密一段消息发送给服务器，做到安全发送。另一方面，服务器可以用私钥加密一段消息，将消息明文和密文发送给接收者，以此证明自己的真实身份，这叫做签名。当然，现实中，是对消息的摘要进行签名加密，因为摘要比较小。
TLS的第一步，就是让发送者持有服务器的公钥。通常获得服务器公钥的方式，都是向服务器进行询问，然后由服务器明文发送过来的。为了保证这一步的安全性，确保明文发送过来的公钥没有被串改，我们又发明了证书。
证书由服务器名称信息和服务器公钥组成，然后加上证书签发机构CA和签发机构对前面信息的签名。改用证书机制后，服务器以明文发送自己的证书信息，使用者用CA的公钥验证证书签名，核对相关的服务器信息，然后就可以信任服务器的公钥了。
至于CA公钥的传递方式，一般是内置的或者通过实体进行传递。
一般服务器是不限制使用者访问的，所以服务器配置了证书和私钥，让发送者能够安全的从第一步开始建立加密通信机制。即使使用者不验证服务器证书，TLS仍旧是以加密方式进行，虽然安全度不是最高，但是屏蔽掉无聊的阿猫阿狗访问已经足够了。
更进一步，服务器可以配置双向认证，配置CA证书并要求认证使用者的证书。那么使用者在访问前就要配置由CA签发的个人证书和私钥，在第一步开始时把自己的证书和随机签名发过去让服务器进行认证。
使用双向认证的时候，通信的安全性已经足够高了：消息是加密的，并且不太容易在某个环节被串改，而使用者必须经过服务器用自己的CA签发授权证书后才能访问服务。
TLS的运用其实应该非常广，只要不是内网服务，而是向不安全的互联网公开的服务，并且在通信上没有使用任何加密手段，也没有特别有效的客户鉴权，都应该使用TLS。
比如有时候因为某种原因，不得不向互联网暴露mysql，redis或者其他开源软件的服务端口，这种大作死的行为，软件自带的脆弱的客户鉴权机制就跟杂草一样一踩就倒，已经是业界人尽皆知的情形。
如果能为这些开放的服务端口加上TLS双向认证通信，基本能把侵害排除99%了吧。那如何给这些服务增加TLS安全通信呢？
首先， 把公开的服务改成内网服务 。
第二， 在服务器和客户端之间配置TLS tunnel ，通过tunnel转发客户端和服务器之间流量。有很多TLS tunnel客户端可以使用，这种方式也不会对原系统造成任何改动，所谓各司其职。用途
tcpdump简义：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。
tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。
语法
tcpdump [-adeflnNOpqStvx][-c<数据包数目>][-dd][-ddd][-F<表达文件>][-i<网络界面>]
[-r<数据包文件>][-s<数据包大小>][-tt][-T<数据包类型>][-vv][-w<数据包文件>][输出数据栏位]
参数说明：>
apache >
① 浏览器发送一个连接请求给安全服务器。
② 服务器将自己的证书，以及同证书相关的信息发送给客户浏览器。
③ 客户浏览器检查服务器送过来的证书是否是由自己信赖的CA中心（如沃通CA）所签发的。如果是，就继续执行协议;如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。
④ 接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。
⑤ 服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接;如果通过验证，服务器获得用户的公钥。
⑥ 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。
⑦ 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。
⑧ 浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。
⑨ 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。
⑩ 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。
双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些。
具体实现>
>>
欢迎分享，转载请注明来源：内存溢出
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）