HTTPS相关知识点

---

HTTPS相关知识点

一 背景知识
    1.基本术语 HTTP|HTTPS|SSL|TLS
    2.HTTP和TCP的关系，如长连接和短连接等
    3.加密算法的大概知识（对称加密和非对称加密）
    4.CA证书的用途

二 基本术语
    "HTTP":是一个专门用来传输web内容的协议。
        版本历史：
            0.9 90年代推出时候为0.9版本
            1.0 之后推出了1.0版本 该版本曾被广泛应用过
            1.1 这个 1.1 版本是1995年底开始起草的（技术文档是 RFC2068），并在1999年正式发布（技术文档是 RFC2616）
            2.0 2015年发布
    "SSL":是Secure Sockets Layer的缩写，翻译成中文叫做安全套接字层。上世界90年代由网景公司设计（该公司还发明了"!!!，js脚本等）
            HTTP协议在传输数据的时候是明文传输的，可能存在数据泄露（被嗅探）和篡改的问题。
            而SSL协议就是为了解决上述问题而提出的。到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。所以，SSL和TLS可以视作同一个东西的不同阶段。

    "HTTPS":即 HTTP + SSL

三 HTTP和TCP的关系
    1)"HTTP协议和TCP协议"
        TCP协议是HTTP协议的基石，即HTTP协议需要依靠TCP协议来传输数据。
        HTTP是应用层协议之一。
        TCP是传输层协议之一。
        有很多应用层的协议（如HTTP|SMTP等）都以TCP协议为基础来进行数据传输。
        传输层协议主要有TCP和UDP两种，区别在于TCP协议是可靠的。
    2)"短连接和长连接"
        HTTP 对TCP连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，英文为“Keep-Alive”或“Persistent Connection”）

    3)HTTP各个版本中TCP的连接方式
        假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS 文件和 JS 文件。在“短连接”的模式下，浏览器会先发起一个 TCP 连接，拿到该网页的 HTML 源代码（拿到 HTML 之后，这个 TCP 连接就关闭了）。然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（图片、CSS、JS）。然后针对【每一个】外部资源，再分别发起一个个 TCP 连接，把这些文件获取到本地（同样的，每抓取一个外部资源后，相应的 TCP 就断开）
        相反，如果是“长连接”的方式，浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。
        HTTP1.0 版本默认使用短连接，也叫作一次性连接。因为那个时候网页简单。
        HTTP1.1 版本中默认使用长连接，因为此时网页已经变得足够复杂，如果继续使用短连接的方式效率太低（因为建立TCP连接需要时间和CPU成本）

四 加密和解密
    加密：给你一个明文，可以通过一定的加密算法得到一串密文的过程。明文————>密文
    解密：给你一个密文，可以通过对应的解密算法得到初始原文的过程。密文————>明文
    对称加密：加密和解密使用相同的密钥。"速度快|效率高|存在密钥传输安全的问题"
    非对称加密：加密和解密使用不同的密钥。拥有一个公钥一个私钥，使用公钥进行加密使用私钥来进行解密。"速度慢|安全性强"
    对称加密和非对称加密的特点也影响到了SSL协议的设计。

五 HTTPS协议为什么要设计成这样？（WHY）
    1)兼容性问题 比如：①已有的web应用应该尽可能无缝的迁移到HTTPS，最好是做到零成本。②浏览器厂家改动应该尽可能的小
        ①"HTTPS协议还是基于TCP来进行传输"
        ②"把HTTP协议包裹起来成为一个新的协议"
        ③好比以前的HTTP协议是塑料水管容易戳破，现在就在以前塑料水管的基础上再包上一层金属管。这样就可以做到，原有的管道能够照常运行，且不再容易被戳破。
    2)可扩展性
        SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性
        如果把SSL看成是一层金属管，那么他不仅能够对输水管道进行加固，而且也能对输电管道，输煤气管道进行加固。
    3)保密性
        说白了以前是透明的塑料管道，随便花点功夫就能够知道传输的内容，而现在能够做到足够好的保密性。
    4)完整性
        能够确保HTTP协议的内容不被修改。
        因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP，ISP 很容易就可以在你访问的页面中植入广告
    5)真实性
        HTTPS 协议必须有某种机制来确保“真实性”的需求。
        如何确定我们访问的网站是真实的，关于这一点仅仅根据域名来判断是不靠谱的。因为我们的DNS系统本身就是不可靠的（域名欺骗和域名劫持），所以我们看到的网址里面的域名未必是真实的。
    6)性能
        使用HTTPS的时候性能不能太差，因此在设计的时候需要考虑两个问题：
        ① 加密和解密采用什么样的方式来进行：对称加密还是非对称加密？
        ② 采用什么样的连接方式：短连接还是长连接

六 设计HTTPS协议的难点
    个人认为最难的地方在于对传输数据进行加密和解密这一块，也就是密钥交换。
    如果客户端和服务器端需要进行HTTPS通信，那么首先需要协商双方应该采用什么样的加密算法，确定了加密算法之后还需要传输加密和解密中可能涉及到的密钥，而此时尚处于握手阶段，所有的数据传输都还是明文的，那么应该如何安全的传输密钥成为最大的问题。


七 解决密钥安全传输的问题
    1）单独使用对称加密来传输
            完全使用对称加密来传输"不具备可行性"，因为如果要使用对称加密，那么浏览器和客户端之间势必需要先交换"对称加密的密钥"。如果这个密钥直接用明文来传输，则很有可能会被攻击者偷窥到。
    2）使用非对称加密来传输 效率太低
    3）使用非对称加密+对称加密：存在中间人攻击隐患（需要具备篡改通信数据的能力）[伪造公钥][MITM]
    4）正是因为"缺乏身份认证机制"，所以我们需要考虑身份认证的问题。


八 身份认证的几种方式
    1) 基于某些私密共享的信息 |前提——通信双方认识彼此熟悉
    2）基于双方都信任的公证人 |如果通信双方都不认识彼此，那么就只能采用该模式（如C2C）
       那么，谁来充当这个公证人呢？"CA"华丽登场

    如何解决SSL的身份认证问题：使用CA
    CA数字证书在技术实现上依赖于非对称加密技术


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

扩充知识：
    网景（英语：Netscape）是一个自1994年开始的品牌。"1994年4月4"日它最初成立的名字是'马赛克通信公司'。该公司有一款名称为"网景导航者"的浏览器，因此"网景"也是是网景通信公司（Netscape Communications Corporation）的常用简称。网景通信公司曾经是一家美国的电脑服务公司，以其生产的同名网页浏览器而闻名。1998年11月，网景被美国在线（AOL）收购，2003年7月网景被解散，网景大部分的程序员被解雇，2008年3月1日美国在线宣布停止对网景浏览器的技术支持。

    网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布了第一版TLS标准文件

    IETF:互联网工程任务小组（英语：Internet Engineering Task Force，缩写为 IETF）负责互联网标准的开发和推动.

    该网站提供免费的安全证书：https://letsencrypt.org


SSL协议握手的过程：
通过握手，客户端和服务器协商各种参数用于创建安全连接：

    ① 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。
    ② 服务器从该列表中决定加密和散列函数，并通知客户端。
    ③ 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
    ④ 客户端确认其颁发的证书的有效性。
    ⑤ 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
    ⑥ 利用随机数，双方生成用于加密和解密的对称密钥。

    以上就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。


TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：

    ① 可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
    ② 可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
    ③ 在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
    ④ 增强服务器和客户端指定Hash和签名算法的能力。
    ⑤ 扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支持。
    ⑥ 添加TLS扩展定义和AES密码组合。
    ⑦ 所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用SSL 2.0以避免安全问题。

//HTTPS协议中关于SSL/TLS层握手过程的说明
 '阶段一：协商加密方式等参数 
 客户端 ① 我想要和你[服务端]进行安全的通话，我这里的支持的对称加密算法有DES|AES|RC5,密钥交换算法有RSA和DH,消息摘要算法有MD5和SHA1|SHA256
       ② [我说完了]

 服务端 ① 我们使用AES-RSA-SHA256的组合方式吧。
       ② 服务器端证书发送给客户端，并说[这是我的证书，里面有我的信息和公钥，你拿去验证一下我的身份吧]。
       ③ [我说完了]
 
        "——————该阶段双方已经协商好了加密[AES]__会话密钥交换[RSA]_消息校验[SHA256]的一套方法。

 '阶段二：验证证书的有效性并交换会话密钥
 客户端 ① 检查证书上面的信息，并通过已有的CA证书验证服务器端证书的真实性，如果有误则发出警告并断开连接。
       ② 客户端从接收到的证书中提取出公钥
       ③ 生成随机数作为会话密钥，即session key,该密钥将被在建立安全通道后用作对称加密的密钥。
       ④ 使用提取出来的公钥加密之前生成的会话密钥，封装成一个ClientKeyExchange消息[其实就是使用公钥对会话密钥进行加密之后的密文]。
       ⑤ 以后我就要使用session key对消息进行加密来和你进行通信了！
       ⑥ [我说完了]

      
 服务端 ① 使用自己的私钥对收到ClientKeyExchange消息进行解密，得到会话密钥，即session key。
            "【注】该消息由客户端使用服务器端发送给其的公钥进行加密，所以服务器端可以使用私钥来解密。
       ② 使用会话密钥加密初始化向量
            "【注】如果采用的是CBC分组模式进行加密处理则需要用到初始向量
       ③ 加密HMAC的密钥
       ④ 以后我也要使用session key对消息进行加密来和你进行通信了！
       ⑤ [我说完了]

        "——————该阶段完成会话密钥session key的安全交换。
    
 '阶段三：使用会话密钥加密消息，所有的消息在安全的信道中传输 
 客户端 ① 要发送给服务端的消息是CMsg:我的小秘密是....
       ② 使用会话秘钥对CMsg进行对称加密得到密文CMsg1:xxxxxooooooo
       ③ 把CMsg1发送给服务器端
 
 服务端 ① 接收到客户端发送来的消息CMsg1:xxxxxooooooo
       ② 使用本地的私钥对收到的消息Msg1进行解密，得到原文为CMsg:我的小秘密是....
       ③ 对客户端的消息进行响应，要发送给客户端的消息为SMsg:其它人不会听到的，我也有个小秘密...
       ④ 使用会话密钥对SMsg进行对称加密得到密文SMsg1:oooooxxxxxxx
       ⑤ 把SMsg1发送给客户端

        "——————该阶段在传输之前使用会话密钥对所有的消息进行对称加密处理。
        

ATS特性

1）iOS9中新增App Transport Security（简称ATS）特性, 让原来请求时候用到的HTTP，全部都转向TLS1.2协议进行传输。
2）这意味着所有的HTTP协议都强制使用了HTTPS协议进行传输。
3）如果我们在iOS9下直接进行HTTP请求是会报错。系统会告诉我们不能直接使用HTTP进行请求，需要在Info.plist中控制ATS的配置。
    "NSAppTransportSecurity"是ATS配置的根节点，配置了节点表示告诉系统要走自定义的ATS设置。
    "NSAllowsAritraryLoads"节点控制是否禁用ATS特性，设置YES就是禁用ATS功能。
4）有两种解决方法，一种是修改配置信息继续使用以前的设置。
    另一种解决方法是所有的请求都基于基于"TLS 1.2"版本协议。（该方法需要严格遵守官方的规定，如选用的加密算法、证书等）

/*
 ATS默认的条件
 1)服务器TLS版本至少是1.2版本
 2)连接加密只允许几种先进的加密
 3)证书必须使用SHA256或者更好的哈希算法进行签名，要么是2048位或者更长的RSA密钥，要么就是256位或更长的ECC密钥。
 */

AFSecurityPolicy，内部有三个重要的属性，如下：

AFSSLPinningMode SSLPinningMode;    //该属性标明了AFSecurityPolicy是以何种方式来验证
BOOL allowInvalidCertificates;      //是否允许不信任的证书通过验证，默认为NO
BOOL validatesDomainName;           //是否验证主机名，默认为YES

"AFSSLPinningMode"枚举类型有三个值，分别是AFSSLPinningModeNone、AFSSLPinningModePublicKey、AFSSLPinningModeCertificate。

"AFSSLPinningModeNone"代表了AFSecurityPolicy不做更严格的验证，"只要是系统信任的证书"就可以通过验证，不过，它受到allowInvalidCertificates和validatesDomainName的影响；

"AFSSLPinningModePublicKey"是通过"比较证书当中公钥(PublicKey)部分"来进行验证，通过SecTrustCopyPublicKey方法获取本地证书和服务器证书，然后进行比较，如果有一个相同，则通过验证，此方式主要适用于自建证书搭建的HTTPS服务器和需要较高安全要求的验证；

"AFSSLPinningModeCertificate"则是直接将本地的证书设置为信任的根证书，然后来进行判断，并且比较本地证书的内容和服务器证书内容是否相同，来进行二次判断，此方式适用于较高安全要求的验证。

如果HTTPS服务器满足ATS默认的条件，而且SSL证书是通过权威的CA机构认证过的，那么什么都不用做。如果上面的条件中有任何一个不成立，那么都只能修改ATS配置。