Ⅰ android 使用 HTTPS
如果你的項目的網路框架是okhttp，那麼使用https還是挺簡單的，因為okhttp默認支持HTTPS。 傳送門
Android 使用 HTTPS 配置的步驟。
配置hostnameVerifier
2.step
配置 sslSocketFactory
調用 getSslSocketFactory(null,null,null) 即可。
3.step
設置OkhttpClient。
方法 getSslSocketFactory(null,null,null) 的第一個參數 本來要傳入自簽名證書的，當傳入null 即可忽略自簽名證書。
如果你想嘗試不忽略自簽名證書 你可以調用下面的方法獲取 SSLSocketFactory。並設置到OkhttpClient中。
通過上面的幾步配置即可使用https的自簽名證書 和 單向驗證的Https了。
Glide 訪問Https的圖片
1.step
在build.gradle 引入下面的aar
2.step
設置已經驗證證書的的OkhttpClient 到Glide 既可。
END.
Ⅱ Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程
由身份或持有的令牌確認享有的許可權，登錄過程實質上的目的也是為了確認許可權。
Cookie是客戶端給伺服器用的，setCookie是伺服器給客戶端用的。cookie由伺服器處理，客戶端負責存儲
客戶端發送cookie：賬戶和密碼
服務端收到後確認登錄setCookie：sessionID=1，記下sessionID
客戶端收到sessionID後記錄，以後請求服務端帶上對比記錄下sessionID，說明已經登錄
會話管理：登錄狀態，購物車
個性化：用戶偏好，主題
Tracking：分析用戶行為
XXS：跨腳本攻擊，及使用javaScript拿到瀏覽器的cookie之後，發送到自己的網站，以這種方式來盜用用戶Cookie。Server在發送Cookie時，敏感的Cookie加上HttpOnly，這樣Cookie只能用於http請求，不能被JavaScript調用
XSRF:跨站請求偽造。Referer 從哪個網站跳轉過來
兩種方式：Basic和Bearer
首先第三方網站向授權網站申請第三方授權合作，拿到授權方頒發的client_id和client_secret（一般都是appid+appkey的方式）。
在這就過程中申請的client_secret是伺服器持有的，安全起見不能給客戶端，用服務端去和授權方獲取用戶信息，再傳給客戶端，包括④，⑤的請求過程也是需要加密的。這才是標準的授權過程。
有了access_token之後，就可以向授權方發送請求來獲取用戶信息
步驟分析就是上面的內容，這里把第4,6,8請求的參數分析一下
第④步參數：
response_type：指授權類型，必選，這里填固定值『code』
client_id：指客戶端id，必選，這里填在平台報備時獲取的appid
redirect_uri：指重定向URI，可選
scope：指申請的許可權范圍，可選
state：指客戶端當前狀態，可選，若填了，則認證伺服器會原樣返回該值
第⑥步參數：
grant_type：指使用哪種授權模式，必選，這里填固定值『authorization_code』
code：指從第⑤步獲取的code，必選
redirect_uri：指重定向URI，必選，這個值需要和第④步中的redirect_uri保持一致
client_id：指客戶端id，必選，這里填在平台報備時獲取的appid
client_secret：指客戶端密鑰，必選，這里填在平台報備時獲取的appkey
第⑧步參數：
access_token：指訪問令牌，必選，這里填第⑦步獲取的access_token
token_type：指令牌類型，必選，大小寫不敏感，bearer類型 / mac類型
expires_in：指過期時間，單位秒，當其他地方已設置過期時間，此處可省略該參數
refresh_token：指更新令牌，可選，用即將過期token換取新token
scope：指許可權范圍，可選，第④步中若已申請過某許可權，此處可省略該參數
我們在上面的第八步中會有refresh_token的參數，這個在實際操作中也比較常見
有時候我們在自己的項目中，將登陸和授權設計成類似OAuth2的過程，不過去掉Authorization code。登陸成功返回access_token，然後客戶端再請求時，帶上access_token。
我們常常會說到TCP/IP，那到底是什麼呢。這就需要講到網路分層模型。TCP在傳輸層，IP在網路層。那為什麼需要分層？因為網路不穩定，導致需要重傳的問題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會進行分塊。TCP還有兩個重要的內容就是三次握手，四次分手。
HTTPS 協議是由 HTTP 加上TLS/SSL協議構建的可進行加密傳輸、身份認證的網路協議，主要通過數字證書、加密演算法、非對稱密鑰等技術完成互聯網數據傳輸加密，實現互聯網傳輸安全保護
1.客戶端通過發送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密演算法及密鑰長度），客戶端隨機數，hash演算法。
2.伺服器可進行SSL通信時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本以及加密組件，服務端隨機數。伺服器的加密組件內容是從接收到客戶端加密組件內篩選出來的。
3.之後伺服器發送Certificate報文。報文中包含公開密鑰證書。一般實際有三層證書嵌套，其實像下面圖二直接用根證書機構簽名也是可以的，但是一般根證書機構比較忙，需要類似中介的證書機構來幫助。
4.最後伺服器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。
5.SSL第一次握手結束後，客戶端以Client Key Exchange報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。
6.接著客戶端繼續發送Change Cipher Spec報文。該報文會提示伺服器，在此報文之後的通信會採用Pre-master secret密鑰加密。
7.客戶端發送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密報文作為判定標准。
8.伺服器同樣發送Change Cipher Spec報文。
9.伺服器同樣發送Finished報文。
10.伺服器和客戶端的Finished報文交換完畢之後，SSL連接就算建立完成。當然，通信會受到SSL的保護。從此處開始進行應用層協議的通信，即發送HTTP響應。
11.應用層協議通信，即發送HTTP響應。
12.最後由客戶端斷開連接。斷開連接時，發送close_notify報文。這步之後再發送TCP FIN報文來關閉與TCP的通信。
利用客戶端隨機數，服務端隨機數，per-master secret隨機數生成master secret，再生成客戶端加密密鑰，服務端加密密鑰，客戶端MAC secert，服務端MAC secert。MAC secert用於做報文摘要，這樣能夠查知報文是否遭到篡改，從而保護報文的完整性。
Android網路請求知識（一）HTTP基礎概念
Android網路請求知識（二）對稱和非對稱加密、數字簽名，Hash，Base64編碼
Android網路請求知識（三）授權，TCP/IP，HTTPS建立過程
Ⅲ android https和http有什麼區別
HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議
它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。
它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通信。）SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。
HTTPS和HTTP的區別：
https協議需要到ca申請證書，一般免費證書很少，需要交費。
http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議
http和https使用的是完全不同的連接方式用的埠也不一樣,前者是80,後者是443。
http的連接很簡單,是無狀態的
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議 要比http協議安全
HTTPS解決的問題：
1 . 信任主機的問題. 採用https 的server 必須從CA 申請一個用於證明伺服器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度才信任次主機. 所以目前所有的銀行系統網站,關鍵部分應用都是https 的. 客戶通過信任該證書,從而信任了該主機. 其實這樣做效率很低,但是銀行更側重安全. 這一點對我們沒有任何意義,我們的server ,採用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的數據的泄密和被竄改
1. 一般意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣.
b) 服務端和客戶端之間的所有通訊,都是加密的.
i. 具體講,是客戶端產生一個對稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的握手過程.
ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有密鑰. 當然竄改也就沒有什麼意義了.
2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.
a) 這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.
b) 目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.
HTTPS 一定是繁瑣的.
a) 本來簡單的http協議,一個get一個response. 由於https 要還密鑰和確認加密演算法的需要.單握手就需要6/7 個往返.
i. 任何應用中,過多的round trip 肯定影響性能.
b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密.
i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 晶元. 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求.
ii. 加密後數據量的影響. 所以，才會出現那麼多的安全認證提示
Ⅳ android https安全嗎
HTTPS (Secure Hypertext Transfer Protocol)安全超文本傳輸協議，是一個安全通信通道，它基於HTTP開發用於在客戶計算機和伺服器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版,是使用TLS/SSL加密的HTTP協議。android相關應用使用https會比http更加安全。網頁鏈接
Ⅳ Android中怎麼使用Https協議
android中使用http協議通信辦法還是有好幾種的，第一種是用socket自定義協議頭，功能靈活但較為復雜。最簡單的我覺得還是下面這種：HttpGet mHttpGet = new HttpGet(要訪問的地址String);HttpResponse mHttpResponse;mHttpResponse = new DefaultHttpClient().execute(mHttpGet); if (mHttpResponse.getStatusLine().getStatusCode() == 200) { String result= EntityUtils .toString(mHttpResponse.getEntity()); }當然，過程中要注意的地方還有挺多的..字元集，轉義之類的，訪問參數之類的，要深入去探究了。
Ⅵ HTTP與HTTPS區別及Android證書配置
HTTP協議傳輸的數據都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私信息非常不安全，為了保證這些隱私數據能加密傳輸，於是網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，後者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。
客戶端會驗證公鑰是否有效。如果沒有問題，就回生成一個隨機值，並對其進行加密，（這個隨機值其實就是對稱加密的私鑰）
服務端用私鑰解密後，得到了客戶端傳過來的隨機值（私鑰），然後把內容進行對稱加密。
首先用的是非對稱加密。把公鑰給客戶端，私鑰在服務端。客戶端用公鑰驗證通過後，會生成私鑰進行對稱加密。然後傳給後台。
為什麼這么做呢。
圖中的方法是驗證服務端購買的證書。如果是信任所有證書的。這三個重寫的方法不需要做操作。直接用默認即可。
詳細解析 HTTP 與 HTTPS 的區別
非對稱加密和對稱加密的區別
如有錯誤。還望指正，非常感謝。
Ⅶ Android之網路—第二篇（Https原理）
Android之網路—第一篇（Http原理）
Android之網路—第二篇（Https原理）
Android之網路—第三篇（解讀OkHttp）
Android之網路—第四篇（解讀Retrofit）
說的通俗一點就是身披安全衣的Http，本質還是http，只是在http外層嵌套了一個SSL/TLS的安全層，該層做了一些數據的加解密處理。
在講解Https原理之前，先做點准備工作，因為會涉及到SSL/TLS連接建立、SSL/TLS加解密方面的知識。所以會整體從網路架構和比較重要的知識點回顧下網路知識。
在講解什麼是SSL/TLS之前，回顧下TCP/IP協議的分層概念。通常一個網路的傳輸中間會經過很多的傳輸節點，才最終達到伺服器。期間過程會包含數據的拆分和拼裝、IP的解析、數據的傳輸等等操作，但是網路傳輸是很不穩定的，如果這次網路請求在中間的某一節點失敗了，難道還要重新再發送一遍么？答案是不應該這么做。
為了網路傳輸的統一規范，就設計了這么一套網路通信的規范，每一層都專注做一件事情，即使當前失敗了，也在這層做處理就可以了，盡量避免重發。
簡單解釋下，每層的含義：
通過上圖發現，數據是由上往下傳遞後，再由下往回傳遞。這是怎麼回事呢？總結就是：在 TCP / IP協議中數據先由上往下將數據裝包，然後由下往上拆包。在裝包的時候，每一層都會增加一些信息用於傳輸，這部分信息就叫報頭，當上層的數據到達本層的時候，會將數據加上本層的報頭打包在一起，繼續往下傳遞。在拆包的時候，每一層將本層需要的報頭讀取後，就將剩下的數據往上傳。
簡要分析下傳輸過程：
這里簡單總結下傳輸層的兩種連接方式：TCP和UDP
三次握手：客戶端主動打開連接，伺服器被動打開連接。
四次揮手：客戶端主動關閉，伺服器被動關閉
說個概念性的東西就是，現代密碼學分為對稱加密和非對稱加密，跟傳統密碼學不一樣的地方就是，除了可以加密文字內容外，還可以用於各種二進制數據的加解密。
通信雙方使用同一個密鑰，使用加密演算法配合上密鑰來加密，解密時使用解密演算法（加密過程的完全逆運算）配合密鑰來進行解密。常用的經典演算法：DES（56 位密鑰，密鑰太短而逐漸被棄用）、AES（128 位、192 位、256 位密鑰，現在最流行）。
通信雙方使用公鑰和加密演算法對數據進行加密得到密文；使用私鑰和加密演算法對數據進行解密得到原數據。常用的經典演算法：RSA（可用於加密和簽名）、DSA（僅用於簽名，但速度更快）。
這個有什麼用？其實這個就是後面Https加解密的原理。原理這么簡單么？是的，就這么簡單。但是要理解還得慢慢往下看。
A用自己的私鑰通過加密演算法得到的數據密文數據，這個數據就可以稱為簽過名。接收方B再用A提供的公鑰通過加密演算法就可以還原數據，從而就驗證了數據的真實性。因為只有A一個人擁有自己的私鑰。
到這里咱們就可以聊聊剛才中間人偽造數據是如何處理了。通過對稱加密可以防止中間人偷窺數據，通過數字簽名可以防止中間人篡改偽造數據。
但是完整版的簽名信息需要將簽名數據取Hash值，減少數據大小
好了，看完理解了上面的知識點，到這里我們可以慢慢分析Https是如何工作的了。
先來總結一句話：Https的本質就是在客戶端和服務端之間用非對稱加密協商出一套對稱密鑰，每次發送信息之前將內容加密，接收後解密，達到內容的加密傳輸。解釋下，就是整個數據的傳輸過程是用對稱加密的方式來傳輸的，只是密鑰的生成是由客戶端和服務端 在創建連接的時候 通過 非對稱加密的方式 協商生成的。
那這里就會有一系列的問題啦：
Q：為什麼不直接用非對稱加密的方式直接加密呢？
A：因為非對稱加密的計算過程是復雜的數學運算，太復雜了，很慢。
Q：哦哦，那既然使用對稱加密的話，這個對稱密鑰是怎麼來的？
A：在實際的場景中，服務端會對接N個客戶端，這個對稱密鑰如果都使用同一個密鑰來通信的話，肯定是不合理的，只要破解了其中一個，其他所有的都會被破解。所以整體的網路架構應該是使用不同加密方式用不同的密鑰來進行數據傳輸的。模型如下圖
Q：但是在網路場景中，對稱加密的密鑰是不能直接在網路上傳輸的。服務端和客戶端是如何都知道的呢？
A：這個是服務端和客戶端一起協商根據只有它倆知道的規則分別生成，就不用通過網路傳輸啦。
Q：如果保證它倆協商出來的密鑰不被破解呢？
A：當然是使用非對稱加密的方式啦。通過之前的加密知識，可以知道非對稱加密是目前來說是絕對安全的。而且一個私鑰可以有多個公鑰，正好滿足一個服務端對N個客戶端的場景。模型如下圖：
實際在協商通訊的過程中，這個公鑰是服務端給客戶端發送的。而且需要注意 這個公鑰是用來協商生成對稱密鑰的，不是用來做數據的加密傳輸的 。
Q：哦哦，原來是這樣，但是這樣子還是有問題啊，客戶端與服務端在協商生成密鑰的過程中為了保證數據被偷窺和被篡改的風險，一般會要求有兩套公鑰和私鑰分別做加解密和簽名驗證處理的，上面的模型只有一套公鑰和私鑰，沒法規避數據被被篡改的風險呀。
A：能提出這個問題，說明之前的學習理解得很好。從上面的模型，可以保證在協商的過程中客戶端A/B/C/D分別向伺服器傳輸的數據是安全。但是伺服器發送給客戶端的數據是如何保證的呢？換句話說就是，客戶端如何驗證數據是服務端發送過來的，而不是被中間假冒掉包的數據。這不就是之前講的數字簽名的內容么？而實際情況中，就是通過CA證書來處理這個問題的。
Q：那這個CA證書是怎麼驗證的呢？
A：請看下面的CA證書的分析。
回歸之前的分析，我們的問題點卡在了「伺服器發送給客戶端的數據是如何保證的呢」。對吧。實際上在協商通信的過程中，服務端會先給客戶端下發證書信息，這個證書信息裡面會包含非對稱加密的公鑰。但是考慮一個問題，如何保證這個公鑰就是客戶端要的公鑰呢？或者說怎麼保證這個證書就是真實的證書，而不是被篡改假冒的證書。只有驗證了這一步，客戶端才完全信賴服務端，才給伺服器發消息，也才接受伺服器的消息。這時候就只需要一套公鑰和私鑰客戶端和服務端就可以通信了。
Q：那客戶端如何驗證服務端下發的證書和公鑰是正確的呢？
A：先換個概念，將證書裡面的公鑰假設為一串數據。要驗證這個數據，只需要提供這串數據的簽名以及加密這段數據的簽名的私鑰對應的公鑰就可以了，如下圖框框所示。
Q：那這樣子又有另外的一個問題產生了怎麼去驗證 這段數據的簽名的私鑰對應的公鑰 了？
A：同樣的，也是需要提供對應的簽名和對應簽名的私鑰對應的公鑰。
Q：但是這樣子下去就會變成一個循環了，怎麼辦？
其實在這里還會有一個場景問題：第三方簽發機構不可能只給你一家公司製作證書，它也可能會給中間人這樣有壞心思的公司發放證書。這樣的，中間人就有機會對你的證書進行調包，客戶端在這種情況下是無法分辨出是接收的是你的證書，還是中間人的。因為不論中間人，還是你的證書，都能使用第三方簽發機構的公鑰進行解密。
A：是的，為處理這個問題，就需要講一個根證書的東西。先舉個例子：假設你是HR，你手上拿到候選人的學歷證書，證書上寫了持證人，頒發機構，頒發時間等等，同時證書上，還寫有一個最重要的：證書編號！我們怎麼鑒別這張證書是的真偽呢？只要拿著這個證書編號上相關機構去查，如果證書上的持證人與現實的這個候選人一致，同時證書編號也能對應上，那麼就說明這個證書是真實的。同樣的，Https請求驗證時，會用到手機操作系統內置的根證書去驗證這個證書的真偽的。
到這里就簡要分析完了證書的驗證過程。證書會包含很多信息，包括伺服器公鑰，伺服器名字，伺服器地區等等信息。這個是沒法篡改的。其中對Https連接來說最重要的就是伺服器的公鑰。
之前學習完TCP的連接過程，現在我們開始來嘮嘮Https連接。什麼是Https連接呢？准確來說就是SSL/TLS加解密層的連接。
大致的建立流程：
詳細的建立流程：
客戶端MAC secret，服務端MAC secret的主要作用：用來認證這個消息是正確的，完整的，解決對稱加密方式沒法驗證消息的缺點。
至此完整的Https在TLS層連接過程分析完畢。
如果覺得我的文章對你有幫助，請隨意贊賞。您的支持將鼓勵我繼續創作！
Ⅷ Android面試筆記——HTTP/HTTPS
HTTP和HTTPS是面試常問的問題，內容比較多而且復雜，HTTPS裡面的細節很多，本文只是把主要的東西寫出來，想要弄懂HTTPS還是要多看幾篇博文，自己動手走一遍把各個攻擊的case搞明白。
HTTP 是超⽂本傳輸協議，也就是HyperText Transfer Protocol。
Host 欄位 ：客戶端發送請求時，⽤來指定伺服器的域名。 Host: www..com
Content-Length 欄位 ：伺服器在返回數據時，會有 Content-Length 欄位，表明本次回應的數據長度。 Content-Length: 1000
Connection 欄位 ：Connection 欄位最常用於客戶端要求伺服器使⽤ TCP 持久連接，以便其他請求復⽤。 HTTP/1.1 版本的默認連接都是持久連接，但為了兼容⽼版本的 HTTP，需要指定 Connection ⾸部欄位的值為Keep-Alive 。
Content-Type 欄位 ：Content-Type 欄位⽤於伺服器回應時，告訴客戶端，本次數據是什麼格式 。 Content-Type: text/html; charset=utf-8
Content-Encoding 欄位 ：Content-Encoding 欄位說明數據的壓縮⽅法。表示伺服器返回的數據使用了什麼壓縮格式 。客戶端在請求時，⽤ Accept-Encoding 欄位說明自己可以接受哪些壓縮⽅法。 Accept-Encoding: gzip, deflate
下圖為訪問網路的返回欄位
HTTP/2 協議是基於 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
這都是基於 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP 。
UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的⼀個丟包全部重傳問題。
UDP 是不可靠傳輸的，但基於 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。
HTTPS 采⽤的是 對稱加密和⾮對稱加密結合 的「混合加密」⽅式：
采⽤「混合加密」的⽅式的原因：
摘要演算法⽤來實現 完整性 ，能夠為數據⽣成獨⼀⽆⼆的「指紋」，⽤於校驗數據的完整性，解決了篡改的⻛險。
客戶端在發送明⽂之前會通過摘要演算法算出明文的「指紋」，發送的時候把「指紋 + 明文」⼀同加密成密文後，發送給伺服器，伺服器解密後，用相同的摘要演算法算出發送過來的明文，通過⽐較客戶端攜帶的「指紋」和當前算出的「指紋」做⽐較，若「指紋」相同，說明數據是完整的。
客戶端先向伺服器端索要公鑰，然後⽤公鑰加密信息，伺服器收到密文後，⽤⾃⼰的私鑰解密。這就存在些問題，如何保證公鑰不被篡改和信任度？
所以這⾥就需要藉助第三⽅權威機構 CA （數字證書認證機構），將伺服器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。
通過數字證書的⽅式保證伺服器公鑰的身份，解決冒充的⻛險 。
證書簽名和驗證過程 ：
兩種情況 ：
Ⅸ android 怎麼信任https
因為最近公司的open api伺服器訪問協議換成了https，所以 android 在使用okhttp 走https 訪問的時候遇到了證書信任的問題，
在這里把我走過的彎路記下來，一如既往的話不多說，上碼：
OkHttpClient sClient = new OkHttpClient();
// 設置超時時間
sClient.setConnectTimeout(8000, TimeUnit.MILLISECONDS);
sClient.setReadTimeout(8000, TimeUnit.MILLISECONDS);
// 注冊攔截器
sClient.interceptors().add(new BaseInterceptor(context));
第一種方式：
sClient.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
運行結果：
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:410)
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.squareup.okhttp.Connection.connectTls(Connection.java:235)
11-26 11:17:57.264 17106-17268/com.dooioo.addressbook W/System.err: at com.squareup.okhttp.Connection.connectSocket(Connection.java:199)
11-26 11:17:57.264 17106-1726