首先，HTTPS並不是這種加密技術的正式名稱，HTTPS代表的是“在TLS/SSL上實現的HTTP協議”，因此實現加密的其實是位於HTTP下面的TLS/SSL層。
我們看看TLS/SSL所實現的幾個主要機制：
1. 證書：通過第三方權威證書頒發機構（如VeriSign）驗證和擔保網站的身份，防止他人偽造網站身份與不知情的用戶建立加密連接。
2. 密鑰交換：通過公鑰（非對稱）加密在網站服務器和用戶之間協商生成壹個***同的會話密鑰。
3. 會話加密：通過機制(2)協商的會話密鑰，用對稱加密算法對會話的內容進行加密。
4. 消息校驗：通過消息校驗算法來防止加密信息在傳輸過程中被篡改。
通過上述機制，用戶與網站之間的傳輸內容受到了保護，因此能夠獲得很高的安全性。不過，任何密碼學手段都不是絕對安全的，上面幾個機制中其實都存在可能的風險：
1. 證書：如果有人偽造證書，瀏覽器會發出警告，提示用戶該網站的證書可能是偽造的，應該停止訪問，但如果妳無視瀏覽器的警告，妳的會話信息就有可能被偽造者竊取。此外，如果第三方證書頒發機構遭到攻擊，攻擊者竊取了已頒發的證書密鑰，就可以偽造相應的網站證書，完全騙過瀏覽器的安全機制，這樣的例子的確曾經發生過。
2. 密鑰交換：RSA，這是壹種最普遍使用的公鑰加密算法，壹般來說安全性很高。
3. 會話加密：AES-256(CBC Mode），這是壹種非常廣泛使用的加密算法，采用256位密鑰代表其安全性很高，如果采用128位密鑰（AES-128）則安全性就差壹些。
4. 消息校驗：SHA1，這是壹種散列算法，SHA1的安全性比MD5要好，但如果采用SHA256則安全性會更好壹些。
上面很抽象是不是，我們用“傳紙條”這個人人小時候都做過的事來形象的說明壹下。
HTTP
假設妳現在正坐在教室裏上課，現在妳非常想和走道旁的迷人的 TA 說壹些話，壹般這個時候妳會用“傳紙條”的方式來交流。而這個方式和 TCP/IP 協議基本的工作模式十分相像：
通過小動作引起對方註意；
對方以多種可能的方式（註視、肢體語言等）回應於妳；
妳確認對方感知到妳後，將紙條傳給對方；
對方閱讀紙條；
對方給予妳閱讀後的反應；
怎麽樣，這個流程是不是很熟悉？
如果妳要傳遞紙條的 TA 距離妳很遠怎麽辦？HTTP 協議就是指妳在紙條上寫明妳要傳給的 TA 是誰，或者 TA 的座位在哪，接著只需要途徑的同學拿到紙條後根據紙條上的指示依次將紙條傳過去就 OK 了。
這個時候問題來了：途徑的同學完全可以觀看並知道妳在紙條上寫了什麽。
這就是 HTTP 傳輸所面臨的問題之壹：中間人攻擊，指消息傳遞的過程中，處在傳遞路徑上的攻擊者可以嗅探或者竊聽傳輸數據的內容。
HTTPS
HTTPS 針對這個問題，采用了“加密”的方式來解決。最著名原始的加密方法就是對稱加密算法了，就是雙方約定壹個暗號，用什麽字母替換什麽字母之類的。現在壹般采用壹種叫 AES（高級加密算法）的對稱算法。
對稱加密算法既指加密和解密需要使用的密鑰 key 是壹樣的。
AES 在數學上保證了，只要妳使用的 key 足夠長，破解幾乎是不可能的（除非光子計算機造出來了）
我們先假設在沒有密鑰 key 的情況下，密文是無法被破解的，然後再回到這個教室。妳將用 AES 加密後的內容噌噌噌地寫在了紙條上，正要傳出去的時候妳突然想到，TA 沒有 key 怎麽解密內容呀，或者說，應該怎麽把 key 給TA？
如果把 key 也寫在紙條上，那麽中間人照樣可以破解竊聽紙條內容。也許在現實環境中妳有其他辦法可以把 key 通過某種安全的渠道送到 TA 的手裏，但是互聯網上的實現難度就比較大了，畢竟不管怎樣，數據都要經過那些路由。
於是聰明的人類發明了另壹種加密算法——非對稱加密算法。這種加密算法會生成兩個密鑰（key1 和 key2）。凡是 key1 加密的數據，key1 自身不能解密，需要 key2 才能解密；凡事 key2 加密的數據，key2 自身不能解密，只有 key1 才能解密。
目前這種算法有很多中，最常用的是 RSA。其基於的數學原理是：
兩個大素數的乘積很容易算，但是用這個乘積去算出是哪兩個素數相乘就很復雜了。好在以目前的技術，分解大數的素因確實比較困難，尤其是當這個大數足夠大的時候（通常使用2的10次方個二進制位那麽大），就算是超級計算機，解密也需要非常長的時間。
現在就把這種非對稱加密的方法應用在我們教室傳紙條的場景裏。
妳在寫紙條內容之前先用 RSA 技術生成了壹對密鑰 k1 和 k2。
妳把 k1 用明文傳了出去，路經也許有人會截取，但是沒有用，k1 加密的數據需要 k2 才可以破解，而 k2 在妳自己手中。
k1 傳到了目的人，目的人會去準備壹個接下來準備用於對稱加密（AES）的傳輸密鑰 key，然後用收到的 k1 把 key 加密，傳給妳。
妳用手上的 k2 解出 key 後，全教室只有妳和妳的目的人擁有這個對稱加密的 key，妳們倆就可以盡情聊天不怕竊聽啦~
這裏也許妳會有問題，為什麽不直接用非對稱加密來加密信息，而是加密 AES 的 key 呢？因為非對稱加密和解密的平均消耗時間比較長，為了節省時間提高效率，我們通常只是用它來交換密鑰，而非直接傳輸數據。
然而使用非對稱加密真的可以防範中間人攻擊嗎？雖然看上去很安全，但是實際上卻擋不住可惡的中間人攻擊。
假設妳是 A，妳的目的地是 B，現在要途徑壹個惡意同學M。中間人的惡意之處在於它會偽裝成妳的目標。
當妳要和 B 完成第壹次密鑰交換的時候，M 把紙條扣了下來，假裝自己是B並偽造了壹個 key，然後用妳發來的 k1 加密了 key 發還給妳。
妳以為妳和 B 完成了密鑰交換，實際上妳是和 M 完成了密鑰交換。
同事 M 和 B 完成壹次密鑰交換，讓 B 以為和 A 妳完成了密鑰交換。
現在整體的加密流程變成了A（加密鏈接1）->M(明文)->B(加密鏈接2)的情況了，這時候 M 依然可以知道A和B傳輸的全部消息。
這個時候就是體現 HTTPS 和傳紙條的區別了。在教室裏，妳是和壹位與妳身份幾乎對等的的對象來通信；而在訪問網站時，對方往往是壹個比較大（或者知名）的服務者，他們有充沛的資源，或許他們可以向妳證明他們的合法性。
此時我們需要引入壹個非常權威的第三方，壹個專門用來認證網站合法性的組織，可以叫做 CA（Certificate Authority）。各個網站服務商可以向 CA 申請證書，使得他們在建立安全連接時可以帶上 CA 的簽名。而 CA 得安全性是由操作系統或者瀏覽器來認證的。
妳的 Windows、Mac、Linux、Chrome、Safari 等會在安裝的時候帶上壹個他們認為安全的 CA 證書列表，只有和妳建立安全連接的網站帶有這些CA的簽名，操作系統和瀏覽器才會認為這個鏈接是安全的，否則就有可能遭到中間人攻擊。
壹旦某個 CA 頒發的證書被用於的非法途徑，那麽這個 CA 之前頒發過的所有證書都將被視為不安全的，這讓所有 CA 在頒發證書時都十分小心，所以 CA 證書在通常情況下是值得信任的。
正如聲網agora.io Web SDK考慮數據安全問題，限制了http訪問getUserMedia接口，只能通過https方式訪問。所以會出現用http在Chrome瀏覽器（47以上版本）中訪問Agora服務失敗，我該怎麽辦？
Agora Web解決方案基於WebRTC技術建立瀏覽器間的音視頻通信，在WebRTC協議中，瀏覽器通過getUserMedia接口獲取視頻(通過攝像頭)和音頻(通過麥克風)數據，Google Chrome是支持WebRTC的主流瀏覽器之壹，在v47及以上版本，考慮到數據安全問題，限制了http訪問getUserMedia接口，只能通過https方式訪問。除了chrome瀏覽器外，Opera瀏覽器在v34版本後也跟進了對http的限制，Firefox暫時沒有此更新。但是考慮到https是WebRTC協議推薦的安全訪問方式，建議客戶統壹通過https來訪問Agora Web服務，也能兼容各瀏覽器平臺。