標籤: 資訊學習

討論 HTTP 與 HTTPS 的優缺點前，先來了解瀏覽器和網頁伺服器之間是怎麼溝通的。

HTTP 通訊

HTTP 的 request 主要包含幾個項目：

• URL
• header
• body

其中 URL 固定以明碼 (plain text) 傳輸，若使用 HTTPS 的話，header 和 body 內容會被加密。

URL 的內容會用於判斷 request 應該要由哪一台伺服器接收 (透過 domain 來判斷)，HTTP methods 則用於判斷要如何與伺服器互動，另外還有 HTTP 傳輸協議的版本，例如要使用 HTTP 1.1 或是 2。

以下範例透過 curl 加上 -v 參數，連線至 http://blog.zeroplex.tw/2020/11/01/benfords-law/ 頁面，另外多加上一個 Origin 當作 header。

使用 HTTP (沒有加密) 時，curl 的動作：

curl --http2 --header "Origin: https://zeroplex.tw" -X GET http://blog.zeroplex.tw/2020/11/01/benfords-law/ -v

Note: Unnecessary use of -X or --request, GET is already inferred.
* Host blog.zeroplex.tw:80 was resolved.
* IPv6: (none)
* IPv4: 172.104.77.215
*   Trying 172.104.77.215:80...
* Connected to blog.zeroplex.tw (172.104.77.215) port 80
> GET /2020/11/01/benfords-law/ HTTP/1.1
> Host: blog.zeroplex.tw
> User-Agent: curl/8.5.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAAQAoAAAAAIAAAAA
> Origin: https://zeroplex.tw

按照順序，curl 動作的順序如下：

1. blog.zeroplex.tw:80 was resolved：解析網域名稱，得知網站伺服器的 IP 為 172.104.77.215
2. Connected to blog.zeroplex.tw (172.104.77.215)：連線到伺服器
3. 送出 request (開頭有 > 的內容)

嘛 …. 蠻簡單的。

再來看看使用 HTTPS (有加密) 時，流程上有什麼差異：

curl --http2 --header "Origin: https://zeroplex.tw" -X GET https://blog.zeroplex.tw/2020/11/01/benfords-law/ -v

Note: Unnecessary use of -X or --request, GET is already inferred.
* Host blog.zeroplex.tw:443 was resolved.
* IPv6: (none)
* IPv4: 172.104.77.215
*   Trying 172.104.77.215:443...
* Connected to blog.zeroplex.tw (172.104.77.215) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp521r1 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=blog.zeroplex.tw
*  start date: Aug  7 04:01:59 2025 GMT
*  expire date: Nov  5 04:01:58 2025 GMT
*  subjectAltName: host "blog.zeroplex.tw" matched cert's "blog.zeroplex.tw"
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://blog.zeroplex.tw/2020/11/01/benfords-law/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: blog.zeroplex.tw]
* [HTTP/2] [1] [:path: /2020/11/01/benfords-law/]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [origin: https://zeroplex.tw]
> GET /2020/11/01/benfords-law/ HTTP/2
> Host: blog.zeroplex.tw
> User-Agent: curl/8.5.0
> Accept: */*
> Origin: https://zeroplex.tw

1. blog.zeroplex.tw:443 was resolved：處理 domain，這步驟相同
2. 連線到伺服器，這步也相同
3. TLSv1.3 (OUT), TLS handshake：SSL handshake，這步會透過 TLS 協定來建立加密連線，並且透過 ca-certificates.crt 根憑證來判斷網站的憑證是否正確
4. 送出 request，這部相同，只是資料透過前一步驟的加密連線來傳輸

到這邊，知道除了 URL 以外，header 和 body 都是建立加密連線以後才送出，所以敏感的資料最好是放在 header 和 body，避免被竊聽。

接下來討論 HTTPS 憑證。

憑證

HTTP 中的憑證，指的是 SSL certification。

HTTPS 中的憑證類似「執照」，需要經過審核、確認無誤以後才會頒發，而且會有期限，並不是隨便拿、隨便有的東西。

經過審核以後，憑證會被標示為「受信任」，這個時候，其他使用者連線到你的網站時，瀏覽器才會標示為安全 (綠色鑰匙，或沒有警告)。

標記為安全的憑證，一定是安全的嗎？並不是。

憑證已審核通過後，僅表示審核當下是被判定是沒問題的。若網站有漏洞，且漏洞被惡意人士利用，作為詐騙或是用來散佈惡意程式，通過回報來讓憑證管理機關了解該網站已有安全疑慮，主管機關會撤銷原本簽署的憑證 (徹照)，使用者的瀏覽器便會警告該網站的憑證有問題。回報、到主管機關撤銷憑證之間，會有一段時間憑證仍然被標示為正常，這段時間就必須由使用者自己來判斷是否安全、可信任。

那標示為有問題的憑證，真的就一定有問題嗎？也不是。

憑證被標示有問題，可能只是憑證沒有通過主管機關審核而已。若只是為了自己的伺服器與使用者之間，透過加密連線來保障內容不會被竊聽，可以自己產生的憑證不需要透過主管機關審核，常見的案例就是 wifi 分享器、伺服器設定頁面，都會走 HTTPS 加密連線，但是憑證都顯示為不安全 (沒有過審核)。

以下圖片，是 ASUS 無線網路分享器自己產生的憑證，被瀏覽器標示為不安全：

人權

人權是大哉問，我對人權的了解程度還不適合來討論這個議題，不過有人提到了我要講一下。

台灣的憲法，保障「人民有秘密通訊之自由」，這是基本人權，和居住、安全一樣，是基本的權力，不是選擇性保障的權力。

所以不使用 HTTPS 而是使用 HTTP，指保障了電池使用時間 (處理器不需要加密、解密比較省電)，反而讓使用者多了一個不安全的管道而已。

HTTPS 不代表一定安全，但是一定會比 HTTP 安全。使用 HTTPS 才能讓伺服器、使用者避開已知的問題。

ps1. 不知道作者會不會看到，覺得應該還是寫一下，如果是為了「安全」，你不應該使用 Internet Explore 當作範例，因為瀏覽器本身就不安全

ps2. 如果架網站只是為了從 Google 或 Facebook 等大公司取回自己的權力，那架網站其實只是假議題，公司掌握了超過半數的使用者，他們只要認定你有問題你就有可能讓你從網路上消失，再說你要怎麼確認你的網站不是跑在大公司的伺服器上、網路傳輸優先順序沒有被調低？ (網路中立) 詳細內容請參考「數位帝國」(ISBN：9786267523230)

ps3. 並不是大公司推廣的東西百害無一利，如果 Google 他們沒有推出 SPDY 現在搞不好沒有 HTTP 2

反串注意！

接觸 YAML 大概是因為遇到 docker 和 kubuernetes 的關係，因為設定檔都必須使用 YAML，然後受到各種荼毒。

先來看一下 spec。

YAML 目前支援常見的幾種資料型態：

• 整數：100、-100、不同進位的表示法 0xC
• 浮點數：`1230.15`、12.3015e+02、負無限 -.inf、以及非數字 .nan
• boolean：true、false
• 字串：不加上引號的字串 John 、加上引號 "John" 或 'John'

先到這邊即可，其他容器類型的陣列、物件這邊先不討論。

這邊先來看一下可能會遇到的問題這個描述：

Name: Zeroplex
version: 3.2.9
stable: 3.2

這邊使用 Symfony\Component\Yaml 來 parse 上面的設定，結果為：

array(3) {
  'Name' =>
  string(8) "Zeroplex"
  'version' =>
  string(5) "3.2.9"
  'stable' =>
  double(3.2)
}

二個版本號，一個是字串，一個是數字。

為什麼會這樣？YAML 中並沒有規範怎麼樣的文字會應該是數字、什麼狀態是文字。也就是說如果字串沒有加上引號時，依照不同的 parser 實作方式，可能會有不同的結果。

這就是規範不明確導致的 undefine behaviour，最慘的是不同的 parser 實作方式不同，因此相同的設定檔使用不同的 parser 可能會被轉譯成不同的內容，而且無法誤測。

上述指示其中一個小問題，如果你想知道其他的問題，可以參考 The yaml document hell 這篇文章，設計不良讓大家都下地獄。

除了 YAML 以外，其實還有不少設計很好的語言，可以用來協助標示設定、狀態：

• JSON：以電腦讀取為主，不適合人類閱讀
• XML：同上
• TOML：語法簡單適合人類閱讀，電腦也不需要費力 parse

只因為 YAML 定義不明確，浪費幾個工作天除錯，真是浪費生命。