结论前置：
A 身份验证
证书， 服务器证书
B 密钥协商
RSA DHE / ECDHE PSK
C 加密通信
加密通信采用对称加密，使用B阶段协商出来的密钥。
B 阶段如果使用 RSA 协商，可以用服务器证书在协商过程中解密到 C过程中的密钥。从而解密通信内容。（此方式下，采用旁路方式就可以）。
B 阶段如果使用DHE/ECDHE协商，至少需要建立链接时的server魔数（也许还需要私钥即服务器证书）才能计算出加密密钥。简单来说协商过程也是一次一密。
于是，应该有两种情况可以解密https。
情况一：与server 通信，实时获得两个信息：1，session 信息。2，server魔数。 这种情况下，只需要旁路就可以了。
情况二：串行在网络中，做中间人。需要服务器证书做认证与签名，流程我暂时还没搞清楚。然后，需要与两端握手并协商密钥，然后做两端加解密，并内容转发。
引用一段有用的内容[1]
A WAF applies filter rules on traffic at an "application" level (e.g. it tries to detect SQL injection attempts). This requires that the WAF sees the traffic, i.e. whatever SSL which may have happened on the client side must stop at the WAF. But you usually want some SSL to protect the traffic between the client and the WAF (in fact, you usually want it more on that link than between the WAF and the server itself, since WAF and server are usually nearby to each other). There are two ways for a WAF to see SSL-protected traffic: The WAF has a copy of the private key used by the (SSL-aware) server, and thus can decrypt the data as it flows. (This can imply some restrictions on the cipher suites used by the server; namely, no DHE). The WAF itself runs a SSL server, and that is the one which the client sees. The WAF decrypt the data, runs its magic on it, and then forwards it to the server over a new connection which may or may not be SSL-protected. Which one you use depends on what your WAF instance can do and how you configured it.
论证过程
https是TCP与http之间加了一层隧道，该隧道使用 SSL/TLS协议，协议版本分为：SSL1.0, SSL2.0, SSL3.0, TLS1.0, TLS1.1, TLS1.2
目前主流使用TLS，很少部分还在用SSL3.0。 其他的没有。
版本是：server和client双方协商的。也就是说如果Server不古老，而且是用的是较新版本的主流浏览器chrome，firefox。那么协议版本一定是TLS1.2
不过我头两天看了IE 11，好像还在用TLS1.1, 更低版本的还在用1.0
以上内容只是相关信息，只要是TLS，对技术调研的结论，目前就不会产生影响。以下是技术细节：
整个https的链接过程分为以下三个部分：
1。 验证过程。
可分为单向验证或双向验证。
单向验证一般就是client使用CA机构签发的证书验证server的合法性（证书分两部分一个是由CA签名的serverPK，以及server自己留存的serverSK）。
除证书的验证功能外，serverPK与serverSK同时还是一对非对称密钥，serverPK是公钥，serverSK是私钥。
双向验证就是server同时会去验证client的合法性。原理相似，私钥由client秘密保存，公钥预先存放在server端。如登录网上银行时使用的USB
KEY。
验证过程对我们的调研结论同样不会产生影响。
2。 密钥协商过程。
可分为PFS和no
PFS两类。主要区别在于协商算法，一般主流的就是RSA，DH/ECDH，DHE/ECDHE，PSK等。
密钥协商的主要目的就是为了生成一次一密的密钥 sessionKEY。
3。 加密通信过程。
加密通信过程为对称加密，密钥为sessionKEY。
所以，只要拿到sessionKEY，我们就能解码整个应用层数据流。
那么，如何拿到sessionKEY呢？
情况A：过程2中采用noPFS协商， 一般为RSA算法。
sessionKEY由client随机生成，使用serverPK加密后传给server，server使用serverSK解密便获得sessionKEY，至此完成协商。
情况B：过程2中采用PFS协商，一般为DHE或ECDHE算法。
实际上是采用段周期的Diffie-Hellman算法完成协商，并使用RSA等非对称算法帮助做两端验证。
通俗易懂但并不准确的说就是 client生成一对密钥 sessionKEY-c-pk
sessionKEY-c-sk。server生成一对密钥 sessionKEY-s-pk sessionKEY-s-sk。
彼此将公钥通信之后，彼此都可以计算出一个相同的sessionKEY。
作为第三方，获得sessionKEY-c-sk
或sessionKEY-s-sk中的任何一个都可以将sessionKEY解密。但这两个密钥都是一次一密的。
换句话说，即使有了serverSK，在这种情况下，也无法做到解密。
那么，是否PFS是什么决定的呢？
是由http server 与browser
自协商的。而且PFS算法的协商优先级更高，即只要双方支持，自然就是PFS的了。目前我见到的浏览器都支持，除了IE。
针对 PFS 的https链接，如果想看通信内容，只有一种办法，就是作中间人。
做中间人，需要两块内容：
1。拿到serverSK，通过阶段1中的身份验证。
2。与client/server两端做协商，并建立两条完整的https链接，做双向转发。每一个包都要做加解密。
什么是PFS：
是https的一个特性，其目的是为了防止server私钥泄漏而带来的数据安全问题。openssl heartbleed之后被及其重视。
完全正向保密 PFS（perfect forward secrecy）
https://en.wikipedia.org/wiki/Forward_secrecy
相关参考资料：
概念：
http://www.guokr.com/post/114121/
http://www.guokr.com/post/116169/
http://www.guokr.com/post/148613/
https://en.wikipedia.org/wiki/HTTPS
双向认证，单项认证：
http://www.jianshu.com/p/0a7b028e2465
http://edison0663.iteye.com/blog/996526
浏览器安全控件：
最主要的功能就是防止客户端操作系统木马程序截取用户关键信息的输入（银行卡帐号/密码）。
http://wiki.mbalib.com/wiki/%E5%AE%89%E5%85%A8%E6%8E%A7%E4%BB%B6
完全正向保密 PFS（perfect forward secrecy）
http://baike.baidu.com/item/%E5%AE%8C%E5%85%A8%E6%AD%A3%E5%90%91%E4%BF%9D%E5%AF%86
https://en.wikipedia.org/wiki/Forward_secrecy
https://www.sslchina.com/deploying-forward-secrecy/
https://zh.wikipedia.org/wiki/%E5%89%8D%E5%90%91%E5%AE%89%E5%85%A8%E6%80%A7
PFS 密钥协商：
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B
** https://program-think.blogspot.com/2016/09/https-ssl-tls-3.html
TLS:
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
其他：
https://segmentfault.com/a/1190000004985253
http://www.admin5.com/special/https/
**** [1] https://security.stackexchange.com/questions/44563/is-ssl-required-for-sites-hosted-behind-waf
免费证书：
https://letsencrypt.org/
RFC：
1.2： https://tools.ietf.org/html/rfc5246
1.0： http://www.rfc-editor.org/rfc/rfc2246.txt
题外内容：TOR / IPsec
https://en.wikipedia.org/wiki/Tor_(anonymity_network)
IPsec： https://zh.wikipedia.org/wiki/IPsec
STARTTLS：
是一种 opportunisitic 加密协议，就是双方协商是否使用slt加密，如果不成功则使用明文传输，(-_-#)
那么是不是client设置了使用SSL/TLS之后，就一定安全了呢？ 还需要了解一下SMTP路由。
https://en.wikipedia.org/wiki/Opportunistic_encryption
https://en.wikipedia.org/wiki/Opportunistic_TLS
http://www.freebuf.com/articles/database/83660.html
Implementation:
pfSense: 开源的免费防火墙/路由器
https://turbofuture.com/computers/Introduction-to-pfSense-An-Open-Source-Firewall-and-Router-Platform
https://www.pfsense.org/download/?section=downloads
用wireshark或snort解析：
http://bammv.github.io/sguil/index.html
http://resources.infosecinstitute.com/ssl-decryption/
https://github.com/plashchynski/viewssld
https://wiki.wireshark.org/SSL
HTTPS测试网站，非常专业：
https://www.ssllabs.com/ssltest/
一个实验：
https://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/ （我down下来了，如果失效了，可以找我要。）（如果我没有把它弄丢的话 -^- ）
证书签名链（ssl certificate chains）
https://nginx.org/en/docs/http/configuring_https_servers.html#chains
TLS session tickets：
回话恢复在某种程度上，破坏了正向加密。主要用来提高握手效率，与减少用于会话保持的开销。带来安全隐患的同时，也为还原https会话带来了可能。
但是https server们终究会将其完善，从而也不会是DPI的真正手段。
https://linuxstory.org/tls-session-resumption/
https://imququ.com/post/optimize-tls-handshake.html
https://imququ.com/post/optimize-tls-handshake.html
参考 Nginx的ssl_session_tickets与ssl_session_ticket_key 选项。
参考阅读：
https://segmentfault.com/a/1190000008656644
TODO:
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security