當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

http_认证机制https加密TLSSSL密钥对(公钥私钥)

發布時間：2024/3/13 编程问答 35 豆豆

生活随笔收集整理的這篇文章主要介紹了 http_认证机制https加密TLSSSL密钥对(公钥私钥) 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

文章目錄
- http_認證機制&https加密&TLS&SSL&密鑰對(公鑰&私鑰)
- - references
  - - 更多詳情(MDN::HTTP)
    - session&token:
  - 何為認證
  - HTTP 使用的認證方式
  - BASIC認證(不常用)
  - - BASIC認證的問題
  - DIGEST 認證(不常用)
  - - DIGEST的問題
  - HTTP 的缺點
  - http加密
  - - 內容的加密
    - 偽裝
  - 密鑰&公鑰&私鑰
  - - 共享密鑰加密vs 公共密鑰加密(對稱加密vs非對稱加密)
    - - HTTPS 采用混合加密機制
    - 公開密鑰(public key)本身的真實性問題
    - - 數字證書認證機構的業務流程。
      - SSL證書的原理
      - 使用兩把密鑰的公開密鑰加密
    - SSL證書
    - - PKI vs Web of trust
      - SSL證書特點
    - 其他SSL證書
    - - EV SSL 證書
      - 用以確認客戶端的客戶端證書
      - 自簽名證書
    - TLS&SSL協議
    - SSL技術的通用性
    - SSL 客戶端認證
    - - SSL 客戶端認證的認證步驟
    - 更多https&ssl
  - https
  - - HTTPS通信
    - https的改進目標
    - https的通信步驟
    - http和https對比

http_認證機制&https加密&TLS&SSL&密鑰對(公鑰&私鑰)

references

<<圖解http>>

更多詳情(MDN::HTTP)

HTTP | MDN (mozilla.org)
- HTTP authentication - HTTP | MDN (mozilla.org)
- Using HTTP cookies - HTTP | MDN (mozilla.org)
- Using HTTP cookies&secure - HTTP | MDN (mozilla.org)

session&token:

session&token link

何為認證

計算機本身無法判斷坐在顯示器前的使用者的身份。
- 進一步說，也無法確認網絡的那頭究竟有誰。
可見，為了弄清究竟是誰在訪問服務器，就得讓對方的客戶端自報家門。
- 可是，就算正在訪問服務器的對方聲稱自己是 user1，身份是否屬實這點卻也無從談起。
為確認 user1本人是否真的具有訪問系統的權限，就需要核對“登錄者本人才知道的信息”、“登錄者本人才會有的信息”。

核對的信息通常是指以下這些。

密碼：只有本人才會知道的字符串信息。
動態令牌：僅限本人持有的設備內顯示的一次性密碼。
數字證書：僅限本人（終端）持有的信息。
生物認證：指紋和虹膜等本人的生理信息。
IC 卡等：僅限本人持有的信息。

HTTP 使用的認證方式

HTTP/1.1 使用的認證方式:

BASIC 認證（基本認證）
DIGEST 認證（摘要認證）
SSL 客戶端認證(證書認證)
FormBase 認證（基于表單認證）

BASIC認證(不常用)

BASIC 認證（基本認證）是從 HTTP/1.0 就定義的認證方式。
即便是現在仍有一部分的網站會使
用這種認證方式。是 Web 服務器與通信客戶端之間進行的認證方式。

BASIC認證的問題

BASIC 認證雖然采用 Base64 編碼方式，但這不是加密處理。
不需要任何附加信息即可對其解碼。
換言之，由于明文解碼后就是用戶 ID和密碼，在 HTTP 等非加密通信的線路上進行 BASIC 認證的過程中如果被人竊聽，被盜的可能性極高。
另外，除此之外想再進行一次 BASIC 認證時，一般的瀏覽器卻無法實現認證注銷操作，這也是問題之一。
BASIC 認證使用上不夠便捷靈活，且達不到多數 Web 網站期望的安全性等級，因此它并不常用。

DIGEST 認證(不常用)

為彌補 BASIC 認證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認證。
DIGEST 認證同樣使用質詢 / 響應的方式（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。
所謂質詢響應方式是指，一開始一方會先發送認證要求給另一方，接著使用從另一方那接收到的質詢碼計算生成響應碼。最后將響應碼返回給對方進行認證的方式。

DIGEST的問題

DIGEST 認證提供了高于 BASIC 認證的安全等級，但是和HTTPS 的客戶端認證相比仍舊很弱。
DIGEST 認證提供防止密碼被竊聽的保護機制，但并不存在防止用戶偽裝的保護機制。
DIGEST 認證和 BASIC 認證一樣，使用上不那么便捷靈活，且仍達不到多數 Web 網站對高度安全等級的追求標準。
因此它的適用范圍也有所受限。

HTTP 的缺點

通信使用明文（不加密），內容可能會被竊聽
不驗證通信方的身份，因此有可能遭遇偽裝
無法證明報文的完整性，所以有可能已遭篡改

這些問題不僅在 HTTP 上出現，其他未加密的協議中也會存在這類問題。

http加密

內容的加密

還有一種將參與通信的內容本身加密的方式。
由于 HTTP 協議中沒有加密機制，那么就對 HTTP 協議傳輸的內容本身加密。
- 即把 HTTP 報文里所含的內容進行加密處理。
- 在這種情況下，客戶端需要對 HTTP 報文進行加密處理后再發送請求。
為了做到有效的內容加密，前提是要求客戶端和服務器同時具備加密和解密機制。
- 主要應用在 Web 服務中。
- 有一點必須引起注意，由于該方式不同于 SSL 或 TLS 將整個通信線路加密處理，所以內容仍有被篡改的風險

偽裝

不驗證通信方的身份就可能遭遇偽裝
HTTP 協議中的請求和響應不會對通信方進行確認。
也就是說存在“服務器是否就是發送請求中 URI 真正指定的主機，
返回的響應是否真的返回到實際提出請求的客戶端”等類似問題
無法判定請求是來自何方、出自誰手(服務器和客戶端都有可能是偽造的)。
- 即使是無意義的請求也會照單全收。無法阻止海量請求下的 DoS攻擊（Denial of Service，拒絕服務攻擊）。
- 無法確定請求發送至目標的 Web 服務器是否是按真實意圖返回響應的那臺服務器。有可能是已偽裝的 Web 服務器。
無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端。
無法確定正在通信的對方是否具備訪問權限。因為某些 Web 服務器上保存著重要的信息，只想發給特定用戶通信的權限。

密鑰&公鑰&私鑰

什么是公鑰和私鑰？ (aliyun.com)

公鑰（Public Key）與私鑰（Private Key）是通過加密算法得到的一個密鑰對（即一個公鑰和一個私鑰，也就是非對稱加密方式）。
公鑰可對會話進行加密、驗證數字簽名，只有使用對應的私鑰才能解密會話數據，從而保證數據傳輸的安全性。

公鑰是密鑰對外公開的部分，
私鑰則是密鑰的非公開的部分，由用戶自行保管。

通過加密算法得到的密鑰對可以保證在世界范圍內是唯一的。
使用密鑰對的時候，如果用**其中一個密鑰(公鑰或者私鑰)加密一段數據**，只能使用密鑰對中的另一個密鑰才能解密數據。
- 例如：用公鑰加密的數據必須用對應的私鑰才能解密；
- 如果用私鑰進行加密也必須使用對應的公鑰才能解密，否則將無法成功解密。

共享密鑰加密vs 公共密鑰加密(對稱加密vs非對稱加密)

區分共享密鑰和公共密鑰

加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common key crypto system），也被叫做對稱密鑰加密。
對稱加密不如公開密鑰(非對稱加密)安全,但是也不是一無是處,兩者組合使用,可以節約開銷

HTTPS 采用混合加密機制

知道了共享密鑰和公共密鑰的基本概念,再看它們的組合應用來節約開銷

HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。
若密鑰能夠實現安全交換，那么有可能會考慮僅使用公開密鑰加密來通信。
- 但是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。
所以應充分利用兩者各自的優勢，將多種方法組合起來用于通信。
- 在交換密鑰環節使用公開密鑰加密方式，之后的建立通信交換報文階段則使用共享密鑰加密方式。

公開密鑰(public key)本身的真實性問題

遺憾的是，公開密鑰加密方式還是存在一些問題的。
那就是無法證明公開密鑰本身就是貨真價實的公開密鑰。
- 比如，正準備和某臺服務器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務器發行的公開密鑰。
- 或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。
為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。
- 數字證書認證機構處于客戶端與服務器雙方都可信賴的第三方機構的立場上。

數字證書認證機構的業務流程。

關鍵:

機構對要公開的密鑰做數字簽名
客戶端要用機構公開的public key(可以是事先植入瀏覽器的key)驗證機構簽名

首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。
數字證書認證機構(CA)在判明提出申請者的身份之后，會
- 對已申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，
- 并將該公開密鑰放入公鑰證書后綁定在一起。
服務器會將這份由數字證書認證機構頒發的*公鑰證書*發送給客戶端，以進行公開密鑰加密方式通信。
- 公鑰證書也可叫做數字證書或直接稱為證書。
接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證
- 一旦驗證通過，客戶端便可明確兩件事：
  - 一，(明確認證機構):認證服務器的公開密鑰的是真實有效的數字證書認證機構。(數字證書不是被調包的,否則就不會通過前面的簽名驗證)
  - 二，服務器的公開密鑰是值得信賴的。此處認證機關的公開密鑰必須安全地轉交給客戶端。
使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發布版本時，會事先在內部植入常用認證機關的公開密鑰。

SSL證書的原理

SSL證書采用公鑰體制，即利用一對互相匹配的密鑰對進行數據加密和解密。
每個用戶自己設定一把特定的、僅為本人所知的私有密鑰（私鑰），并用它進行解密和簽名；
同時設定一把公共密鑰（公鑰）并由本人公開，為一組用戶所共享，用于加密和驗證簽名。

由于密鑰僅為本人所有，可以產生其他人無法生成的加密文件，也就是形成了數字簽名。

使用兩把密鑰的公開密鑰加密

公開密鑰加密方式很好地解決了共享密鑰加密的困難。

公開密鑰加密使用一對非對稱的密鑰。
一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。
顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。
使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。
利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。
- 要想根據密文和公開密鑰，恢復到信息原文是異常困難的，因為解密過程就是在對離散對數進行求值，這并非輕而易舉就能辦到。
- 退一步講，如果能對一個非常大的整數做到快速地因式分解，那么密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

SSL證書

雖然使用 HTTP 協議無法確定通信方，但如果使用 SSL 則可以。

SSL 不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用于確定對方。
- 證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。
- 另外，偽造證書從技術角度來說是異常困難的一件事。
所以只要能夠確認通信方（服務器或客戶端）持有的證書，即可判斷通信方的真實意圖。
In cryptography: [kr?p?tɑɡr?fi], a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key.[1]
- The certificate includes information about the key, information about the identity of its owner (called the subject身份主體), and the digital signature of an entity that has verified the certificate’s contents (called the issuer發行機構).
  - If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate’s subject.
  - In email encryption, code signing, and e-signature systems, a certificate’s subject is typically a person or organization.
  - However, in Transport Layer Security (TLS) a certificate’s subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices.
  - TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.(TLS有時候仍被稱呼為SSL)

PKI vs Web of trust

In a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA),[2] usually a company that charges customers to issue certificates for them.
By contrast, in a web of trust scheme, individuals sign each other’s keys directly, in a format that performs a similar function to a public key certificate.
- In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner. Its decentralized trust model is an alternative to the centralized trust model of a public key infrastructure (PKI), which relies exclusively on a certificate authority (or a hierarchy of such). As with computer networks, there are many independent webs of trust, and any user (through their public key certificate) can be a part of, and a link between, multiple webs.
  
  The web of trust concept was first put forth by PGP creator Phil Zimmermann in 1992 in the manual for PGP version 2.0:
  
  As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.
The most common format for public key certificates is defined by X.509.[3]
- Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as Public Key Infrastructure (X.509) as defined in RFC 5280

SSL證書特點

是一個經證書授權中心（CA）數字簽名的、包含公開密鑰以及公開密鑰擁有者信息的文件。
最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。
數字證書還有一個重要的特征就是只在特定的時間段內有效。

其他SSL證書

EV SSL 證書

可證明組織真實性的EV SSL證書

證書的一個作用是用來證明作為通信一方的服務器是否規范，另外一個作用是可確認對方服務器背后運營的企業是否真實存在。擁有該特性的證書就是 EV SSL 證書（Extended Validation SSL Certificate）。
EV SSL 證書是基于國際標準的認證指導方針頒發的證書。
其嚴格規定了對運營組織是否真實的確認方針，因此，通過認證的 Web 網站能夠獲得更高的認可度。
持有 EV SSL 證書的 Web 網站的瀏覽器地址欄處的背景色是綠色的，從視覺上就能一眼辨別出。
而且在地址欄的左側顯示了 SSL 證書中記錄的組織名稱以及頒發證書的認證機構的名稱。

用以確認客戶端的客戶端證書

HTTPS 中還可以使用客戶端證書。以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用跟服務器證書如出一轍。
但客戶端證書仍存在幾處問題點。
- 其中的一個問題點是證書的獲取及發布。
  - 想獲取證書時，用戶得自行安裝客戶端證書。
  - 但由于客戶端證書是要付費購買的，且每張證書對應到每位用戶也就意味著需支付和用戶數對等的費用。
  - 另外，要讓知識層次不同的用戶們自行安裝證書，這件事本身也充滿了各種挑戰。
現狀是，安全性極高的認證機構可頒發客戶端證書但僅用于特殊用途的業務。比如那些可支撐客戶端證書支出費用的業務。
- 例如，銀行的網上銀行就采用了客戶端證書。在登錄網銀時不僅要求用戶確認輸入 ID 和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。

自簽名證書

獨立構建的認證機構叫做自認證機構，由自認證機構頒發的“無用”證書也被稱為自簽名證書。

TLS&SSL協議

SSL協議現已廢棄:(SSL->TLS)

Transport Layer Security (TLS), the successor of the now-deprecated Secure Sockets Layer (SSL), is a cryptographic protocol designed to provide communications security over a computer network.
HTTPS was used with the SSL protocol. As SSL evolved into Transport Layer Security (TLS),

傳輸層安全性協議（英語：Transport Layer Security，縮寫：TLS）及其前身安全套接層（英語：Secure Sockets Layer，縮寫：SSL）是一種安全協議，目的是為互聯網通信提供安全及數據完整性保障。
網景公司（Netscape）在1994年推出首版網頁瀏覽器－網景導航者時，推出HTTPS協議，以SSL進行加密，這是SSL的起源。
- IETF將SSL進行標準化，1999年公布TLS 1.0標準文件（RFC 2246）。
- 隨后又公布TLS 1.1（RFC 4346，2006年）、TLS 1.2（RFC 5246，2008年）和TLS 1.3（RFC 8446，2018年）。
- 在瀏覽器、電子郵件、即時通信、VoIP、網絡傳真等應用程序中，廣泛使用這個協議。
- 許多網站，如Google、Facebook、Wikipedia等也以這個協議來創建安全連線，發送資料。
- 目前已成為互聯網上保密通信的工業標準。
SSL包含記錄層（Record Layer）和傳輸層，記錄層協議確定傳輸層數據的封裝格式。
傳輸層安全協議使用X.509認證，之后
- 利用非對稱加密演算來對通信方做身份認證，之后交換對稱密鑰作為會談密鑰（Session key）。
- 這個會談密鑰是用來將通信兩方交換的資料做加密，保證兩個應用間通信的保密性和可靠性，使客戶與服務器應用之間的通信不被攻擊者竊聽。

SSL技術的通用性

在采用 SSL 后，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。
SSL 是獨立于 HTTP 的協議，所以不光是 HTTP 協議，其他運行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL 協議使用。
可以說 SSL是當今世界上應用最為廣泛的網絡安全技術。

SSL 客戶端認證

從使用用戶 ID 和密碼的認證方式方面來講，只要二者的內容正確，即可認證是本人的行為。
- 但如果用戶 ID 和密碼被盜，就很有可能被第三者冒充。
利用 SSL 客戶端認證則可以避免該情況的發生。
- SSL 客戶端認證是借由 HTTPS 的客戶端證書完成認證的方式。
- 憑借客戶端證書認證，服務器可確認訪問是否來自已登錄的客戶端。

SSL 客戶端認證的認證步驟

為達到 SSL 客戶端認證的目的，需要事先將客戶端證書分發給客戶端。

步驟 1：

服務器接收到需要認證資源的請求，會發送 Certificate Request 報文，要求客戶端提供客戶端證書。
步驟 2：

用戶選擇要發送的客戶端證書后，客戶端會把客戶端證書信息以 Client Certificate 報文方式發送給服務器。

步驟 3：

服務器驗證客戶端證書驗證通過后方可領取證書內客戶端的公開密鑰，然后開始 HTTPS 加密通信。

https

HTTPS通信

如果在 HTTP 協議通信過程中使用未經加密的明文
另外，對于 HTTP 來說，服務器也好，客戶端也好，都是沒有辦法確認通信方的。
很有可能并不是和原本預想的通信方在實際通信。
并且還需要考慮到接收到的報文在通信途中已經遭到篡改這一可能性。

為了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。
我們把添加了加密及認證機制的 HTTP 稱為 HTTPS（HTTP Secure）
HTTP 協議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）的組合使用，加密 HTTP 的通信內容。
用 SSL 建立安全通信線路之后，就可以在這條線路上進行 HTTP通信了。

與 SSL 組合使用的 HTTP 被稱為 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over TLS (早期:HTTP over SSL)。

https的改進目標

HTTPS 協議是由 HTTP 加上 TLS/SSL 協議構建的可進行加密傳輸、身份認證的網絡協議，主要通過數字證書、加密算法、非對稱密鑰等技術完成互聯網數據傳輸加密，實現互聯網傳輸安全保護。

設計目標主要有三個。

（1）數據保密性：保證數據內容在傳輸的過程中不會被第三方查看。就像快遞員傳遞包裹一樣，都進行了封裝，別人無法獲知里面裝了什么。

（2）數據完整性：及時發現被第三方篡改的傳輸內容。就像快遞員雖然不知道包裹里裝了什么東西，但他有可能中途調包，數據完整性就是指如果被掉包，我們能輕松發現并拒收

接收到的內容可能有誤:

由于 HTTP 協議無法證明通信的報文完整性，因此，在請求或響應送出之后直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求 / 響應和接收到的請求 / 響應是前后相同的。
從某個 Web 網站上下載內容，是無法確定客戶端下載的文件和服務器上存放的文件是否前后一致的。文件內容在傳輸途中可能已經被篡改為其他的內容。即使內容真的已改變，作為接收方的客戶端也是覺察不到的。
像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改內容的攻擊稱為中間人攻擊（Man-in-the-Middle attack，MITM）。

（3）身份校驗安全性：保證數據到達用戶期望的目的地。就像我們郵寄包裹時，雖然是一個封裝好的未掉包的包裹，但必須確定這個包裹不會送錯地方，通過身份校驗來確保送對了地方 。

https的通信步驟

步驟 1：客戶端通過發送 Client Hello 報文開始SSL通信。
- 報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2：服務器可進行 SSL 通信時，會以 Server Hello 報文作為應答。
- 和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3：之后服務器發送 Certificate 報文。報文中包含公開密鑰證書。
步驟 4：最后服務器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束。
步驟 5： SSL 第一次握手結束之后，客戶端以 Client Key Exchange報文作為回應。
- 報文中包含通信加密中使用的一種被稱為Pre-master secret 的隨機密碼串。
- 該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6：接著客戶端繼續發送 Change Cipher Spec 報文。
- 該報文會提示服務器，在此報文之后的通信會采用 Pre-master secret密鑰加密。
步驟 7：客戶端發送 Finished 報文。
- 該報文包含連接至今全部報文的整體校驗值。
- 這次握手協商是否能夠成功，要以服務器是否能夠正確解密該報文作為判定標準。
步驟 8：服務器同樣發送 Change Cipher Spec 報文。
步驟 9：服務器同樣發送 Finished 報文。
步驟 10：服務器和客戶端的 Finished 報文交換完畢之后，SSL 連接就算建立完成。
- 當然，通信會受到 SSL 的保護。
- 從此處開始進行應用層協議的通信，即發送 HTTP 請求。
步驟 11：應用層協議通信，即發送 HTTP 響應。
步驟 12：最后由客戶端斷開連接。
- 斷開連接時，發送 close_notify

http和https對比

HTTPS 并非是應用層的一種新協議。
只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。
通常，HTTP 直接和 TCP 通信。當使用 SSL 時，則演變成先和SSL 通信，再由 SSL 和 TCP 通信了。
簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP).
It is used for secure communication over a computer network, and is widely used on the Internet.[1][2]
In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL).
The protocol is therefore also referred to as HTTP over TLS,[3] or HTTP over SSL.

The principal motivations for HTTPS are
- authentication of the accessed website, and
- protection of the privacy and integrity of the exchanged data while in transit.
- It protects against man-in-the-middle attacks, and the bidirectional encryption of communications between a client and server protects the communications against eavesdropping and tampering.[4][5]
- The authentication aspect of HTTPS requires a trusted third party to sign server-side digital certificates.
  - This was historically an expensive operation, which meant fully authenticated HTTPS connections were usually found only on secured payment transaction services and other secured corporate information systems on the World Wide Web.
  - In 2016, a campaign by the Electronic Frontier Foundation with the support of web browser developers led to the protocol becoming more prevalent.[6] (流行)
  - HTTPS is now used more often by web users than the original non-secure HTTP, primarily to protect page authenticity on all types of websites;
    - secure accounts;
    - and to keep user communications, identity, and web browsing private.

總結

以上是生活随笔為你收集整理的http_认证机制https加密TLSSSL密钥对(公钥私钥)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： revit二开之获取嵌套族中的子族（过滤
下一篇： 2016在电影院看过的电影