Tag: signature

用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡，ap-southeast-1)，但發現偶而會很不順，傳輸的時候會很卡，所以後來決定租了一條專線用 AWS Direct Connect 接進去。

不過因為跑在 AWS 上面的服務是掛在 public network 上，而不是 private ip 的網段，所以就不能用 IPsec site-to-site 打通收工，而需要搞 BGP routing，然後就卡關卡的亂七八糟 XD

首先是文書作業的部份，因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權)，這部份在 web console 上建立完 Public VIF 後會進入審核階段，接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定，我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。

這邊比較有趣的是，如果你沒有買 support plan 的話無法開 technical support，但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別：「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。

過了審核後接下來是設定 pfSense 的部份，因為是要接通 public network 的部份，所以你要收 AWS 提供的 BGP routing，這部份在 pfSense 上會透過 OpenBGPD 解決，但主要還是因為對 BGP 不熟悉，所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題，不然現在事後來看，自己 tcpdump 應該就有能力找到問題了...

主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。

這是一個 TCP extension，連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改：「Protection of BGP Sessions via the TCP MD5 Signature Option」。

要注意的是這個協定不是 application level，而是在 TCP 層本身就保護起來，包括 3-way handshake 的部份，所以從一開始 SYN 封包過去就要有 md5sig 的資訊。

這也表示用 telnet 不會通是正常的，這點讓我找問題找錯方向好久...

另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD)，這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到：

Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.

That module is required for TCP_SIGNATURE to function.

If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.

到了對應的選項那邊要選擇，因為我們的 pfSense 機器比較低階，沒有那堆硬體加速度的東西，所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。

設定完後新的連線也還是不會有效果，後來想了一下還是整台重開機，然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題，純粹就是不熟悉這些東西造成的。

JSON Canonicalization

這篇是講 JSON object 上的簽名，但實際上就是在討論 JSON Canonicalization 的前因後果：「How (not) to sign a JSON object」。

在處理 JSON 資料時，「判斷兩個 JSON object 是否相同」是一個不怎麼簡單的問題，其中一個想法是找一個機制可以把意義相同的 JSON object 都轉成相同的 (byte)string representative，這也就是 JSON Canonicalization。當你可以確保意義相同的 JSON Canonicalization 後，你就可以對 string 本身簽名。

這件事情其實在 XML 就有過同樣的歷史故事 (yeah，總是有人愛在某種資料格式上面疊上簽名)，也就是「XML Signature」這個方式。

在 XML 這邊不幸的是，還不少標準選用 XML Signature，像是當年為了實做 Google Apps (現在叫做 G Suite) 的 SSO，而需要接 SAML...

回到原來的 JSON Canonicalization，可以馬上想到的變化包括了空白與 object 裡 key 的順序，也就是這兩個：

{"a":1,"b":2}
{
  "b": 2,
  "a": 1
}

但不幸的是，還有 Unicode 來一起亂，也就是下面這個跟上面有相同的意思：

{
  "\u0062": 2,
  "\u0061": 1
}

另外還有其他的地雷是平常不會想到的，如果你因為複雜而決定用 library 來做，那也代表 library 必須面對這些複雜的情境，未必沒有 bug...

所以文章作者在最後面才會請大家不要再來亂了 XDDD

Maybe you don’t need request signing? A bearer token header is fine, or HMAC(k, timestamp) if you’re feeling fancy, or mTLS if you really care.

Canonicalization is fiendishly difficult.

Add a signature on the outside of the request body, make sure the request body is complete, and don’t worry about “signing what is said versus what is meant” – it’s OK to sign the exact byte sequence.

microG 的進展...

留在 tab 上的東西，忘記在哪看到的... microG 發佈了新的專案：「LineageOS for microG」。

microG 是 Android 上 Google 服務 API 的重新實作 (所以 open source)，不像 Open GApps 還是屬於 proprietary software。

這次的事情是 microG 的人 fork 了 LineageOS 專案，因為 LineageOS 專案拒絕 microG 的 signature spoofing patch：

Why do we need a custom build of LineageOS to have microG? Can't I install microG on the official LineageOS?

MicroG requires a patch called "signature spoofing", which allows the microG's apps to spoof themselves as Google Apps. LineageOS' developers refused (multiple times) to include the patch, forcing us to fork their project.

另外也提到了他們覺得拒絕的原因很鳥：

Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?

No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services.
The signature spoofing could be an unsafe feature only if the user blindly gives any permission to any app, as this permission can't be obtained automatically by the apps.

Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.

於是就 fork 了新的專案... 就觀察看看吧。

imgproxy：自動處理圖片的工具

看到「imgproxy: Resize your images instantly and securely」這篇文章，介紹「DarthSim/imgproxy」這個專案，想起很久以前的同事在 PIXNET 弄的 *.pimg.tw 系列服務...

imgproxy 可以 resizing，也可以 croping，然後也支援 signature token 機制，感覺是每個大一點的站台都會自己刻一次的服務 XD

整個專案以 Golang 為主，效能應該是不錯... 不過一般前面還是會放 cache 機制 (像是 CDN 之類的服務)，而不會把 loading 直接打進來，避免同樣的圖片一直重複計算。

AWS IAM 支援 SAML 2.0

剛剛看到 AWS 宣佈 AWS IAM 支援 SAML 2.0：「AWS Identity and Access Management Using SAML」。

SAML 是 Single Sign-On 協定的一種，2001 年就推出來了，不過其中用到的架構頗為複雜，由於是 XML 交換技術，再加上要在 XML 上面簽名 (XML Signature)，其實我不是很喜歡這東西... @_@

當初會硬要接觸是因為 Google Apps 的 SSO 是使用 SAML，真是懷念啊...

由於是個公開標準，有不少企業 SSO 方案都有支援 SAML。而 AWS IAM 支援 SAML 就相當於讓控管的部份整合起來了... 我好像也應該來弄弄了？

Blind Signature...

最近看到電子投票的事情，想起之前研究所時所學的密碼學... 是否有辦法找出一個合理的密碼系統，可以在密碼學這層解決電子投票要處理的問題：

  • 正確性：一人一票、無法偽造、無法更改。
  • 匿名性：無法得知單一的投票內容。
  • 可驗證性：自己可以驗證自己的投票內容、任何人都可以驗證全體的投票總數。
  • 其他要求：...

有很多人試著去建立這樣的系統 (在「Cryptography - Electronic Voting」這篇可以看到)，但目前沒有完美的系統可以做到...

其中 Blind Signature 在這樣的系統內常常被拿出來當工具... 之前沒仔細看懂，週末花了一些時間發現 Blind Signature 還蠻有趣的。

Blind Signature 想要與一般的 signature 一樣，讓對方簽 message m，取回 signature s。但多了一個要求：要在對方不知道 m 的內容情況下達到相同的效果。

在 Wikipedia 上有說明用 RSA 的作法，看懂以後覺得還蠻有趣的...