HTTPS知识梳理

梳理HTTPS知识,如有错误请指正,参考文章如下:

腾讯云文档SSL原理:
https://www.qcloud.com/docume...
HTTPS:
http://www.360doc.com/content...
https://segmentfault.com/a/11...
SSL与TLS:
https://segmentfault.com/a/11...
http://kb.cnblogs.com/page/19...
RSA加密算法-维基百科:
https://zh.wikipedia.org/zh-c...
数字证书基本概念:
http://blog.csdn.net/adeyi/ar...

1 加解密基本概念

1.1 对称加密算法

加密、解密使用相同密钥。

encode : clipboard.png

decode : clipboard.png

1.2 非对称加密算法

加密、解密使用不同密钥,分为公钥、私钥。

1.3 公钥密码体制

公钥密码体制使用非对称加密算法,分三部分:加解密算法、公钥、私钥。
其中,算法、公钥公开,私钥保密,加解密过程如下:

encode : clipboard.png

decode : clipboard.png

1.4 RSA

RSA是一种公钥密码体制,算法、公钥公开,私钥保密。RSA的一对公钥、私钥都可以用来加密和解密,公钥加密的内容只能使用私钥解密,私钥加密的内容只能使用公钥解密。

1.5 哈希算法

将任意长度的二进制值映射为较短的固定长度的二进制值,这个小的二进制值称为哈希值。

clipboard.png

1.6 签名

作用:保证通信过程中传递信息未被修改。
实现:计算信息的hash值,并与信息一起发送,为避免恶意同时篡改信息hash值情况,对hash值加密,接收方收到数据后,计算信息的hash值,对比传输解密后的hash值,即可获知信息是否未被修改。(加密细节后文详述)

clipboard.png

2 HTTP、TLS、HTTPS

2.1 HTTP

HTTP请求 clipboard.png

黑客拦截 clipboard.png

裸奔的HTTP信息容易被窃听甚至篡改。现在有2个问题:
1)如何确保客户端的通信对象是真正的服务器而非黑客
2)如何保证即使通信内容被黑客窃取也不会泄露真是内容

2.2 TLS

  • HTTPS比HTTP多一层SSL/TLS
  • SSL(Secure Socket Layer,安全套接字层)
  • TLS(Transport Layer Security,传输层安全)

SSL版本:SSL1.0、SSL2.0、SSL3.0
TLS版本:TLS1.0、TLS1.1、TLS1.2。
TLS是IETF制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。两者差别极小,可以理解为SSL 3.1。SSL3.0和TLS1.0由于存在安全漏洞,已经很少被使用到。TLS 1.3 改动会比较大,目前还在草案阶段,目前使用最广泛的是TLS 1.1、TLS 1.2。

clipboard.png

2.3 HTTPS

clipboard.png

1)Client请求,发送客户端信息(如:支持的非对称/对称加密算法、压缩方式等)+随机码1
2)Server响应,发送确认信息(如:确认后续使用的非对称/对称加密算法、压缩方式等)+数字证书+随机码2
2)Client校验数字证书真实性,确认后获得服务器公钥
3)Client确认,发送确认信息+随机码3,随机码3公钥加密
3)Server收到后,Clinet和Server都有3个随机数,组合生成密钥
4)Server确认,握手结束,下一步开始使用协商的对称加密算法+密钥进行通信
5)对称加密算法+密钥,请求,序号1
6)对称加密算法+密钥,响应,序号2
...

注意:

  • 为保证通信传递信息未被修改,信息发送前计算hash值与信息一起发送,接收方收到后可重新计算hash值并与收到hash值对比,确保传递信息未被修改。
  • 上步的计算信息hash值,有的文章中提到,为避免黑客同时修改内容与hash值,握手3)4)步应使用公钥&私钥加密对hash值加密,我理解这是不必要的,黑客目的是要获得随机码3并算出密钥,同时修改了内容与hash无法获取随机码3,并导致握手失败(Client与Server密钥对应不上),而且使用私钥加密并进行信息传递,本身存在被试探私钥加密规律的问题。
  • 握手结束后,通信含有序号,目的是为了避免黑客截取某些信息后原封不动重发多次,扰乱通信,添加序号后一旦序号不对应,立即终止通信。(序号具体实现待补充修改)

2.4 数字证书

2个概念:

指纹:数字证书主体的hash值
签名:使用CA(证书管理机构)的私钥,加密后的指纹

Client 校验证书确认服务器身份过程:

    操作系统安装时就已经自带权威CA机构的证书,这些证书里包含其CA公钥,用来解密数字证书的签名(被CA私钥加密)。

1)客户端收到服务器的数字证书A,查看A的Issuer证书发布机构,从操作系统中找到对应发布机构的CA证书,获取CA公钥
2)使用CA公钥解密证书签名,获得证书主体内容的hash1
3)重新计算证书主体内容得hash2,与hash1对比证明证书未被修改
4)从证书中获得服务器公钥,为HTTPS过程中加密协商做准备
步骤1~4确认数字证书本身真实性,确实为权威CA机构发布,而非伪造

5)确认服务器证书真实性后,对比访问域名与数字证书Subject证书所有者是否一致等信息,确认访问服务器真实性。
步骤5确认访问网站的真实性

133 声望
14 粉丝
0 条评论
推荐阅读
前端HTTP优化
实现上,可使用 webpack 配合系列插件,打包过程中可压缩源代码(去空格、换行、注释,JS混淆代码等等),webpack 配置复杂,不过多赘述

Eric1阅读 2.7k

Android安全之Https中间人攻击漏洞
HTTPS,是一种网络安全传输协议,利用SSL/TLS来对数据包进行加密,以提供对网络服务器的身份认证,保护交换数据的隐私与完整性。中间人攻击,Man-in-the-middle attack,缩写:MITM,是指攻击者与通讯的两端分别创...

YAQ御安全阅读 5.3k

拒绝裸奔,为 Elasticsearch 设置账号密码(qbit)
前言2019 年 5 月 21 日,Elastic 官方博客发文称,ES 6.8 和 7.1 免费开放基本的安全功能。包括: {代码...} 铭毅天下解读: Elasticsearch 7.1免费安全功能全景认知阮一鸣《Elasticsearch核心技术与实战》有对...

qbit阅读 6.4k

gitlab-ce将https修改为http
索性我们禁用gitlab的https功能,将期恢复为http。后期我们再在部署一个nginx进行数据转发,然后在nginx上起用https并设置证书。这样应该就规避了gitlab的证书错误问题。

myskies1阅读 617

gitlab-ce使用nginx做反向代理的方式启用https
由于某些未知的原因,gitlab-ce的https近期出现了问题,被chrome识别出是非安全的连接。索性我们将了gitlab-ce的https改为http。但当下https基本上已经成为了标准,不启用https好像有点说不过去。

myskies阅读 744

HTTPS 是这样握手的
HTTP协议默认是明文传输,存在一定的安全隐患,容易被中间人窃听和攻击,在 加密解决HTTP协议带来的安全问题 中提到使用哈希、对称加密、非对称加密等方式对数据加密,能解决数据安全的问题。

一颗冰淇淋阅读 636

使用nodejs的http和https下载远程资源,post数据
经常用到nodejs下载资源的情况(简单的爬虫),可以考虑直接使用nodejs内置的http/https模块。test.mjs {代码...} post数据 {代码...}

jsoncode阅读 513

133 声望
14 粉丝
宣传栏