公钥,私钥、Https协议

一、公钥加密
假设一下,我找了两个数字,一个是1,一个是2。我喜欢2这个数字,就保留起来,不告诉你们(私钥),然后我告诉大家,1是我的公钥。

我有一个文件,不能让别人看,我就用1加密了。别人找到了这个文件,但是他不知道2就是解密的私钥啊,所以他解不开,只有我可以用
数字2,就是我的私钥,来解密。这样我就可以保护数据了。

我的好朋友x用我的公钥1加密了字符a,加密后成了b,放在网上。别人偷到了这个文件,但是别人解不开,因为别人不知道2就是我的私钥,
只有我才能解密,解密后就得到a。这样,我们就可以传送加密的数据了。

二、私钥签名
如果我用私钥加密一段数据(当然只有我可以用私钥加密,因为只有我知道2是我的私钥),结果所有的人都看到我的内容了,因为他们都知
道我的公钥是1,那么这种加密有什么用处呢?

但是我的好朋友x说有人冒充我给他发信。怎么办呢?我把我要发的信,内容是c,用我的私钥2,加密,加密后的内容是d,发给x,再告诉他
解密看是不是c。他用我的公钥1解密,发现果然是c。
这个时候,他会想到,能够用我的公钥解密的数据,必然是用我的私钥加的密。只有我知道我得私钥,因此他就可以确认确实是我发的东西。
这样我们就能确认发送方身份了。这个过程叫做数字签名。当然具体的过程要稍微复杂一些。用私钥来加密数据,用途就是数字签名

总结:公钥和私钥是成对的,它们互相解密。

公钥加密,私钥解密。

私钥数字签名,公钥验证。

举例

比如有两个用户Alice和Bob,Alice想把一段明文通过双钥加密的技术发送给Bob,Bob有一对公钥和私钥,那么加密解密的过程如下:

  1. Bob将他的公开密钥传送给Alice。
  2. Alice用Bob的公开密钥加密她的消息,然后传送给Bob。
  3. Bob用他的私人密钥解密Alice的消息。

  上面的过程可以用下图表示,Alice使用Bob的公钥进行加密,Bob用自己的私钥进行解密。

什么是HTTP协议?

HTTP协议全称Hyper Text Transfer Protocol,翻译过来就是超文本传输协议,位于TCP/IP四层模型当中的应用层。

HTTP协议通过请求/响应的方式,在客户端和服务端之间进行通信

这一切看起来很美好,但是HTTP协议有一个致命的缺点:不够安全

HTTP协议的信息传输完全以明文方式,不做任何加密,相当于是在网络上“裸奔”。这样会导致什么问题呢?由于传输信息是明文,这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击

小灰和小红可以事先约定一种对称加密方式,并且约定一个随机生成的密钥。后续的通信中,信息发送方都使用密钥对信息加密,而信息接收方通过同样的密钥对信息解密。

虽然我们在后续的通信中对明文进行了加密,但是第一次约定加密方式和密钥的通信仍然是明文,如果第一次通信就已经被拦截了,那么密钥就会泄露给中间人,中间人仍然可以解密后续所有的通信内容。

这可怎么办呢?别担心,我们可以使用非对称加密,为密钥的传输做一层额外的保护。

非对称加密的一组秘钥对中,包含一个公钥和一个私钥。明文既可以用公钥加密,用私钥解密;也可以用私钥加密,用公钥解密。

在小灰和小红建立通信的时候,小红首先把自己的公钥Key1发给小灰:收到小红的公钥以后,小灰自己生成一个用于对称加密的密钥Key2,并且用刚才接收的公钥Key1对Key2进行加密(这里有点绕),发送给小红:小红利用自己非对称加密的私钥,解开了公钥Key1的加密,获得了Key2的内容。从此以后,两人就可以利用Key2进行对称加密的通信了。在通信过程中,即使中间人在一开始就截获了公钥Key1,由于不知道私钥是什么,也无从解密。中间人虽然不知道小红的私钥是什么,但是在截获了小红的公钥Key1之后,却可以偷天换日,自己另外生成一对公钥私钥,把自己的公钥Key3发送给小灰。

小灰不知道公钥被偷偷换过,以为Key3就是小红的公钥。于是按照先前的流程,用Key3加密了自己生成的对称加密密钥Key2,发送给小红。

这一次通信再次被中间人截获,中间人先用自己的私钥解开了Key3的加密,获得Key2,然后再用当初小红发来的Key1重新加密,再发给小红。这样一来,两个人后续的通信尽管用Key2做了对称加密,但是中间人已经掌握了Key2,所以可以轻松进行解密。

这时候,我们有必要引入第三方,一个权威的证书颁发机构(CA)来解决。

到底什么是证书呢?证书包含如下信息:

流程如下:

1.作为服务端的小红,首先把自己的公钥发给证书颁发机构,向证书颁发机构申请证书。

2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1,并且通过服务端网址等信息生成一个证书签名,证书签名同样经过机构的私钥加密。证书制作完成后,机构把证书发送给了服务端小红。

3.当小灰向小红请求通信的时候,小红不再直接返回自己的公钥,而是把自己申请的证书返回给小灰。

4.小灰收到证书以后,要做的第一件事情是验证证书的真伪。需要说明的是,各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以小灰只需要知道是哪个机构颁布的证书,就可以从本地找到对应的机构公钥,解密出证书签名。

接下来,小灰按照同样的签名规则,自己也生成一个证书签名,如果两个签名一致,说明证书是有效的。

验证成功后,小灰就可以放心地再次利用机构公钥,解密出服务端小红的公钥Key1。

5.像之前一样,小灰生成自己的对称加密密钥Key2,并且用服务端公钥Key1加密Key2,发送给小红。

6.最后,小红用自己的私钥解开加密,得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。

由于证书信息是由服务器网址等信息生成的并且经过机构私钥加密,所以中间人无法篡改。

参考链接:https://blog.csdn.net/cut001/article/details/53189645 参考公众号:程序员小灰

原文地址:https://www.cnblogs.com/leifonlyone/p/12609629.html

时间: 2024-10-12 20:09:14

公钥,私钥、Https协议的相关文章

非对称加密,数字签名,公钥私钥,Openssl,https,TLS/SSL等概念说明

本文将通过个人口吻介绍有关公钥私钥,Openssl,https,TLS/SSL等的一些概念及简单配置,在目前时间点(2017年5月7号)下,个人水平有限,存在不少知识理解不够深入,望见谅,后续有新的收获之后将会补充完善该博文. 关于http以及web等基础概念,欢迎看我的另一篇博文:"http,https,www,web等的区别含义" 博文链接地址:http://watchmen.blog.51cto.com/6091957/1922919 本文参考文献引用链接: 1.https://

公钥私钥与SSL的握手协议(转)

一,公钥私钥1,公钥和私钥成对出现2,公开的密钥叫公钥,只有自己知道的叫私钥3,用公钥加密的数据只有对应的私钥可以解密4,用私钥加密的数据只有对应的公钥可以解密5,如果可以用公钥解密,则必然是对应的私钥加的密6,如果可以用私钥解密,则必然是对应的公钥加的密明白了? 假设一下,我找了两个数字,一个是1,一个是2.我喜欢2这个数字,就保留起来,不告诉你们,然后我告诉大家,1是我的公钥. 我有一个文件,不能让别人看,我就用1加密了.别人找到了这个文件,但是他不知道2就是解密的私钥啊,所以他解不开,只有

HTTPS协议

原文出自:http://www.cnblogs.com/zhuqil/archive/2012/07/23/2604572.html HTTPS其实是有两部分组成:HTTP + SSL / TLS, 也就是在HTTP上又加了一层处理加密信息的模块.服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据 1. 客户端发起HTTPS请求 这个没什么好说的,就是用户在浏览器里输入一个https网址,然后连接到server的443端口. 2. 服务端的配置 采用HTTPS协议的服

大型网站的 HTTPS 实践(1):HTTPS 协议和原理

转自:http://op.baidu.com/2015/04/https-s01a01/ 1 前言 百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS.本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义. 2 HTTPS 协议概述 HTTPS 可以认为是 HTTP + TLS.HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的. TLS 是传输层加密协议,它的前身是 SSL 协议,最早由 ne

Fiddler抓取HTTPS协议

HTTPS协议握手过程: 1,客户端明文请求,把自己支持的非对称加密算法(用于使用CA证书公钥加密计算生成协商密钥的随机数per_master).对称加密算法(用于以后使用协商密钥加密传输内容).验证数据完整性的HASH算法.随机数Random_C发给服务器. 2,服务器发回客端的明文信息,包含选择一套加密算法.HASH算法.CA证书.随机数Random_S.CA证书中包含服务器地址.公钥.证书颁发机构信息和签名. 3,客户端做五件事: a)对证书合法性.证书中包含的地址与正在访问的地址是否一致

Loadrunner对https协议(单双向SSL)的web端性能测试

1.项目背景 1.1 单双向SSL的含义及部署 单向SSL即我们说到的https协议. 特点是,浏览器需要请求验证服务器证书: 基本含义是:一个安全通信通道,它基于HTTP开发,用于在客户计算机和服务器之间交换信息.它使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全版. 双向SSL顾名思义就是双方都需要验证证书的协议,浏览器首先向服务端请求证书,然后服务器端需要向浏览器请求目前登陆用户的个人证书验证. 1.2 系统的基本部署 单向SSL交互过程: 使用单向SSL时,仅通过虚拟主

RSA不对称加密和公钥 私钥

理论上只要有加密的规则 基本都是可以解密的 但是如果解密需要消耗的时间过长 比如1000年 解密过后已经没什么意义了 此时可认为这种算法不能被破解 也就是说此加密可信 MD5 是一种单向操作 加密后不能被还原 只能用于信息校验(相同的输入md5后的字符是相同的<_>) RSA 私钥 公钥 加密算法 是一种可以还原数据原型的算法  公钥加密的东西  只能用私钥解出来 即使公钥自身也解不出来  同理私钥加密的东西也只有公钥能解密出来  自身也解不出来 .所以二者是对等的 相互依赖的. 但是加入我们

HTTP协议和HTTPS协议初探

概况 HTTP是hypertext transfer protocol(超文本传输协议)的简写.它是TCP/IP协议的一个应用层协议,用于定义WEB浏览器与WEBserver之间交换数据的过程. HTTP是一个属于应用层的面向对象的协议,因为其简捷.高速的方式,适用于分布式超媒体信息系统.它于1990年提出.经过几年的使用与发展.得到不断地完好和扩展.眼下在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,并且HTTP-NG(Next Generation of

《Apache数据传输加密、证书的制作》——涉及HTTPS协议

首先了解http和https: HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议. HTTPS和HTTP的区别: http是超文本传输协议,信息是明文传输,https 则是具有安全性的ssl加密传输协议 http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443. HTTPS协议是由SSL+HTTP协议构建的可进行加密传输.身份认证的网络协议 要比http协议安全 HTTPS解决的问题: 1 . 信任主机的问题.