HTTPS学习总结拿走不谢
|
然后客户端会将自己计算出来的摘要跟解密出来的服务器发送过来的摘要进行对比，如果两个是相同的，那么证明服务器发出的响应数据跟客户端收到的响应数据是相同的。也就是数据是完整的，没有丢失，也没有遭到篡改。 为什么非对称加密可以保证服务器发送的摘要不被修改呢? 因为私钥只有服务器有，也就是说，只有服务器能够使用私钥进行加密。而使用私钥加密的数据，只有公钥可以解密。换句话说，用公钥能够解密出来的数据，就是使用私钥加密过的。所以，只要客户端使用公钥能够解密出来加密过的摘要，那么这个摘要就是服务器使用私钥加密的。而且私钥只有服务器知道，别人无法篡改加密后的摘要。 这里其实我有个疑问，反过来，在请求过程中，客户端使用公钥加密摘要，然后服务器私有私钥解密摘要。貌似只有证明这个摘要是使用公钥加密的，但是，公钥是公开的，别人也能知道，那别人不就可以篡改这个摘要? 使用数字证书验证服务器的身份 HTTPS是如何确认服务器的真实性的呢?也就说，怎样确认跟客户端通信的服务器就是我们的域名指向的服务器，而不是其他服务器冒充的? HTTPS采用非对称加密方式解决问题。 服务器拥有私钥，这个私钥只有服务器有，所以，只要客户端拥有服务器的公钥，那么，当服务器使用私钥加密数据发送给客户端，而客户端能够解密出数据，说明公钥和私钥是配对的，而公钥是对应着我们想要的那个服务器的，所以就代表服务器是真的。 那么问题又来了，我们怎么拿到该服务器的公钥呢?在客户端内置?怎么多网站，怎么看都不现实。 那我们就在建立连接的时候发送给客户端。 嗯，HTTPS就是这么做的。 不对，那发送公钥的时候，公钥也可能被篡改啊，要是被篡改成其他服务器的公钥，以后就是跟其他冒充的服务器通信了，那怎么玩? 嗯，HTTPS引入了权威的第三方机构来确保这个公钥确实是该服务器的。 如果要使用HTTPS，服务器管理人员需要向CA(权威的证书颁发机构)购买证书。CA会将该服务器的域名、公钥、公司信息等内容封装到证书中。并且使用CA自己的私钥对证书进行签名。那么，服务器将证书发给客户端，客户端如果验证出证书是有效的，并且证书的域名跟目前通信的域名一致，那么这个证书里面的公钥就是有效的。而且当前是域名指向的服务器的公钥。所以，我们就能确保拿到的公钥是真的了。 嗯，这个CA机构颁发的证书就叫做数字证书。 问题又来了，客户端如何验证服务器发过来证书是有效的呢? 证书上有CA用其私钥做的签名，而一般客户端都会内置这些权威机构(CA)的公钥的，所以能够直接拿到CA的公钥对证书上的签名进行解密，然后自己根据证书上的说明计算摘要，两个摘要一致的话，代表证书是有效。因为只有CA自己才有私钥，别人是不可能冒充这个签名的。 说了那么多，HTTPS在连接建立时会发给客户端一个数字证书，客户端验证了数字证书之后，就能确认服务器的身份。同时还可以用数字证书上的公钥加密随机生成的共享密钥A，与服务器协商接下来通信过程中加密数据所用的共享密钥A。 HTTPS握手过程
SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术虽然比公钥加密技术的速度快，可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下： ①客户端向服务器请求HTTPS连接。 客户端向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。 ②服务器确认并返回证书。 服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。 ③客户端验证服务器发来的证书。 客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开;如果合法性验证通过，将继续进行第四步。 ④信息验证通过，客户端生成随机密钥A，用公钥加密后发给服务器。 从第③步验证过的证书里面可以拿到服务器的公钥，客户端生成的随机密钥就使用这个公钥来加密，加密之后，只有拥有该服务器(持有私钥)才能解密出来，保证安全。 ⑤服务器用私钥解密出随机密钥A，以后通信就用这个随机密钥A来对通信进行加密。 我们这个握手过程并没有将验证客户端身份的逻辑加进去。因为在大多数的情况下，HTTPS只是验证服务器的身份而已。如果要验证客户端的身份，需要客户端拥有证书，在握手时发送证书，而这个证书是需要成本的。 【编辑推荐】
点赞 0 （编辑：淮北站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
