DAY24 連網站時，怎麼建立可信又安全的通訊?

• 一. SSL和TLS是什麼?
  • 1-1 SSL 安全通訊端層
  • 1-2 TLS 傳輸層安全性協定
  • 1-3 中間人攻擊
• 二. HTTP和HTTPS是什麼?
  • 2-1 HTTP 超文本傳輸協定
  • 2-2 HTTPS 安全超文本傳輸協定
  • 2-3 HTTPS保護流程
  • 2-4 HTTPS不代表一定安全
  • 2-5 憑證鏈

假設今天要登入一個網站
https://mikey.com
輸入了:
帳號:MIKEY
密碼:12345
這時候會出現的安全問題:

1. 別人會不會看到?
2. 資料會不會被改?
3. 我輸入帳密的這個網站是真的嗎?

一. SSL和TLS是什麼?

1-1 SSL 安全通訊端層

Secure Sockets Layer，SSL
安全通訊端層
一套早期的安全通訊技術

官方指引:TLS是SSL的後續版本

1-2 TLS 傳輸層安全性協定

Transport Layer Security，TLS
傳輸層安全性協定

主要功能是:
幫應用程式建立安全通訊

1. 讓第三方即使攔截資料，也不能直接讀懂內容 (機密性)
2. 資料在傳輸途中有沒有遭未授權修改 (完整性)
3. 你連的Server是否是我要找的網域 (身分驗證)

IPAS 115-1 Q6 選項A
應用層:HTTPS透過TLS提供"端對端加密"
防止網頁傳輸內容遭中間人竊聽攻擊

1-3 中間人攻擊

Man-in-the-Middle Attack，MITM
中間人攻擊

概念就是攻擊者夾在客戶端與伺服器端中間
攻擊者可能會在中間進行:

• 竊聽 Eavesdropping
• 竄改 Modification
• 冒充 Impersonation

二. HTTP和HTTPS是什麼?

2-1 HTTP 超文本傳輸協定

Hypertext Transfer Protocol，HTTP
超文本傳輸協定

瀏覽器(Browser)和Web Server之間的溝通規則
通常在:TCP 80 Port

HTTP本身，不提供TLS加密保護

2-2 HTTPS 安全超文本傳輸協定

Hypertext Transfer Protocol Secure，HTTPS
安全超文本傳輸協定
HTTP + TLS

通常在:TCP443 Port

2-3 HTTPS保護流程

假設今天打開了一個HTTPS網站

1. 打招呼
   • 瀏覽器:嗨我想跟你聊天，但我想先確定你是不是我找的人
   • Server:好，這是我的身分證(SSL憑證)和我的公鑰
2. 驗證身分
   • 瀏覽器檢查這張身分證是不是真的(有沒有信任的機構簽發過"CA")
   • 如果是假的->就會跳出「此連線不安全」
3. 交換密鑰 DAY12對稱與非對稱式加密
   • 瀏覽器用Server的公鑰，加密一把工作階段密鑰傳過去
   • 因為是用Server的公鑰加密的，所以能解密的只有Server的私鑰
     • 公鑰(打開的保險箱)，私鑰(保險箱鑰匙)
4. 加密溝通
   • 之後的所有HTTP請求和回應都用這個密鑰去加密
   • 中間人就算看到也是一堆亂碼，因為他不知道密碼規則所以也解不了(因為他沒有臨時密鑰)

這一整段流程就是TLS

1. TLS握手
2. 憑證驗證
3. 密鑰交換
4. TLS加密通道

所以TLS傳輸層安全協定
會把DAY12學到的對稱和非對稱加密配合使用
這就叫混合式密碼技術

工作階段金鑰 Session Key
某一次通訊工作階段使用的對稱式金鑰

1. TLS交握
2. 建立Session Key
3. 使用對稱式加密
4. 快速保護大量資料

2-4 HTTPS不代表一定安全

即使顯示HTTPS

它還是有可能是釣魚網站

HTTPS只代表:
你和這個網站之間的通訊被TLS保護
不代表:

• 網站一定合法
• 網站沒有 SQL Injection
• 網站沒有 XSS
• 等等...

只能說你與網站伺服器有安全的通訊通道
但不保證網站本人是不是壞人
或網站本人有沒有漏洞

怎麼確定這個網站是本人還是壞人?
靠的就是DAY13提過的Certificate數位憑證
就像網站的身分證，內容包含(網域名稱)和公鑰
瀏覽器透過驗證這張憑證來確認server身分，建立安全連線

• 驗證:
• 誰發的->這張憑證的CA有沒有在瀏覽器的信任名單
• 發給誰->憑證上的網域跟我連的網站有沒有一樣
• 過期沒->有效期限到了沒
• 被竄改沒->用瀏覽器上CA的公鑰去驗數位簽章

而這些憑證是由CA(憑證授權機構)組織來發放
以上這一整套機制就是PKI公鑰基礎建設
包含:CA、憑證、公私鑰、數位簽章、信任鏈

2-5 憑證鏈

剛剛提到的網站的憑證是由CA去發放和簽署
而CA上面還有一個，負責授權底下這些CA的Root CA
所以:
網站憑證也不是直接由RootCA去發放

整體憑證鏈是:

1. RootCA 瀏覽器出廠就信任(下載瀏覽器時內建的名單)
2. 中繼CA IntermediateCA
   • RootCA和網站之間的中繼，負責代替RootCA發憑證
3. 網站憑證 中間CA發的

Root CA
整個信任鏈的最上層CA
如果:
伺服器憑證可以一路驗證到最上面的可信RootCA
瀏覽器才有理由信任這張憑證