深刻了解解析Https - 从了解到放弃

Https的概念

如下相关名词均摘自wikipedia

Https 超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种经过计算机网络进行安全通讯的传输协议。HTTPS经由HTTP进行通讯，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。

SSL 安全套接层（Secure Sockets Layer）是netscape设计的主要用于Web的安全传输协议,位于可靠的面向链接的网络层协议和应用层协议之间的一种协议层。

TLS 传输层安全协议（英语：Transport Layer Security） 用于两个应用程序之间提供保密性和数据完整性。

IETF 互联网工程任务小组（英语：Internet Engineering Task Force，縮寫為IETF）负责互联网标准的开发和推进。

TLS与SSL关系

TLS的前身是 SSL3.0 协议，最先由netscape公司于 1995 年发布，1999 年通过 IETF 讨论和规范后，更名为 TLS。若是没有特别说明，SSL 和 TLS 说的都是同一个协议。

目前有如下几个版本：SSLv2，SSLv3，TLSv1，TLSv1.1，TLSv1.2，TLSv1.3(草案)当前基本再也不使用低于 TLSv1 的版本

Https与Http

TLS/SSL协议的基本概念

TLS/SSL的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性

• 散列函数Hash：常见的有 MD五、SHA一、SHA256，该类函数特色是函数单向不可逆、对输入很是敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性；

• 对称加密：常见的有 AES-CBC、DES、3DES、AES-GCM等，相同的密钥能够用于信息的加密和解密，掌握密钥才能获取信息，可以防止信息窃听，通讯方式是1对1；

• 非对称加密：即常见的 RSA、ECDHE、DH 、DHE等算法，算法特色是，密钥成对出现，通常称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。所以掌握公钥的不一样客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通讯，服务器能够实现1对多的通讯，客户端也能够用来验证掌握私钥的服务器身份。

对称加密的弊端

1. 要求提供一条安全的通道使通讯双方在首次通讯时协商一个共同的密钥。直接面对面协商可能难于实施，因此双方须要借助于邮件和电话等其余相对不够安全的手段来进行协商。

2. 密钥的数目难于管理。由于对于每个合做者都须要使用不一样的密钥，很难适应开放社 会中大量的信息交流。 对称加密算法通常不能提供信息完整性的鉴别。它没法验证发送者和接受者的身份。

3. 对称密钥的管理和分发工做是一件具备潜在危险的、繁琐的过程。对称加密是基于共同保守秘密来实现的，采用对称加密技术的贸易双方必须保证采用的是相同的密钥，保证彼此密钥的交换是安全可靠的，同时还要设定防止密匍泄密和更改密钥的程序。

非对称加密的弊端

先天不足

在公开密钥密码体制中，经常使用的一种是RSA加密算法。其数学原理是将一个大数分解成两个质数的乘积，加密和解密用的是两个不一样的密钥。即便己知明文、密文和加密密钥(公钥)，想要推导出解密密钥(私钥)，在计算上是不可能的。按如今的计算机技术水平，要破解目前采用的1024位RSA密钥，须要上千年的计算时间。公开密钥技术解决了密钥发布的管理问题，商家能够公开其公开密钥，而保留其私有密钥。在2010年之后，均采用了2048位的签名

身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但RSA算法没法确保服务器身份的合法性，由于公钥并不包含服务器的信息

中间人攻击和信息抵赖

1. 客户端C和服务器S进行通讯，中间节点M截获了两者的通讯；

2. 节点M本身计算产生一对公钥pub_M和私钥pri_M；

3. C向S请求公钥时，M把本身的公钥pub_M发给了C；

4. C使用公钥 pub_M加密的数据可以被M解密，由于M掌握对应的私钥pri_M，而 C没法根据公钥信息判断服务器的身份，从而 C和 M之间创建了"可信"加密链接；

5. 中间节点 M和服务器S之间再创建合法的链接，所以 C和 S之间通讯被M彻底掌握，M能够进行信息的窃听、篡改等操做。

6. 服务器也能够对本身的发出的信息进行否定，不认可相关信息是本身发出。

横空出世的CA验证及证书

CA （Certification Authority）负责审核信息，而后对关键信息利用私钥进行"签名"，公开对应的公钥，客户端能够利用公钥验证签名。CA也能够吊销已经签发的证书，具体的流程以下：

相关

1. 申请证书不须要提供私钥，确保私钥永远只能服务器掌握；
2. 证书的合法性仍然依赖于非对称加密算法，证书主要是增长了服务器信息以及签名；
3. 内置 CA 对应的证书称为根证书，颁发者和使用者相同，本身为本身签名，即自签名证书；
4. 证书=公钥+申请者与颁发者信息+签名；
5. 公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

如何验证证书的合法性

客户端针对服务端用私钥对证书信息签名的校验

当客户端对服务端发送client_hello以后 服务端会将公开的密钥证书发送给客户端,证书中包含了公钥,各类信息,签名(ca针对证书的摘要信息进行私钥加密)

当客户端接收到证书后会经过内置ca公钥对签名进行解密已验证证书的合法性.若是已知的ca公钥均没法解密证书签名,则认定当前证书不是被承认的证书(没有颁布本证书或者证书被伪造)

证书链

证书链 :服务器证书、中间证书与根证书在一块儿组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。

如 CA根证书和服务器证书中间增长一级证书机构，即中间证书，证书的产生和验证原理不变，只是增长一层验证，只要最后可以被任何信任的CA根证书验证合法便可。

1. 服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为本身签发的有效证书；
2. 中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为本身签发的合法证书；
3. 客户端内置信任 CA 的 root.pem 证书，所以服务器证书 server.pem 的被信任。

证书链的优点与特色

• 减小根证书结构的管理工做量，能够更高效的进行证书的审核与签发；
• 根证书通常内置在客户端中，私钥通常离线存储，一旦私钥泄露，则吊销过程很是困难，没法及时补救；
• 中间证书结构的私钥泄露，则能够快速在线吊销，并从新为用户签发新的证书；
• 证书链四级之内通常不会对 HTTPS 的性能形成明显影响。
• 同一本服务器证书可能存在多条合法的证书链。由于证书的生成和验证基础是公钥和私钥对，若是采用相同的公钥和私钥生成不一样的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不一样的是中间证书的签发机构不一样；
• 不一样证书链的层级不必定相同，可能二级、三级或四级证书链。中间证书的签发机构多是根证书机构也多是另外一个中间证书机构，因此证书链层级不必定相同。

证书吊销

CA 机构可以签发证书，一样也存在机制宣布以往签发的证书无效。证书使用者不合法，CA 须要废弃该证书；或者私钥丢失，使用者申请让证书无效。主要存在两类机制：CRL与OCSP。

CRL

Certificate Revocation List， 证书吊销列表，是一个单独的文件。该文件包含了 CA 已经吊销的证书序列号(惟一)与吊销日期，同时该文件包含生效日期并通知下次更新该文件的时间，固然该文件必然包含 CA 私钥的签名以验证文件的合法性。

在证书中通常会包含一个 URL 地址 CRL Distribution Point，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优势是不须要频繁更新，可是不能及时吊销证书，由于 CRL 更新时间通常是几天，这期间可能已经形成了极大损失。

OCSP

Online Certificate Status Protocol， 证书状态在线查询协议，一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。

证书中通常也会包含一个 OCSP 的 URL 地址，要求查询服务器具备良好的性能。部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的，对于吊销证书会是一件很是麻烦的事情。

TLS/SSL握手过程

X.509

X.509 是一个标准，也是一个数字文档，这个文档根据RFC 5280来编码并签发，一份X.509证书是一些标准字段的集合，这些字段包含有关用户或设备及其相应公钥的信息。

编码 (也用于扩展名)

• .DER - 扩展名DER用于二进制DER编码的证书，不可读。这些证书也能够用CER或者CRT做为扩展名。 Java和Windows服务器偏向于使用这种编码格式，比较合适的说法是“我有一个DER编码的证书”，而不是“我有一个DER证书”。

• .PEM - 扩展名PEM用于ASCII(Base64)编码的各类X.509 v3 证书。以“-----BEGIN...”开头， “-----END...”结尾，内容是BASE64编码，Apache和Linux服务器偏向于使用这种编码格式。

经常使用的扩展名

• .KEY - 一般用来存放一个公钥或者私钥，并不是X.509证书，编码多是PEM，也多是DER.

• .CSR - 是Certificate Signing Request的缩写，即证书签名请求，这不是证书，是生成证书时要把这个提交给权威的证书颁发机构。其核心内容是一个公钥(固然还附带了一些别的信息)，在生成这个申请的时候，同时也会生成一个私钥，私钥要本身保管好.当权威证书颁发机构颁发的证书过时的时候，你还能够用一样的csr来申请新的证书，key保持不变.

• .CRT - certificate的缩写，其实仍是证书的意思，常见于Linux系统，有多是PEM或者DER编码，大多数应该是PEM编码.

• .CER - certificate的缩写，其实仍是证书的意思，常见于Windows系统，有多是PEM或者DER编码，大多数应该是DER编码.

注意：CRT文件和CER文件只有在使用相同编码的时候才能够安全地相互替代。

• .PFX/PKCS12 - predecessor of PKCS#12，包含了证书和私钥，对Linux服务器来讲，通常来讲CRT和KEY是分开存放在不一样文件中的，但Windows的IIS则将它们存在一个PFX文件中，并经过提取密码来保护。

• .JKS/JCEKS - Java密钥库(KeyStore)的两种比较常见类型，包含了证书和私钥，利用Java的“keytool”的工具，能够将PFX转为JKS，固然了，keytool也能直接生成JKS，JCEKS在安全级别上要比JKS强，使用的Provider是JCEKS(推荐)，使用使用TripleDES 保护KeyStore中的私钥；

• .BKS – Bouncy Castle Provider，包含了证书和私钥， android系统支持的类型，它使用的也是TripleDES来保护密钥库中的私钥，它可以防止证书库被不当心修改（Keystore的keyentry改掉1个bit都会产生错误），BKS可以跟JKS互操做。

注意：经过工具 BKS、JKS、PFX 三种格式的证书都可以相互转换

OpenSSL

OpenSSL简单地说，OpenSSL是SSL的一个实现，SSL只是一种规范理论上来讲，SSL这种规范是安全的，目前的技术水平很难破解，但SSL的实现就可能有些漏洞，如著名的“心脏出血”。OpenSSL还提供了一大堆强大的工具软件，强大到90%咱们都用不到.

证书编码的转换

PEM转为DER openssl x509 -in cert.crt -outform der -out cert.der DER转为PEM openssl x509 -in cert.crt -inform der -outform pem -out cert.pem (提示:要转换KEY文件也相似，只不过把x509换成rsa，要转CSR的话，把x509换成req...)

"心脏出血"事件

2014年曝光了OpenSSL的源代码中存在一个漏洞，可让攻击者得到服务器上64K内存中的数据内容

OpenSSL心脏出血漏洞的大概原理是OpenSSL在2012年引入了心跳(heartbeat)机制来维持TLS连接的长期存在，心跳机制是做为TLS的扩展实现，但在代码中包括TLS(TCP)和DTLS(UDP)都没有作边界的检测，因此致使攻击者能够利用这个漏洞来得到TLS连接对端（能够是服务器，也能够是客户端）内存中的一些数据，至少能够得到16KB每次，理论上讲最大能够获取64KB。

Alexa排名前百万的网站中有40.9%的网站收到影响

Https主要流程

client	server
1 Client Hello
	2 Server Hello
	3 certificate
	4 server_key_exchange(DH加密须要)
	5 certificate_request(双向验证须要)
	6 server_hello_done
7 certificate(双向验证须要)
8 client_key_exchange
9 certifiate_verify(双向验证须要)
10 change_cypher_spec
11 encrypted handshake message
----finished----
	12 change_cypher_spec
	13 encrypted handshake message
	----finished----

Wireshark抓包实例

1. Client Hello (C-S)

   

1.提供最高支持的TLS/SSl版本 2.客户端生成随机数random_c 3.客户端支持的加密方式

2. Server Hello(S-C)

   

   1.协商后使用的TLS/SSl版本 2.服务端生成随机数random_s 3.协商后使用的加密方式

   (上图中使用的是RSA和DH混合使用的方式,RSA验证服务器身份,DH算法加密密钥)

3. Certificate (S-C)/可选

   

提供服务器的身份证书给客户端鉴定，若是不用公钥证书体系验证身份和交换密钥，该步骤可选，好比在用DH方法交换的时候。

4. Server Key Exchange (S-C)/可选

   

密钥交换用到的服务器方的信息，通常是补充上次的 [Certificate]指令的信息，若是才用DH加密算算法须要提供.

5. certificate_request(S-C)/可选 服务端要求客户端提供证书,包括客户端能够提供的证书类型及服务器接受的证书distinguished name列表，能够是root CA或者subordinate CA

6. Server Hello Done (S-C)

   

   结束服务器端的握手过程

7. certificate(C-S)/可选 若是服务端须要客户端提供证书,则在此提供客户端的证书

8. Client Key Exchange (C-S)

   

   客户端会在生成一个随机数pubkey并将它发送到服务端,客户端与服务端均会根据以前生成的random_c,random_s,pubkey三个随机数生成对称加密的session secret

9. certifiate_verify(C-S)/可选 发送使用客户端证书给到这一步为止收到和发送的全部握手消息签名结果

10. Change Cipher Spec (C-S)

通知服务端接下来的数据均采用session secret为key对称加密方式 11. Encrypted Handshake Message(C-S)

客户端随后马上发送了一个通过加密的消息, 服务端应该能够根据生成的session secret来进行解密,这个加密的消息解密之后是有固定格式的，符合这个格式，或则知足一些字符匹配，才是合法的。

12. Change Cipher Spec(S-C)

通知客户端接下来的数据均采用被session secret加密的对称加密方式

13. Encrypted Handshake Message(S-C)

服务端随后也马上发送了一个通过加密的消息,让给客户端进行验证

14. 正式的数据交互 随后两端都会经过已经协商好的session secret做为key的对称加密方式经过http协议进行数据交互

自签名证书的不安全性

1. 自签证书最容易被假冒和伪造，而被欺诈网站所利用

• 自签证书最容易受到SSL中间人攻击
• 以上这两点都是因为自签证书不受浏览器信任，而网站告诉用户要信任而形成
• 自签证书支持不安全的SSL通讯从新协商机制(Dos及中间人攻击)
• 自签证书支持很是不安全的SSL V2.0协议
• 自签证书没有可访问的吊销列表
• 自签证书使用1024位的非对称密钥对
• 自签证书证书有效期太长，短则5年，长则20年、30年

HTTPS性能损耗

增长延时

分析前面的握手过程，一次完整的握手至少须要两端依次来回两次通讯，至少增长延时2RTT（Round-Trip Time，往返时间），利用会话缓存从而复用链接，延时也至少1 RTT。

消耗较多的CPU资源

除数据传输以外，HTTPS通讯主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据)；压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密须要消耗 CPU 约17核，24核CPU最多接入 HTTPS 链接 4800； 静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，若是将全部的HTTP链接变为HTTPS链接，则明显RSA的解密最早成为瓶颈。所以，RSA的解密能力是当前困扰HTTPS接入的主要难题。

HTTPS接入优化

CDN接入

HTTPS 增长的延时主要是传输延时 RTT，RTT 的特色是节点越近延时越小，CDN 自然离用户最近，所以选择使用 CDN 做为 HTTPS 接入的入口，将可以极大减小接入延时。CDN 节点经过和业务服务器维持长链接、会话复用和链路质量优化等可控方法，极大减小 HTTPS 带来的延时。

会话缓存

虽然前文提到 HTTPS 即便采用会话缓存也要至少1*RTT的延时，可是至少延时已经减小为原来的一半，明显的延时优化；同时，基于会话缓存创建的 HTTPS 链接不须要服务器使用RSA私钥解密获取 Pre-master 信息，能够省去CPU 的消耗。若是业务访问链接集中，缓存命中率高，则HTTPS的接入能力讲明显提高。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际能够承载13k/的接入，收效很是可观。

硬件加速

为接入服务器安装专用的SSL硬件加速卡，做用相似 GPU，释放 CPU，可以具备更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡能够提供35k的解密能力，至关于175核 CPU，至少至关于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡能够实现接近10台服务器的接入能力。

远程解密

本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则能够充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器能够选择 CPU 负载较低的机器充当，实现机器资源复用，也能够是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。

SPDY/HTTP2

前面的方法分别从减小传输延时和单机负载的方法提升 HTTPS 接入性能，可是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优点，经过修改协议的方法来提高 HTTPS 的性能，提升下载速度等。

最后

在这里我总结出了互联网公司Android程序员面试简历模板，面试涉及到的绝大部分面试题及答案作成了文档和架构视频资料免费分享给你们【包括高级UI、性能优化、架构师课程、NDK、Kotlin、混合式开发（ReactNative+Weex）、Flutter等架构技术资料】，但愿能帮助到您面试前的复习且找到一个好的工做，也节省你们在网上搜索资料的时间来学习。

资料获取方式：加入Android架构交流QQ群聊：513088520 ，进群即领取资料！！！

点击连接加入群聊【Android移动架构总群】：加入群聊