HTTPS简介

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HTTPS简介相关的知识,希望对你有一定的参考价值。

一、简单总结

1、HTTPS概念总结

HTTPS 就是对HTTP进行了TLS或SSL加密。

应用层的HTTP协议通过传输层的TCP协议来传输,HTTPS 在 HTTP和 TCP中间加了一层TLS/SSL加密层。

HTTP是明文传输,而现在HTTPS把明文加密后 再给TCP传输。

2、HTTPS实现的简化版

2.1、HTTPS在三次握手的时候用非对称加密生成 一个密钥,后面的数据通信就用这个密钥进行对称加密通信。这样既做到了安全性,又避免了非对称加密的效率问题。

2.2、有的时候我们需要做接口的安全性,如果用非对称加密是最安全的,但是效率比较低,如果用对称加密 安全性又不是很好。所以 也可以自己 简单模拟HTTPS来进行通信。

比如APP接口设计,我们用对称加密进行通信,如果对称加密的密钥放到APP中,是不安全的,可以用逆向工程拿到,如果用HTTPS的接口获取密钥,其实HTTPS里的内容也可以被解密,这个和客户端的代码也有关系(比如ios最常用的AFNetWorking就存在过漏洞),所以我们可以这么做:

  • APP请求接口,第一次先用非对称加密 请求接口 XXX/getAESSecretKey 来获取密钥(字符串)。

  • 剩下的请求都根据这个密钥来进行对称加密 通信。

上面两步就是简化版的HTTPS通信。

2.3、真正的HTTPS通信要比这个麻烦,我们刚才举例的密钥是事先定好的,而HTTPS是通过 三次握手 中每次都生成一次随机数,也就是客户端生成2次随机数,服务端生成1次随机数,并且服务端确定加密方法,然后客户端和服务端根据定好的加密规则,各自把这三个随机数生成同样的“对话密钥”,这个“对话密钥”就是后面数据通信用的 对称加密的 密钥。

这样每个客户端也 都有不同的 对称加密密钥。

二、HTTPS简介

HTTPS(Hypertext Transfer Protocol Secure):超文本传输安全协议。

HTTP的URL由“http://”起始,默认端口为80,HTTPS的URL由“https://”起始,默认端口为443。

HTTPS报文中的任何东西都被加密,包括所有报头和荷载。这样攻击者就获取不到有用的信息。

三、对称加密和非对称加密

1、概念

对称加密:文件加密和解密使用相同的密钥

非对称加密:需要两个密钥:公开密钥(publickey)和私有密钥(privatekey)。

用公钥对数据进行加密,只有用对应的私钥才能解密;如果用私钥对数据进行加密,那么只有用对应的公钥才能解密。

公钥 :用于向外发布,任何人都能获取。

私钥 :要自己保存,切勿给别人,一般只有运维的人才知道。

2、算法

对称加密常用的算法:DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等。

非对称加密常用的算法: RSA,ECDHE,DH,DHE、Elgamal、背包算法、Rabin、等。

3、能否被破解

RSA加密:还没人声称以破解。世纪金融体系就是靠着1RSA加密建立的,破解了这个,就可以伪造整个金融体系。

AES加密:标准的128位AES是10轮的。现在针对7轮的AES已经破解了,家用机几分钟就能搞定。破解标准的10轮,家用电脑,还不足以短时间内破解。。大型机已经可以算是破解了128位的,所以现在最低也要求256位的AES。

四、TLS

1、TLS历程:

  • 1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,但是未发布。

  • 1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。

  • 1996年,SSL 3.0版问世,得到大规模应用。

  • 1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。

  • 2006年,升级到TLS 1.1版

  • 2008年,升级到TLS 1.2版

  • 2011年,TLS 1.2的修订版

目前,应用最广泛的是TLS 1.0,然后是SSL 3.0。但是,主流浏览器都已经实现了TLS 1.2的支持。

TLS 1.0也可以标示为SSL 3.1,TLS 1.1为SSL 3.2,TLS 1.2为SSL 3.3。

前一段时间苹果对HTTPS支持的要求里面就要求为TLS1.2版本。

2、SSL/TLS协议的基本过程概要

  • 客户端发送请求给服务器,请求包含客户端生成的一个随机数和客户端版本信息。

  • 服务端回复给客户端,包括服务器证书、服务端生成的一个随机数、确定加密密算法。

  • 客户端验证服务器证书,生成一个随机数并用公钥加密,编码信息等。

客户端和服务端通过上面三个随机数,按照第二步确定的加密方法,生成各自的"会话密钥","会话密钥"就是对称加密的密钥。

  • 服务端发送给客户端之前商定的编码信息

  • 双方采用"对话密钥"进行对称加密通信。

因为公钥放在数字证书中。只要证书是可信的,公钥就是可信的。这样就能保证公钥不被篡改。

双方协商生成"对话密钥"。"对话密钥"是对称加密,所以运算速度非常快,而服务器公钥只用于加密"对话密钥"本身,这样就减少了加密运算的消耗时间。

前两个都在握手(明文通信)阶段完成的。

3、下面是详细步骤,摘自阮一峰的《SSL/TLS协议运行机制的概述》:

3.1、客户端(比如浏览器)先向服务器发出加密通信的请求,这被叫做ClientHello请求。

在这一步,客户端主要向服务器提供以下信息。

(1) 支持的协议版本,比如TLS 1.0版。

(2) 一个客户端生成的随机数,稍后用于生成"对话密钥"。

(3) 支持的加密方法,比如RSA公钥加密。

(4) 支持的压缩方法。

客户端发送的信息之中不包括服务器的域名。也就是说,理论上服务器只能包含一个网站,否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说,这当然很不方便。2006年,TLS协议加入了一个Server Name Indication扩展,允许客户端向服务器提供它所请求的域名。

3.2、服务器回应(SeverHello)

服务器收到客户端请求后,向客户端发出回应,这叫做SeverHello。服务器的回应包含以下内容。

(1) 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。

(2) 一个服务器生成的随机数,稍后用于生成"对话密钥"。

(3) 确认使用的加密方法,比如RSA公钥加密。

(4) 服务器证书。

除了上面这些信息,如果服务器需要确认客户端的身份,就会再包含一项请求,要求客户端提供"客户端证书"。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。

3.3、客户端回应

客户端收到服务器回应以后,首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。

如果证书没有问题,客户端就会从证书中取出服务器的公钥。然后,向服务器发送下面三项信息。

(1) 一个随机数。该随机数用服务器公钥加密,防止被窃听。

(2) 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。

(3) 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。

上面第一项的随机数,是整个握手阶段出现的第三个随机数,又称"pre-master key"。有了它以后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。

此外,如果前一步,服务器要求客户端证书,客户端会在这一步发送证书及相关信息。

3.4、服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。然后,向客户端最后发送下面信息。

(1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。

(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。

至此,整个握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用"会话密钥"加密内容。

五、证书

刚才我们提到通信中要用到证书,公钥就在证书里面。证书还包括域名、公司信息、序列号和签名信息等。

证书分为自签名证书 和 CA 证书。

1、自签名证书,可以自己生成,但是 容易被假冒和伪造、容易受到SSL中间人攻击、证书有效期太长、法被吊销(如果你的私钥被黑客获取,证书不能被吊销,则黑客可以伪装成你与用户进行通信)。

2、CA:数字证书认证机构 Certificate Authority

任何个体/组织都可以扮演 CA 的角色,只不过难以得到客户端的信任,能够受浏览器默认信任的 CA 大厂商有很多,其中 TOP5 是 Symantec、Comodo、Godaddy、GolbalSign 和 Digicert。

需要花钱购买,比如淘宝用的是GlobalSign 的。

六、SSL单向认证和双向认证

双向认证:需要服务端与客户端都提供证书,只能是服务端允许的客户能去访问,安全性相对于要高一些。客户端需要安装证书。

单向认证:只要求站点部署了ssl证书就行,任何用户都可以去访问(IP被限制除外等),只是服务端提供了身份认证。一般的网站都是单向认证。

七、其他

1、因为前段时间苹果要求HTTPS的规则里 要求用ECDH_RSA和ECDHE_ECDSA算法,所以这里简单说下。

上面说过ECDHE 是非对称加密算法的一种。

  • RSA:算法实现简单,诞生于 1977 年,安全性高。缺点就是需要比较大的素数(目前常用的是 2048 位)来保证安全强度,很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。

  • DH:diffie-hellman 密钥交换算法,诞生于1977 年,但是 1999 年才公开。缺点是比较消耗 CPU 性能。

  • ECDHE:使用椭圆曲线(ECC)的 DH 算法,优点是能用较小的素数(256 位)实现 RSA 相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,有的客户端不支持。

  • ECDH:不支持 PFS,安全性低,同时无法实现 false start。

  • DHE:不支持 ECC。非常消耗 CPU 资源。

建议优先支持 RSA 和 ECDH_RSA 密钥交换算法。原因是:

  • ECDHE 支持 ECC 加速,计算速度更快。支持 PFS,更加安全。支持 false start,用户访问速度更快。

  • 目前还有至少 20% 以上的客户端不支持 ECDHE,我们推荐使用 RSA 而不是 DH 或者 DHE,因为 DH 系列算法非常消耗 CPU(相当于要做两次 RSA 计算)。

另外,DSA和ECDSA(椭圆曲线签名算法)都只是签名算法,它用来确保信息发布人的身份和信息的完整性,不能用来做加密传输

2、因为HTTPS连接所用的公钥以明文传输,因此中国的防火长城可以对特定网站按照匹配的黑名单证书,通过伪装成对方向连接两端的计算机发送RST包干扰两台计算机间正常的TCP通讯,以打断与特定IP地址之间的443端口握手,或者直接使握手的数据包丢弃,导致握手失败,从而导致TLS连接失败。这也是一种互联网信息审查和屏蔽的技术手段。

 

我的今日头条号:终极iOS程序猿,大家可以直接打开网站,或者从今日头条里搜索“终极iOS程序猿”,欢迎大家多多关注,多多点赞,谢谢。

以上是关于HTTPS简介的主要内容,如果未能解决你的问题,请参考以下文章

计算机网络HTTP 与 HTTPS ( HTTPS 简介 | HTTP 通信过程 )

HTTPS简介

Kafka简介+Kafka Tool使用简介+使用实例

Https协议简介

Https协议简介

https证书申请流程和简介