Charles 代理https请求

起因

需要调用一个https服务，获取token，再携带token调用对应系统发送报文。

在postman测试中，token可以正常获取，携带token并发送GET请求也可以正常发送请求返回数据。

但是在应用程序使用中发现GET请求始终无法调用成功，response状态码405。应用使用HttpURLConnection进行请求，后续删除部分不使用的代码后居然通了。

想深入理解https请求道理经历了什么改变，从不可用变为可用。

最初的想法使用wireshark监控本地网络数据，找到对应https解析后观察问题原因。

跟据TLS协议握手逻辑，在wireshark中使用正确证书、密钥等方式，将请求解析。

密钥获取方式：

可惜2种方式都没解决掉。

搜索原因，分析为tls1.2本地与服务端协商的套件为TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384，现在浏览器默认使用ECDHE的加密类型，作为套件使用，wireshare无法处理此类型https请求解析。

严重怀疑：1、直接通过Fiddler就可以解决我的需求。2、Wireshark还是没用明白。

主要就是以下步骤：

开启Charles的拦截后，发送postman直接拦截成功。

观察请求头数据，一切正常加密套件确认为TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。

开启Charles的拦截后，应用发送请求居然没显示拦截？？？

查了各种资料，对Charles针对性配置，仍然无效。再对windows系统进行配置仍然无效。判断应为程序问题，程序使用HttpURLConnection发送请求，发现需要设置Proxy对象，才能成功被Charles拦截。

观察后发现HttpURLConnection存在一个坑，虽然在编写过程设置了请求为GET方式，但是通过HttpURLConnection获取了输出流，虽然没有传入任何参数，请求方式在Charles中显示为POST。

Charles本质为代理或者说是中间人攻击，https请求必须流经Charles才能被拦截到，例如：A -> Charles -> 计算机网络底层 -> B。
HttpURLConnection发送请求的方式，网络层级应该比Charles更低。
但是postman为什么直接能被Charles拦截？是因为网络层级与Charles一致或更高么。
Wireshark的所处的网络层级一定比Charles低，那是否可以通过服务器证书解析请求、响应信息呢？

Fiddler确实也能解决这个问题，找到的资料是通过fiddler将https代理到另一个本地服务器，解析信息。
Wireshark应该可以解析浏览器发送的https请求，通过应用貌似需要程序特殊配置。
HttpURLConnection发送GET请求失败，居然因为调用getOutputStream()方法后请求类型变为了POST，哪怕是没有对输出流添加任何数据。