最近在學習NodeJs架設網站，發現自己對於HTTP了解的太少，又不想啃厚重的Spec所以就買了這本半科普的書籍，內容蠻輕鬆有趣但該提的觀念都講得蠻清楚，剛好自己對於網站安全部份不太熟悉，所以打算整理一下自己的思緒分享出來，有興趣可以上淘寶購買。
HTTP本身在安全性上有許多的疑慮，主要有三點
1.明文傳送，這樣大家都知道我在講什麼
2.驗證身份，我沒辦法確定這個Response真的是我信任的Server回覆的(Server也無法信任Client)
3.內文竄改，發回來的訊息被改過我也不知道
有了問題自然有人會想辦法解決，所以就出現了新的HTTPS，HTTP over SSL
HTTPS在不影響HTTP運作下，在HTTP層與TCP層中加入了SSL通訊協定，藉此達到加密/驗證身份的動作：
1.加密方式：
加密主要有兩種，對稱加密與非對稱加密，對稱加密是指雙方共用一把鑰匙，優點是加解密相對簡單與快速，缺點就是如果別人知道鑰匙後就完了；
非對稱加密則是每人都有公開與私密金鑰，A要傳訊息給B就用B的公開金鑰加密，B拿到後用自己的私密金鑰解開就可以，其他人解不開，優缺點跟對稱加密相反。
SSL使用了兩種加密方式，後續會提到。
2.驗證身份：
我該如何驗證Server到底值不值得信任呢？目前的方式是透過第三方驗證單位(CA)發送證書，原理大概就是Server向驗證單位申請，審核通過後發送證書，之後在Handshake階段Client就可以拿證書去問驗證單位這個Server正不正確，通過的話就可以安心連結。
至於證書會不會被偽造呢？書中就提說難度很大XD 而且Client在與驗證單位確認證書時傳送是透過非對稱加密，所以不會被偷看到內容，而且驗證單位的公開金鑰是直接放在瀏覽器裡頭，比較不會有外漏的疑慮(雖然還是發生過.....)
目前主流都是Server端做驗證，而Client端只有在高安全需求下才會申請驗證，畢竟驗證要錢啊！
至於實作方面，在Handshake階段
1.Client發出請求時會帶SSL版本與加密方式，Server會回傳證書和公開金鑰，此時Client可以去CA做驗證
2.Client隨機產生亂數密碼，使用Server公開金鑰加密後丟給Server，Server用自己的私鑰解開(非對稱加密階段)
3.剛才上一步Client隨機產生的亂數密碼就成了對稱加密的秘鑰!之後就走對稱加密了
詳細的步驟可以參考此網站
SSL解決了兩個問題，至於如何確定內文沒有遭到竄改則需要靠訊息鑑定碼(MAC)，簡單來說就是把傳送的訊息透過某種加密方式加密，對方收到後解密比對內文，如果解密後內容與內容一致表示正確。
這大概就是HTTP封包傳輸時會遇到的危險，另外HTTP1.1這個協議已經用了超過十年，面臨現今大量的網路傳輸有點老態龍鍾，在2015年已經通過了HTTP2的修正，下一篇來研究HTTP2的內容。
沒有留言:
張貼留言