[skill][https][ssl/tls] HTTPS相关知识汇总

结论前置：

　　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