[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