（1）對稱加密
客戶端和服務器公用一個密匙用來對消息加解密，這種方式稱為對稱加密。客戶端和服務器約定好一個加密的密匙。客戶端在發消息前用該密匙對消息加密，發送給服務器后，服務器再用該密匙進行解密拿到消息。
（2）非對稱加密
采用非對稱加密時，客戶端和服務端均擁有一個公鑰和私鑰，公鑰加密的內容只有對應的私鑰能解密。私鑰自己留着，公鑰發給對方。這樣在發送消息前，先用對方的公鑰對消息進行加密，收到后再用自己的私鑰進行解密。這樣攻擊者只拿到傳輸過程中的公鑰也無法破解傳輸的內容。盡管非對稱加密解決了由於密鑰被獲取而導致傳輸內容泄露的問題，但中間人仍然可以用篡改公鑰的方式來獲取或篡改傳輸內容，而且非對稱加密的性能比對稱加密的性能差了不少。
（3）第三方認證
上面這種方法的弱點在於，客戶端不知道公鑰是由服務端返回，還是中間人返回的，因此我們再引入一個第三方認證的環節：即第三方使用私鑰加密我們自己的公鑰，瀏覽器已經內置一些權威第三方認證機構的公鑰，瀏覽器會使用第三方的公鑰來解開第三方私鑰加密過的我們自己的公鑰，從而獲取公鑰，如果能成功解密，就說明獲取到的自己的公鑰是正確的。但第三方認證也未能完全解決問題，第三方認證是面向所有人的，中間人也能申請證書，如果中間人使用自己的證書掉包原證書，客戶端還是無法確認公鑰的真偽。
（4）數字簽名
為了讓客戶端能夠驗證公鑰的來源，我們給公鑰加上一個數字簽名，這個數字簽名是由企業、網站等各種信息和公鑰經過單向hash而來，一旦構成數字簽名的信息發生變化，hash值就會改變，這就構成了公鑰來源的唯一標識。
具體來說，服務端本地生成一對密鑰，然后拿着公鑰以及企業、網站等各種信息到CA(第三方認證中心)去申請數字證書，CA會通過一種單向hash算法(比如MD5)，生成一串摘要，這串摘要就是這堆信息的唯一標識，然后CA還會使用自己的私鑰對摘要進行加密，連同我們自己服務器的公鑰一同發送給我我們。瀏覽器拿到數字簽名后，會使用瀏覽器本地內置的CA公鑰解開數字證書並驗證，從而拿到正確的公鑰。由於非對稱加密性能低下，拿到公鑰以后，客戶端會隨機生成一個對稱密鑰，使用這個公鑰加密並發送給服務端，服務端用自己的私鑰解開對稱密鑰，此后的加密連接就通過這個對稱密鑰進行對稱加密。
所以，總的來說HTTPS在驗證階段使用非對稱加密+第三方認證+數字簽名獲取正確的公鑰，獲取到正確的公鑰后以對稱加密的方式通信