# MIT:14. SSL and HTTPS 影片筆記

###### tags: `SSL`

> [14. SSL and HTTPS
](https://www.youtube.com/watch?v=q1OF_0ICt9A&t=2856s)

### 1: symmetric encrypt/ asynmetric encrypt /sign

syn: E~KEY~( P)=C , D~KEY~( C)=
對稱加密 一把金鑰 速度快
用於確立安全連線後 client/server雙方加解密

asymc: E~PK~( P)=C , D~SK~ ( C)=P
非對稱加密 公私鑰 公鑰加密內容只有私鑰可解開 速度慢
用於建立安全連線時

sign: Sign~SK~( M)=S , verify~PK~(M,S)=validate result
簽章 用私鑰簽章訊息,得知對應公鑰的所有人可辨識該簽章來源

rdp(remote desktop protocal) 3389
http port 80
https port 443

### 2: KDC缺陷

| name | key |
| -------- | -------- |
| hostName | public Key |
| ... | ... |

>
>Kerberos使用Needham-Schroeder協議作為它的基礎。它使用一個由兩個獨立的邏輯部分：認證伺服器和票據授權伺服器組成的"可信賴的第三方"，術語稱為密鑰分發中心（KDC）。Kerberos工作在用於證明用戶身份的"票據"的基礎上。
>KDC持有一個密鑰資料庫；每個網絡實體——無論是客戶還是伺服器——共享一套只有他自己和KDC知道的密鑰。密鑰的內容用於證明實體的身份。對於兩個實體間的通信，KDC產生一個會話密鑰，用來加密他們之間的交互信息。
>ref: https://zh.wikipedia.org/wiki/Kerberos

1. 中心化: 所有人只信任KDC =>SSL中改善為多個CA(certificate agent)分擔
2. 維護成本: 儲存大量資料/查詢負擔
3. 連線時須先連上KDC才能確認對方安全性=>速度瓶頸
4. 難以scalible/disaster recovery

### 3: SSL process

A(Client)->B(server): sign_A's SK(E_B's PK(secret))
note right of B(server):只有B可解密 藉由sign可確認對方為A
B(server)->A(Client):E_Secret(m)
Note left of A(Client): 後續使用secret加解密

優點:
1. 上圖僅有a生產加密項, 可由b新增hash項目n 使S'=HASH(S||n)
2. 完成authentication
2a. A用A'SK簽章,B因A'PK可認知資料來源為A
2b. B know A's PK to verify
3. remove KDC online issue

### 4. how to find public key

1. 公正第三方 CA(certificate agent):
提供 hostname:public key對照表

| name | key |
| -------- | -------- |
| hostName | public Key|

client要求CA提供server certificate
CA 提供 CA~SIGN~({name:key}) 提供client端驗證server

前提:CA被系統信任

ps. name:key中的name為domain name,而非ip
ps. CA~SIGN~ == CA~ca's_SK~

### 5. CA update certification

1. expiration time 避免CA SKey被偷

2. 兩種補救方案(歷史)
2a. certification revokation list(CRLs):
CRLs紀錄不可信的CA,供查詢: browser需時常更新該列表
2b. online certification status protocal(OCSP):
可信第三方提供可信列表,向server send request前驗證,
壞處:增加latency/ 高度依賴OCSP(if OCSP down then website down)

### 6. https 影響

1. data on network: sign/encrypt =>SSL/TLS
2. code/cookie in Browser:
2a. URL schema: https://
2b. host name in URL == name in certificate
| name | key |
| -------- | -------- |
| hostName | public Key|

2c. cookie use secure flag:
non-secure cookie: send when http/https
secure cookie:send only when https
3. UI(lock icon):依據各家broswer處理,易仿造,可信度低

http連線經由dns查詢IP

如果使用HTTP

A(Client)-->B(server): Hijack by attacker

A(Client)->C(attacker): Hijack by attacker
note right of C(attacker):client data(cookie) leak to malicious source

## 3 way hankshake

Step 1 (SYN): In the first step, the client wants to establish a connection with a server, so it sends a segment with SYN(Synchronize Sequence Number) which informs the server that the client is likely to start communication and with what sequence number it starts segments with

Step 2 (SYN + ACK): Server responds to the client request with SYN-ACK signal bits set. Acknowledgement(ACK) signifies the response of the segment it received and SYN signifies with what sequence number it is likely to start the segments with

Step 3 (ACK): In the final part client acknowledges the response of the server and they both establish a reliable connection with which they will start the actual data transfer

---
### PKI


---
### RA(registration authority) 註冊機構

A registration authority (RA) is an authority in a network that verifies user requests for a digital certificate and tells the certificate authority (CA) to issue it.

The main purpose of an RA is to ensure that a user or device is allowed to request a digital certificate from a specific website or application. If the request is allowed, the RA forwards the certificate request to the CA, which completes the digital certificate request process.

註冊機構(RA)可以被認為是證書機構的看門人。為了獲得證書，請求用戶或設備必須首先在 RA註冊並滿足必要的要求，包括身份和身份驗證檢查。這以證書籤名請求的形式出現。

由 RA 成功註冊的請求隨後被轉發給 CA，CA 的職責是頒發稱為證書的電子文檔。此證書頒發給請求用戶或設備。頒發的證書可以根據 CA 的公鑰進行驗證，以確保證書確實有效並且到遠程資源的連接是可信的。

* work flow

:::info
1. 嘗試訪問受證書支持的網站的用戶向 CA 請求證書。該請求被發送到 Web 服務器。
2. Web 服務器將證書請求轉發給 RA。RA 確保允許用戶接收證書。
3. 如果 RA 批准該請求，則將其傳遞給 CA，CA 生成數字證書。
4. CA 將數字證書直接發送給用戶以完成該過程。

:::

:::info
CA: certification authority, RA: registration authority, VA: validation authority

Rough outline:
* A user applies for a certificate with his public key at a registration authority (RA).
* RA confirms the user's identity to the certification authority (CA) which in turn issues the certificate.
* The user can then digitally sign a contract using his new certificate. His identity is then checked by the contracting party with a validation authority (VA) which again receives information about issued certificates by the certification authority.
:::