❶ 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 （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。
通过数字证书的⽅式保证服务器公钥的身份，解决冒充的⻛险 。
证书签名和验证过程 ：
两种情况 ：