二
https 當中的「s」代表的是「安全」（secure），在登入銀行或電郵賬號時，你會常常看到它出現在瀏覽器位址列。不過，移動應用在網路連線安全性上面沒有那麼透明，使用者很難知道應用連線網路時使用的是 http 還是 https。
ats 由此登場，它在 ios 9 當中是預設開啟的。然而，開發者仍然能夠關閉 ats，讓自己的應用通過 http 連線傳輸資料——現在的情況是，這招在年底之後就行不通了。（技術人員注意：ats 要求使用 tls v 1.2，但那些已經經過加密的批量資料例外，比如流**資料。）
三為什麼這麼做？
四 開發者應該做什麼？
首先需要選擇合適的證書為部署https證書做決策，然後調整後台應用實現後台應用全站https，協調運營及開發完成部署完善服務端應用部署及web伺服器配置，最後以安全方式發布應用完成應用改造，重新發布應用。
五 https的基礎原理和通訊過程
https(secure hypertext transfer protocol) 安全超文字傳輸協議 它是乙個安全通訊通道，它基於 http 開發，用於在客戶計算機和伺服器之間交換資訊。它使用安全套接字層(ssl)進行資訊交換，簡單來說它是 http 的安全版,是使用 tls/ssl 加密的 http 協議。
http 協議採用明文傳輸資訊，存在資訊竊聽、資訊篡改和資訊劫持的風險，而協議 tls/ssl 具有身份驗證、資訊加密和完整性校驗的功能，可以避免此類問題。
tls/ssl 全稱安全傳輸層協議 transport layer security, 是介於 tcp 和 http 之間的一層安全協議，不影響原有的 tcp 協議和 http 協議，所以使用 https 基本上不需要對 http 頁面進行太多的改造。
1、tls/ssl 原理
https 協議的主要功能基本都依賴於 tls/ssl 協議，本節分析安全協議的實現原理。
tls/ssl 的功能實現主要依賴於三類基本演算法：雜湊函式 hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函式驗證資訊的完整性。
雜湊函式 hash，常見的有 md5、sha1、sha256，該類函式特點是函式單向不可逆、對輸入非常敏感、輸出長度固定，針對資料的任何修改都會改變雜湊函式的結果，用於防止資訊篡改並驗證資料的完整性；對稱加密，常見的有 aes-cbc、des、3des、aes-gcm等，相同的金鑰可以用於資訊的加密和解密，掌握金鑰才能獲取資訊，能夠防止資訊竊聽，通訊方式是1對1；非對稱加密，即常見的 rsa 演算法，還包括 ecc、dh 等演算法，演算法特點是，金鑰成對出現，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的資訊只能私鑰解開，私鑰加密的資訊只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密資訊，只能和掌握私鑰的伺服器進行加密通訊，伺服器可以實現1對多的通訊，客戶端也可以用來驗證掌握私鑰的伺服器身份。
在資訊傳輸過程中，雜湊函式不能單獨實現資訊防篡改，因為明文傳輸，中間人可以修改資訊之後重新計算資訊摘要，因此需要對傳輸的資訊以及資訊摘要進行加密；對稱加密的優勢是資訊傳輸1對1，需要共享相同的密碼，密碼的安全是保證資訊保安的基礎，伺服器和 n 個客戶端通訊，需要維持 n 個密碼記錄，且缺少修改密碼的機制；非對稱加密的特點是資訊傳輸1對多，伺服器只需要維持乙個私鑰就能夠和多個客戶端進行加密通訊，但伺服器發出的資訊能夠被所有的客戶端解密，且該演算法的計算複雜，加密速度慢。
結合三類演算法的特點，tls 的基本工作方式是，客戶端使用非對稱加密與伺服器進行通訊，實現身份驗證並協商對稱加密使用的金鑰，然後對稱加密演算法採用協商金鑰對資訊以及資訊摘要進行加密通訊，不同的節點之間採用的對稱金鑰不同，從而可以保證資訊只能通訊雙方獲取。
2、pki 體系
（1）rsa 身份驗證的隱患
身份驗證和金鑰協商是 tls 的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但 rsa 演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊，存在安全隱患：
客戶端 c 和伺服器 s 進行通訊，中間節點 m 截獲了二者的通訊；
節點 m 自己計算產生一對公鑰 pub_m 和私鑰 pri_m;
c 向 s 請求公鑰時，m 把自己的公鑰 pub_m 發給了 c;
c 使用公鑰 pub_m 加密的資料能夠被 m 解密，因為 m 掌握對應的私鑰 pri_m，而 c 無法根據公鑰資訊判斷伺服器的身份，從而 c 和 m 之間建立了」可信」加密連線；
中間節點 m 和伺服器s之間再建立合法的連線，因此 c 和 s 之間通訊被m完全掌握，m 可以進行資訊的竊聽、篡改等操作。
另外，伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。
因此該方案下至少存在兩類問題：中間人攻擊和資訊抵賴。
而隨著2023年行將結束，我們發現，這一天，已經越來越近了。
（2）身份驗證-ca 和證書
解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的，能夠驗證伺服器的身份資訊，為此需要引入權威的第三方機構 ca。ca 負責核實公鑰的擁有者的資訊，並頒發認證」證書」，同時能夠為使用者提供證書驗證服務，即 pki 體系。
基本的原理為，ca 負責審核資訊，然後對關鍵資訊利用私鑰進行」簽名」，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。ca 也可以吊銷已經簽發的證書，基本的方式包括兩類 crl 檔案和 ocsp。ca 使用具體的流程如下：
a.服務方 s 向第三方機構ca提交公鑰、組織資訊、個人資訊(網域名稱)等資訊並申請認證；
b.ca 通過線上、線下等多種手段驗證申請者提供資訊的真實性，如組織是否存在、企業是否合法，是否擁有網域名稱的所有權等；
c.如資訊審核通過，ca 會向申請者簽發認證檔案-證書。
證書包含以下資訊：申請者公鑰、申請者的組織資訊和個人資訊、簽發機構 ca 的資訊、有效時間、證書序列號等資訊的明文，同時包含乙個簽名；
簽名的產生演算法：首先，使用雜湊函式計算公開的明文資訊的資訊摘要，然後，採用 ca 的私鑰對資訊摘要進行加密，密文即簽名；
d.客戶端 c 向伺服器 s 發出請求時，s 返回證書檔案；
e.客戶端 c 讀取證書中的相關的明文資訊，採用相同的雜湊函式計算得到資訊摘要，然後，利用對應 ca 的公鑰解密簽名資料，對比證書的資訊摘要，如果一致，則可以確認證書的合法性，即公鑰合法；
f.客戶端然後驗證證書相關的網域名稱資訊、有效時間等資訊；
g.客戶端會內建信任 ca 的證書資訊(包含公鑰)，如果ca不被信任，則找不到對應 ca 的證書，證書也會被判定非法。
在這個過程注意幾點：
1.申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握；
2.證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器資訊以及簽名；
3.內建 ca 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書；
4.證書=公鑰+申請者與頒發者資訊+簽名；
HTTP通訊原理和HTTPS通訊原理
本博主參加位元組跳動第一次面試的時候，發現自己對於網路協議這方面欠缺很嚴重，並且在資訊保安課程中學到了部分數字證書的概念，故特意整理部落格以加強自己對於部分協議體系的理解。http 協議 hypertext transfer protocol，超文字傳輸協議 是客戶端瀏覽器或其他程式與web伺服器之...
HTTPS的過程和原理
1.握手的時候使用的非對稱加密演算法 用來加密握手之後的請求和應答 2.傳輸資訊的時候使用的對稱加密，3.保證資料的完整性用的是hash演算法 數字簽名 在了解https之前,得先了解對稱加密和非對稱加密 對稱加密 這就是對稱加密演算法，其中圖中的金鑰s同時扮演加密和解密的角色。具體細節不是本文範疇...
https 建立通訊原理與過程
一 https簡介 二 https與http的區別 1 https的伺服器需要到ca申請證書，以證明自己伺服器的用途 2 http資訊是明文傳輸，https資訊是密文傳輸 3 http與https的埠不同，乙個是80埠，乙個是443埠 可以說http與https是完全不同的連線方式，https集合了...