# HTTP vs HTTPS

打開你的網頁輸入欄，我們常看到http或是https 開頭，你有好騎過這是什麼嗎？
以下內容將給你解答

## HTTP 介紹
### HTTP 是什麼
**HTTP（HyperText Transfer Protocol）**： HTTP是一種用於在網際網路上傳輸超文本（例如網頁）的協議。它用於瀏覽器和Web伺服器之間的通信，使用戶可以在瀏覽器中訪問和檢視網頁。HTTP是一個客戶端-服務器協議，用戶（客戶端）向Web伺服器（服務器）發送HTTP請求，伺服器則回應請求並提供所請求的網頁或資源。
### 其他傳輸協議
除了HTTP 還有其像是FTP SMTP 傳輸協議:
- **FTP（File Transfer Protocol）**：FTP是一種專為文件傳輸而設計的協議。它允許用戶將文件從一個計算機傳送到另一個計算機，通常用於文件上傳、下載和文件管理。FTP可以在原始形式下運行，也可以使用安全的FTPS或SFTP實現加密傳輸。
- **SMTP（Simple Mail Transfer Protocol）**：SMTP是一種用於電子郵件的協議。它用於發送和路由電子郵件消息，並確保消息能夠正確傳遞到接收者的電子郵件伺服器。SMTP通常用於電子郵件客戶端和伺服器之間的通信，以及伺服器之間的電子郵件路由。

以下是他們三者間的比較表，簡單總結三種不同傳輸協議的主要差異：

| 特性 | HTTP（HyperText Transfer Protocol） | FTP（File Transfer Protocol） | SMTP（Simple Mail Transfer Protocol） |
|-------------------|--------------------------------------|-----------------------------|----------------------------------------|
| 用途 | 用於在網絡上傳輸超文本，通常用於網頁瀏覽和資源檢索。 | 用於在網絡上傳輸文件，特別是大文件或目錄。 | 用於傳送電子郵件。 |
| 協議層次 | 應用層 | 應用層 | 應用層 |
| 通信方式 | 客戶端-服務器 | 客戶端-服務器 | 服務器-服務器 |
| 通信端口 | 80（默認） | 21（默認） | 25（默認） |
| 安全性 | 原始HTTP不安全，但可以使用HTTPS實現安全傳輸。 | 原始FTP不安全，但可以使用FTPS或SFTP實現安全傳輸。| SMTP通常不加密，但可以使用SMTPS或STARTTLS實現安全傳輸。 |
| 用戶驗證 | 可以使用基本驗證、摘要驗證等。 | 可以使用匿名登錄或使用者名稱/密碼驗證。 | 使用者名稱/密碼驗證。 |
| 文件傳輸方式 | 傳輸超文本、圖像、視頻等。 | 傳輸文件和目錄。 | 傳送電子郵件消息。 |
| 主要應用 | 網頁瀏覽、資源檢索、API通信等。 | 文件上傳和下載、軟件分發等。 | 電子郵件的發送和路由。 |

這個表格總結了HTTP、FTP和SMTP的主要區別，包括它們的用途、協議層次、通信方式、安全性、用戶驗證、文件傳輸方式以及主要應用。每種協議都有其獨特的用途和特點，根據不同的需求和情境來選擇使用。

## HTTPS 介紹
HTTPS（Hypertext Transfer Protocol Secure）是一種安全的超文本傳輸協議，用於在網絡上安全地傳輸數據。它是HTTP的一種安全版本，主要用於保護數據在客戶端和服務器之間的傳輸過程中不被恶意攻击者窺探、竊取或篡改。以下是HTTPS的主要特點和運作原理：

當然，我可以幫你進行排版，讓上述內容更易讀：

**1. 數據加密：**

- **說明：** HTTPS使用加密技術來加密數據，使其在傳輸過程中無法被第三方讀取。最常見的加密協議是TLS（Transport Layer Security）或其前身SSL（Secure Sockets Layer）。

- **舉例：** 想像你寫了一封信給遠方的朋友，信中包含了一些私人訊息。如果你只是把信放進一個普通的信封裡，郵遞員或任何在信件傳遞途中接觸到它的人都有可能打開信封並閱讀這些私人訊息。這就像是未加密的 HTTP：數據在網絡上明文傳輸，任何人只要在傳輸路徑上，就有可能讀取這些數據。

現在，假設你有一個特殊的魔法箱（TLS/SSL加密），你將信放進箱子裡並用一個只有你和你朋友知道的特殊密碼（加密密鑰）來鎖住。然後，你將這個箱子郵寄給你的朋友。在這種情況下，即使郵遞員或其他人拿到了這個箱子，他們也無法打開它，因為他們不知道密碼。只有你的朋友收到箱子後，才能用密碼打開箱子，讀取信件。

這就像是 HTTPS：數據在傳輸過程中被加密，即使數據被截獲，沒有適當的密鑰也無法解讀。總結來說，HTTPS通過使用TLS/SSL加密技術，確保數據在傳輸過程中保持私密和安全，就像是使用一個只有發送者和接收者能夠開啟的魔法箱子來郵寄信件一樣。

當然可以，這裡是根據您提供的格式對2、3、4項的內容進行的重新編排：

**2. 身份驗證：**

- **說明：** HTTPS通過使用數字證書來驗證客戶端和服務器的身份。這確保了用戶在與預期的網站進行通信，而不是與偽造的網站。

- **舉例：** 想像你收到一封來自朋友的信。如果信封上沒有任何標記，你可能無法確定這真的是你朋友寄來的。但如果信封上有你朋友獨特的印章（數字證書），你就可以確定這是真實的來信。同樣，在HTTPS中，當你訪問一個網站時，網站的數字證書就像是這個獨特的印章，讓你確信你正在與真正的網站通信。

**3. 完整性保護：**

- **說明：** HTTPS使用校驗和數字簽名來確保在傳輸過程中數據的完整性，從而防止任何未經授權的修改。

- **舉例：** 想像你將一件珍貴的藝術品用封條密封並寄出。如果封條在到達目的地時被破壞或更改，收件人就知道途中可能發生了篡改。在HTTPS中，校驗和和數字簽名就像是這樣的封條，保證數據在傳輸過程中保持未被更改，確保其完整性。

**4. 信任鏈：**

- **說明：** 數字證書由受信任的證書機構（Certificate Authorities，簡稱CA）簽發，這些機構被瀏覽器內置信任。當您訪問一個使用HTTPS的網站時，瀏覽器將檢查該網站的數字證書是否由受信任的CA簽發，以確保該網站的真實性。

- **舉例：** 想像你在一家新餐廳用餐，你可能會懷疑它的品質。但如果知名美食評論家（CA）推薦這家餐廳，你會更有信心。在HTTPS中，證書機構就像是這些評論家，當你訪問一個網站時，由這些機構簽發的數字證書為該網站提供了可信度，讓你放心與之交互。

**5. 端口：**

- **說明：** 在網絡通信中，HTTP和HTTPS使用不同的端口來傳輸數據。HTTP通常使用端口80，而HTTPS則通常使用端口443。端口是網絡地址的一部分，用於區分不同的網絡服務。

- **舉例：** 想像一座大樓（網絡伺服器），其中有許多不同的入口（端口）。每個入口都對應不同的服務。端口80就像是專為普通訪客（HTTP流量）設置的大門，而端口443則像是一個安全的入口，僅供持有特殊通行證（HTTPS流量）的訪客使用。這樣，即使兩種訪客都訪問同一座大樓，他們也會通過不同的入口進入，確保安全和有序的流量管理。

### HTTP vs HTTPS
以下是HTTP和HTTPS之間的比較：

| 特點 | HTTP | HTTPS |
|------------------|-----------------------------------------|-----------------------------------------|
| 安全性 | 不安全，數據以明文形式傳輸，容易被竊取或竄改 | 安全，數據通過加密傳輸，難以被竊取或竄改 |
| 協議 | 標準的超文本傳輸協議 | 安全的超文本傳輸協議 |
| 加密 | 不提供數據加密 | 使用TLS或SSL加密數據傳輸 |
| 網站識別 | 未驗證，無法確保網站真實性 | 通過數字證書驗證網站真實性 |
| 數字證書 | 不需要數字證書 | 需要由受信任的證書機構（CA）簽發的數字證書 |
| 預設端口 | 80 | 443 |

總結來說，HTTP是一種不安全的協議，數據以明文形式傳輸，不提供加密、身份驗證和完整性保護。

而HTTPS是HTTP的安全版本，通過使用TLS或SSL協議對數據進行加密，同時使用數字證書驗證網站的真實性，從而確保數據在傳輸過程中的安全性和完整性。

因此，在保護用戶隱私和數據安全方面，HTTPS是更安全的選擇，特別是對於敏感信息的傳輸。

## 其他問題
### 1. TLS/SSL 加密 vs. SSH 加密

以下是TLS/SSL 加密和SSH 加密之間的主要區別：

| 特性 | TLS/SSL 加密 | SSH 加密 |
|------------------------|----------------------------------------|--------------------------------------|
| 用途 | 主要用於網際網路通信，例如瀏覽器和網站之間的數據傳輸。 | 主要用於安全的遠程訪問和控制遠程服務器。 |
| 適用協議 | 用於保護 HTTP（HTTPS）、SMTP（SMTPS）、IMAP（IMAPS）等應用層協議。 | 主要用於遠程 shell，也可用於文件傳輸和端口轉發等多種用途。 |
| 加密層次 | 運行於傳輸層（第四層），提供端到端的數據加密。 | 運行於應用層（第七層）或傳輸層，可選擇性地提供端到端的數據加密。 |
| 金鑰交換方式 | 常用的金鑰交換方式包括RSA和ECDHE，可靠於證書機構（CA）簽署的數字證書。 | 常用的金鑰交換方式包括基於密碼的認證、公鑰認證和主機密鑰。 |
| 主要端口 | 443（HTTPS）, 465（SMTPS）, 993（IMAPS）等。 | 22（SSH） |
| 主要工作流程 | 客戶端和服務器建立連接，交換加密協議，協商加密參數，建立安全連接。 | 客戶端和服務器之間進行身份驗證，協商加密算法，建立安全的遠程連接。 |
| 安全性 | 適用於網絡通信，提供端到端的數據保護，可用於安全的網絡傳輸。 | 適用於遠程訪問，提供對遠程服務器的安全訪問和控制。 |

總之，TLS/SSL 和 SSH 都是加密協議，但它們的用途、層次和主要特點有所不同。

TLS/SSL 主要用於網絡通信的加密，而 SSH 主要用於遠程訪問和控制。

### 2. 為何在網址欄輸入 http 或直接輸入 www. 會導入至 https？

用戶輸入 http 或只是 www.，網站通過自動重定向到 https 來確保提供安全的瀏覽體驗，具體來說，這涉及到以下幾個部分：

1. **網站伺服器設定：** 網站管理員會在伺服器上設置重定向規則。這通常通過修改伺服器的配置文件來實現，比如 Apache 的 `.htaccess` 文件或 Nginx 的配置文件。這些規則指示伺服器在收到 HTTP 請求時，自動將其重定向到 HTTPS。

2. **應用程式層面的重定向：** 在某些情況下，重定向還可以通過網站的後端程式（例如使用 PHP、Node.js 等）來實現。程式碼會檢查請求是否是 HTTPS，如果不是，則發送一個重定向響應。

3. **Content Delivery Network (CDN)：** 對於使用 CDN 來分發內容的網站，CDN 服務提供商也可以設置 HTTP 到 HTTPS 的重定向。這通常在 CDN 配置控制面板中完成。

4. **網站代碼和元標籤：** 網站的 HTML 代碼中可以包含特定的元標籤，指示瀏覽器始終通過 HTTPS 加載頁面。

這些重定向機制的實施確保了即使用戶輸入的 URL 不是 HTTPS，他們仍然會被安全地導向到加密的 HTTPS 版本，從而提高瀏覽安全性和用戶數據保護。

### 3. 什麼是網站證書（SSL/TLS證書）？

- **說明：** 網站證書是一個數字文件，用於確保網站的身份和數據的安全性。它包含了網站的公開金鑰，以及其他有關網站擁有者的信息。網站證書由受信任的證書機構（CA）簽發，用戶的瀏覽器信任這些CA，因此它們能夠確保網站的真實性。

### 4. 什麼是跨網站腳本攻擊（XSS）？

- **說明：** 跨網站腳本攻擊是一種網絡安全漏洞，攻擊者通過在網頁上注入惡意腳本，使用戶的瀏覽器執行這些腳本，從而竊取用戶數據、會話令牌或進行其他惡意活動。為了防止XSS攻擊，開發人員需要適當地過濾和驗證用戶輸入，並使用安全的編碼方式。

### 5. 什麼是SQL注入攻擊？

- **說明：** SQL注入攻擊是一種利用不當處理用戶輸入的漏洞，從而在應用程序的數據庫中執行惡意SQL查詢的攻擊方式。攻擊者可以通過注入SQL代碼，對數據庫進行非法操作，例如刪除數據、泄露敏感信息或修改數據。防止SQL注入攻擊的方法包括使用參數化查詢、適當的權限控制和輸入驗證。

### 6. 什麼是跨站點请求偽造（CSRF）攻擊？

- **說明：** 跨站點请求偽造攻擊是一種攻擊方式，攻擊者利用受害者在已經身份驗證的情況下在網站上執行未經授權的操作。攻擊者可以誘導受害者執行某些操作（例如更改密碼、發送資金），而受害者的瀏覽器會以其已經驗證過的身份執行這些操作。防止CSRF攻擊的方法包括使用CSRF令牌、驗證HTTP Referer標頭等。

### 7. 什麼是雙因素驗證（2FA）和多因素驗證（MFA）？

- **說明：** 雙因素驗證和多因素驗證是一種增強帳戶安全性的方法。它們要求用戶在登錄時提供多個身份驗證因素，通常包括密碼（知識因素）以及某種形式的硬體或軟體令牌、指紋、短信驗證碼等（擁有因素或生物特徵因素）。這樣即使攻擊者獲得了用戶的密碼，他們仍然需要另一個因素才能成功登錄。

這些問題涵蓋了一些網絡安全和網絡通信的重要主題，有助於更全面地理解相關的概念和考慮到安全性。

## 備註
1. 關於SSL 作用層，查了許多文章有的從第七層到第四層都有，目前似乎沒有個標準答案

## 延伸閱讀
1. [網路七層概念 / OSI 七層模型：解釋網路通訊的層次結構](https://hackmd.io/@rgnkud/B13cOR-Pp)
2. [TCP/IP 4層是什麼？ 跟OSI七層有什麼關係](https://hackmd.io/@rgnkud/SkBECYMP6)
3. [三次握手 vs 四次握手](https://hackmd.io/@rgnkud/SkUO8ofva)