HTTPS

HTTP参考:
HTTP 相关

HTTP和HTTPS 区别:

  • HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。

  • HTTP协议运行在TCP之上,所有传输的内容都是明文,HTTPS运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的.
    TLS/SSL中使用了非对称加密,对称加密以及HASH算法

  • HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。

  • https 可以有效的防止运营商劫持,解决了防劫持的一个大问题.

  • http的连接很简单,是无状态的;

  • https 协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全

HTTPS 在内容传输的加密上使用的是对称加密非对称加密只作用在证书验证阶段

https.png

SSL/TLS:

SSL是TLS的前身,SSL从1.0、2.0到3.0一步步修订,但安全性都不是非常完美。知道后来SSL3.0摇身一变变成TLS1.0,TLS1.0和SSL3.0几乎没有区别发展至今已经达到TLS1.2的稳定版本。TLS1.3的草案也已经提出。
SSL (Secure Socket Layer,安全套接字层).它是一种标准协议,
TLS:(Transport Layer Security)传输层安全性协议.
TLS:位于 HTTP 和 TCP 之间的协议,其内部有 TLS握手协议、TLS记录协议

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

  • 2、TLS用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议.

  • 3、TLS 的最大优势就在于:TLS 是独立于应用协议。 HTTPS 使用 TLS 保证安全,这里的“安全”分两部分,一是传输内容加密、二是服务端的身份认证

SSL、TLS的握手过程:

ssl:TLS.png

在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。
在TLS握手阶段,客户端首先要告知服务端,自己支持哪些加密算法,所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端.

除此之外,客户端还要产生一个随机数,这个随机数一方面需要在客户端保存,另一方面需要传送给服务端, 客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

1、客户端首次发出请求:
客服端提供:

  • 支持的协议版本,比如TLS 1.0版
  • 一个客户端生成的随机数,稍后用于生成”对话密钥”
  • 支持的加密方法,比如RSA公钥加密
  • 支持的压缩方法

2、服务端首次回应:

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

服务端需要提供的信息:

  • 协议的版本
  • 加密算法
  • 随机数
  • 服务器证书

3、客户端再次回应:

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

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

4、服务器再次响应:

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

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

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

SSL协议在握手阶段使用的是非对称加密,在传输阶段使用的是对称加密,也就是说在SSL上传送的数据是使用对称密钥加密的!
因为非对称加密的速度缓慢,耗费资源。其实当客户端和主机使用非对称加密方式建立连接后,客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥,由于这个过程本身是安全可靠的,也即对称加密密钥是不可能被窃取盗用的,因此,保证了在传输过程中对数据进行对称加密也是安全可靠的,因为除了客户端和主机之外,不可能有第三方窃取并解密出对称加密密钥!如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。

https 是如何确保安全的
https://www.cnblogs.com/anyehome/p/8858456.html

SSL/TLS 工作流程:

20190609230605501.png

参考 https 工作流程
1、Client发起一个HTTPS的请求,根据RFC2818的规定,Client知道需要连接Server的443(默认)端口。
2、Server把事先配置好的公钥证书(public key certificate)返回给客户端。
3、Client验证公钥证书:比如是否在有效期内,证书的用途是不是匹配Client请求的站点,是不是在CRL吊销列表里面,它的上一级证书是否有效,这是一个递归的过程,直到验证到根证书(操作系统内置的Root证书或者Client内置的Root证书)。如果验证通过则继续,不通过则显示警告信息。
4、Client使用伪随机数生成器生成加密所使用的会话密钥,然后用证书的公钥加密这个会话密钥,发给Server。
5、Server使用自己的私钥(private key)解密这个消息,得到会话密钥。至此,Client和Server双方都持有了相同的会话密钥。
6、Server使用会话密钥加密“明文内容A”,发送给Client。
7、Client使用会话密钥解密响应的密文,得到“明文内容A”。
8、Client再次发起HTTPS的请求,使用会话密钥加密请求的“明文内容B”,然后Server使用会话密钥解密密文,得到“明文内容B”

https 特点:

1、内容加密。浏览器到百度服务器的内容都是以加密形式传输,中间者无法直接查看原始内容。
2、身份认证。保证用户访问的是百度服务,即使被 DNS 劫持到了第三方站点,也会提醒用户没有访问百度服务,有可能被劫持
3、数据完整性。防止内容被第三方冒充或者篡改。

https 的缺点:

1、证书费用以及更新维护。
2、HTTPS 降低一定用户访问速度(实际上优化好就不是缺点了)。
3、HTTPS 消耗 CPU 资源,需要增加大量机器。
4、从TLS的握手过程可以看出,即使不需要进行任何计算,TLS的握手也需要至少1个RTT(往返时延。在计算机网络中它是一个重要的性能指标,表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认),总共经历的时延)。会使页面的加载时间延长近50%,增加10%到20%的耗电
5、HTTPS 涉及到的安全算法会消耗 CPU 资源,需要增加服务器资源(https 访问过程需要加解密)

https 访问流程:

  1. 三次握手建立 TCP 连接。耗时一个 RTT。
  2. 使用 HTTP 发起 GET 请求,服务端返回 302 跳转到 https://www.baidu.com 。需要一个 RTT 以及 302 跳转延时。
  3. 三次握手重新建立 TCP 连接。耗时一个 RTT。
  4. TLS 完全握手阶段一。耗时至少一个 RTT。
  5. 解析 CA 站点的 DNS。耗时一个 RTT。
  6. 三次握手建立 CA 站点的 TCP 连接。耗时一个 RTT。
  7. 发起 OCSP 请求,获取响应。耗时一个 RTT。
  8. 完全握手阶段二,耗时一个 RTT 及计算时间。
  9. 完全握手结束后,浏览器和服务器之间进行应用层(也就是 HTTP)数据传输。
    当然不是每个请求都需要增加 7 个 RTT 才能完成 HTTPS 首次请求交互。大概只有不到 0.01% 的请求才有可能需要经历上述步骤。

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

https://www.cnblogs.com/mylanguage/p/5635524.html

为什么数据传输采用对称加密?

非对称加密的加解密效率是非常低的,而 http 的应用场景中通常端与端之间存在大量的交互,非对称加密的效率是无法接受的。

在 HTTPS 的场景中只有服务端保存了私钥,一对公私钥只能实现单向的加解密,所以HTTPS 中内容传输加密采取的是对称加密,而不是非对称加密

为什么需要CA机构颁发证书?

防止”中间人“攻击,同时可以为网站提供身份证明。

中间人攻击

1、某网站拥有用于非对称加密的公钥A、私钥A’。

2、浏览器向网站服务器请求,服务器把公钥A明文给传输浏览器。

3、中间人劫持到公钥A,保存下来,把数据包中的公钥A替换成自己伪造的公钥B(它当然也拥有公钥B对应的私钥B’)。

4、浏览器随机生成一个用于对称加密的密钥X,用公钥B(浏览器不知道公钥被替换了)加密后传给服务器。

5、中间人劫持后用私钥B’解密得到密钥X,再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,440评论 5 467
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,814评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,427评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,710评论 1 270
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,625评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,014评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,511评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,162评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,311评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,262评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,278评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,989评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,583评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,664评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,904评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,274评论 2 345
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,856评论 2 339