❶ HTTPS 抓包原理以及 android 端如何防止抓包
抓包的基本原理就是中間人攻擊 HTTPS 的握手過程 。Mac 上可使用 Charles 進行抓包。本質上就是兩段 HTTPS 連接，Client <--> Man-In-The-Middle 和 Man-In-The-Middle <--> Server。使用 Charles 進行抓包，需要 Client 端提前將 Charles 的根證書添加在 Client 的信任列表中。
回顧之前的 HTTPS 的握手過程 ，可以知道 SSL 的核心過程就是客戶端驗證證書鏈合法性——客戶端檢查證書鏈中是否有一個證書或者公鑰存在於客戶端的可信任列表中。
手機系統中內置了上百份不同的根證書。Certificate Pinning 的原理其實就是 app 中內置需要被信任的特定證書，app 在驗證伺服器傳過來的證書鏈時，使用這些特定證書來驗證的。
證書的主要作用是公鑰的載體，但在實踐中我們更多是去 pinning 公鑰， SubjectPublicKeyInfo(SPKI) 。這是因為很多伺服器會去定期旋轉證書，但是證書旋轉後，證書中的公鑰還是相同的公鑰。
如果私鑰泄露了，那麼伺服器端就不得不使用新的私鑰做出新的證書。客戶端為了預防這種情況，可以提前 pinning 這些新的證書。這樣，當伺服器替換新的證書時，客戶端 app 就可以不做任何改動。
從 SDK 24 開始，Android 支持通過 xml 來配置 certificate pinning，見 Network Security Configuration 。
其中 <pin> 節點接受 SubjectPublicKeyInfo 的 hash 值。
OkHttp 從 2.1 開始直接支持 Certificate Pinning 。
我在項目實踐中發現有的伺服器並不會在 ssl 握手階段 將完整的證書鏈傳輸過來——只會傳證書鏈中的根證書和葉子證書。如果安卓系統中使用 HttpUrlConnection 訪問伺服器，拋出如下類似異常：
但是瀏覽器對於這種缺失中間證書的伺服器卻能驗證通過，主要原因是瀏覽器訪問有完整證書鏈的網站時，如果發現證書鏈中有瀏覽器沒有內置的中間證書，那麼瀏覽器會將該證書緩存下來，這樣瀏覽器訪問其他沒有該中間證書的伺服器時，就可以使用這個緩存的中間證書來驗證證書鏈。
解決安卓上出現這個問題的方法是將這個中間證書通過 app 添加到信任證書列表中。我們需要將該中間證書加入到 App 運行時所用的 TrustManager 中。
使用 X509TrustManagerExtensions 可以將證書 pinning 到 app 中。 X509TrustManagerExtensions.checkServerTrusted() 允許開發者在系統對證書鏈驗證通過後，再次使用自己的方法驗證證書鏈。
使用方法如下：
❷ Android使用OkHttp請求自簽名的https網站
很多公司考慮到安全問題，項目中都採用https加密協議進行數據傳輸。但是一些公司又不想花一筆錢去CA申請證書，所以就採用自簽名的證書。
OkHttp默認是可以訪問通過CA認證的HTTPS鏈接，例如網路首頁也是https鏈接（ https://www..com/ ）。 但是如果是你們公司自簽名(即自己用keytool生成的證書，而不是採用通過CA認證的證書)的伺服器，OkHttp是無法訪問的，例如訪問12306網站（ https://kyfw.12306.cn/otn/ ） ，會報如下錯誤：
HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。握手過程的簡單描述如下：
握手過程中如果有任何錯誤，都會使加密連接斷開，從而阻止了隱私信息的傳輸。
以下我們使用12306網站為例
注意：別忘了加許可權和依賴okhttp庫
Demo地址： https://github.com/wildma/okhttps
參考博客： http://blog.csdn.Net/lmj623565791/article/details/48129405
❸ Android HTTPS、TLS版本支持相關解決方案(轉發)
原作: https://blog.csdn.net/s003603u/article/details/53907910
該文章內容只是轉發
在互聯網安全通信方式上，目前用的最多的就是https配合ssl和數字證書來保證傳輸和認證安全
因此，這三者的關系已經十分清楚了：https依賴一種實現方式，目前通用的是SSL，數字證書是支持這種安全通信的文件。另外有SSL衍生出TLS和WTLS，前者是IEFT將SSL標准化之後產生的（TLS1.0），與SSL差別很小，後者是用於無線環境下的TSL。
我們都知道HTTPS能夠加密信息，以免敏感信息被第三方獲取。所以很多銀行網站或電子郵箱等等安全級別較高的服務都會採用HTTPS協議。
HTTPS其實是由兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸的數據都是加密後的數據。具體是如何進行加密，解密，驗證的，且看下圖。
在4.x系統上通過HTTPS進行訪問產生如下異常：
Android4.x系統對TLS的支持存在版本差異，具體細節請看以下分析
首先我們查看一下Google關於 SSLEngine 的官方文檔說明
這里截取不同Android版本針對於TLS協議的默認配置圖如下：
從上圖可以得出如下結論：
有了以上關於Android SSLEngine相關知識的鋪墊，讓我們來測試一下這次目標案例的域名 fort.sports.baofeng.com
我們可以在 QUALYS SSL LABS 測試它對ssl支持的版本
這里截取SSL報告中對我們有用的一部分，如下圖
這就能解釋為什麼大部分4.xAndroid系統在進行HTTPS訪問時產生上述異常
我們再次查看SSL報告中的幾個關鍵結果：
從上圖可以看出，伺服器配置已經可以支持TLS1.0、TLS1.1、TLS1.2
從下圖可以看出，Handshake Simulation在Android 4.x系統也可以正常運作了
或許，你以為這樣就完美了，但是，你有沒有想到過這樣一種情況，當你所訪問的域名伺服器只支持TLS1.2，那Android4.x系統應該如何應對那
答案：想辦法讓Android4.x打開對TLS1.1、TLS1.2的支持
具體怎麼使用HTTPS，參考HttpsUtils：
自行實現SSLSocketFactory ，實現對TLSv1.1、TLSv1.2的支持
❹ android https自簽名證書和機構頒發證書的區別
1、https自簽名證書，免費，可自己生成，不受瀏覽器信任，沒有第三方監管，容易被仿造，存在安全風險。
2、證書頒發機構，權威、合法第三方證書頒發管理機構CA，需要准入許可證，頒發的SSL證書安全可行，提供長期的技術支持和售後服務，提供高額的保險。
3、關於證書頒發機構的介紹：http://www.wosign.com/CA/index.html
❺ android開發一般都使用什麼框架
目前框架使用的主要都是開源框架，都可以在github上找到：
1、volley，項目地址 https://github.com/smanikandan14/Volley-demo
2、android-async-http 項目地址：https://github.com/loopj/android-async-http
3、Afinal框架 項目地址：https://github.com/yangfuhai/afinal
4、xUtils框架 項目地址：https://github.com/wyouflf/xUtils
5、ThinkAndroid 項目地址：https://github.com/white-cat/ThinkAndroid
6、LoonAndroid 項目地址：https://github.com/gdpancheng/LoonAndroid
主要有以下模塊：
(1) 自動注入框架（只需要繼承框架內的application既可）
(2)
圖片載入框架（多重緩存，自動回收，最大限度保證內存的安全性）
(3) 網路請求模塊（繼承了基本上現在所有的http請求）
(4)
eventbus（集成一個開源的框架）
(5) 驗證框架（集成開源框架）
(6) json解析（支持解析成集合或者對象）
(7) 資料庫（不知道是哪位寫的 忘記了）
(8) 多線程斷點下載（自動判斷是否支持多線程，判斷是否是重定向）
(9)
自動更新模塊
(10) 一系列工具類
❻ 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 （數字證書認證機構），將伺服器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。
通過數字證書的⽅式保證伺服器公鑰的身份，解決冒充的⻛險 。
證書簽名和驗證過程 ：
兩種情況 ：