在HTTP協議中有可能存在信息竊聽或身份偽裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題。
1.HTTP的缺點
HTTP主要有這些不足，列舉如下：
通信使用名文，內容可能會被竊聽
不驗證通信方的身份，因此有可能遭遇偽裝
無法證明報文的完整性，所以有可能已遭篡改
這些問題不僅在HTTP上出現，其他未加密的協議也會存在這類問題。除此之外，HTTP本身有很多缺點。而且像某些特定的Web服務器和特定的Web瀏覽器在實際應用中存在的不足，另外，用Java和PHP等編程語言開發的Web應用也可能存在安全漏洞。為了有效防止這些弊端，有必要使用HTTPS。SSL提供認證和加密處理及摘要功能。僅靠HTTP確保完整性是非常困難的，因此通過和其他協議組合使用來實現這個目標。
2.HTTP+加密+認證+完整性保護=HTTPS
經常會在Web的登錄頁面和購物結算等使用HTTPS通信。使用HTTPS通信時，不再用http://，而是改用https://。另外，當瀏覽器訪問HTTPS通信有效的Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。
HTTPS并非時應用層的一種新協議。只是HTTP通信接口部分用SSL和TLS協議代替而已。通常，HTTP直接和TCP通信，當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。SSL是獨立于HTTP的協議，所以不光是HTTP協議，其他運行在應用層的SMTP和Telnet等協議均可配合SSL協議使用。可以說SSL是當今世界上應用最為廣泛的網絡安全技術。
相互交互密鑰的公開密鑰加密技術
在對SSL進行講解之前，我們先來了解一下加密方法。SSL采用了一種叫做公開密鑰加密的加密處理方式。近代的加密方式中加密算法是公開的，而加密卻是保密的。通過這種方法得以保持加密方法得安全性。加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來，任何人只要持有密鑰就能解密了，如果密鑰被攻擊者獲得，那加密也就失去了意義。
共享密鑰加密的困境
加密和解密用同一個密鑰的方式稱為共享密鑰加密，也被叫做對稱密鑰加密。以共享密鑰方式加密時必須將密鑰也發給對方。在互聯網上轉發密鑰時，如果通信被監聽，密鑰就可能落到攻擊者之手，也就失去了加密的意義。
使用兩把密鑰的公開密鑰加密
公開密鑰加密是一種非對稱的密鑰，一把叫做私有密鑰，一把叫做公開密鑰。使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方在收到被加密的信息后，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。
HTTPS采用混合加密機制
HTTPS采用共享密鑰和公開密鑰加密兩者并用的混合加密機制。若密鑰能夠實現安全交換，那么有可能考慮僅使用公開密鑰加密來通信。但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來建立通信。在交換密鑰環節使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。
證明公開密鑰正確性的證書
公開密鑰加密方式還是有一些問題，那就是無法證明公開密鑰本身就是貨真價實的公開密鑰，為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其他相關機關頒發的公開密鑰證書。
數字證書認證機構處于客戶端和服務器雙方都可信賴的第三方機構的立場上。首先，服務器的運營人員向數字認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份之后，會對已申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定到一起。服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通信，公鑰證書也叫做數字證書，接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端就可以明確兩件事：一，認證服務器的公開密鑰是真實有效的數字證書認證機構，二，服務器的公開密鑰是可信賴的。此處認證機關的公開密鑰如何安全的交給客戶端是個問題，因此，多數瀏覽器在開發商發布版本時，會事先植入常用認證機關的公開密鑰。
可證明組織真實性的EV SSL證書
證書的一個作用是用來證明作為通信一方的服務器是否規范，另外一個作用是確認對方服務器背后運營的企業是否真實存在，擁有該特性的證書就是EV SSL證書。
用以確認客戶端的客戶端證書
HTTPS中可以使用客戶端證書。以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍。例如，銀行的網上銀行就采用了客戶端證書。在登錄網銀時，不僅要求用戶確認輸入ID和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。
認證機構信譽第一
SSL機制中介入認證機構之所以可行，是建立在其信用絕對可靠的這一大前提下的，然后2011年發生在荷蘭的偽造證書事件從根本上撼動了SSL的可信度。因為偽造證書上有正規認證機構的數字簽名，所以瀏覽器會判定該證書是正當的。當偽造的證書被用作服務器偽裝時，用戶根本無法察覺，雖然存在將證書無效化的證書吊銷列表機制以及從客戶端刪除根證書頒發機構的對策，但距離生效期間還需要一段時間，在這段時間里有多少用戶蒙受損失就不得而知了。
由自認證機構頒發的證書稱為自簽名證書
即使使用自簽名證書，通過SSL加密之后，可能偶爾還會看見通信處在安全的狀態的提示，可那也是有問題的，因為就算加密通信，也不能排除正在和已經通過偽裝的假服務器保持通信。
3.HTTPS的安全通信機制
1.客戶端通過發送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密算法及密鑰長度等）。
2.服務器可進行SSL通信時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本和加密組件，服務器的加密組件內容是從客戶端加密組件列表內篩選出來的。
3.服務器發送Certificate報文。報文中包含公開密鑰證書。
4.最后服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束
5.客戶端以Client Key Exchange報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文采用公開密鑰加密。
6.接著客戶端繼續發送Change Cipher Spec報文。該報文會提示服務器，在此報文之后的通信會采用Pre-master secret密鑰加密。
7.客戶端發送Finished報文，該報文包含連接至今的全部報文的整體較驗值。此次握手是否成功，取決于服務器是否正確解密該報文作為判斷標準。
8.服務器同樣發送Change Cipher Spec報文
9.服務器同樣發送Finished報文
10.SSL連接建立完成，當然，通信會收到SSL的保護，從此處開始進入應用層協議的通信，即發送HTTP請求。
11.應用層協議通信，即發送HTTP響應。
12。客戶端斷開連接，斷開時發送close_notify報文，這步之后發送TCP FIN報文來關閉與TCP的通信。
在以上流程中，應用層發送數據時會附加一種叫做MAC的報文摘要，MAC能夠查知報文是否遭到篡改，從而報文報文的完整性。
SSL和TLS
HTTPS使用SSL和TLS這兩個協議。SSL技術最初是由瀏覽器開發商網景通信公司倡導的，開發過SSL3.0之前的版本。目前由IETF（Internet Engineering Task Force,Internet工程任務組）的手中。
IETF以SSL3.0為基準，后制定了TLS1.0、TLS1.1、TLS1.2。TSL是以SSL為原型開發的協議，有時會統一稱該協議為SSL。當前的主流版本是SSL3.0和TLS1.0。
