OpenSSL 使用指令進行 RSA 加解密
本篇文章介紹使用 openssl 使用指令進行 RSA 加解密。包含使用 PEM 和 DER 格式，以及使用 Base64 格式的方法。 加密首先我們把明文存在檔案裡，例如 message.txt： 1test 有兩種指令可以使用。 rsautlPEM使用公鑰來加密 1openssl rsautl -encrypt -inkey public.pem -pubin -in message.txt -out encrypted 將加密後的資料存成檔案 encrypted。 可以使用不同的 padding 12345-ssl Use SSL v2 padding-raw Use no padding-pkcs Use PKCS#1 v1.5 padding (default)-oaep Use PKCS#1 OAEP-x931 Use ANSI X9.31 padding DER使用公鑰來加密 ...
OpenSSL 使用指令進行簽章和檢驗
本篇文章介紹使用 openssl 使用指令進行簽章和檢驗，例如可以使用 RSA 或 EC (ECDSA) 金鑰來簽章和檢驗。包含使用 PEM、DER 和 PVK 格式，以及使用 Base64 格式的方法。 簽章首先我們把要簽署的訊息存在檔案裡，例如 message.txt： 1test PEM使用私鑰來簽章，把簽章輸出到檔案： 1openssl dgst -sha256 -sign private.pem -out sig message.txt sig 為輸出的檔案名稱，-sha256 為用來簽章的演算法，可以使用下面指令來看有哪些可使用： 1openssl dgst -list 會輸出下面內容： 12345678910Supported digests:-blake2b512 -blake2s256 -md4 -md5 -md5-sha1 -mdc2 -rip ...
OpenSSL 指令產生 RSA 私鑰和公鑰
本篇文章介紹使用 openssl 指令產生 RSA 的私鑰和公鑰，包含 PEM、DER 和 PVK 格式。其中 PEM 分為 PKCS#1 和 PKCS#8 兩種格式。同時也說明如何生成包含密碼的方式。 產生私鑰無密碼PEM (PKCS#1)輸入下面指令，會產生 private.pem 私鑰檔案 1openssl genrsa -out private.pem 2048 檔案內容大概長這樣 123456789101112131415161718192021222324252627-----BEGIN RSA PRIVATE KEY-----MIIEpQIBAAKCAQEA3MiYJlVyBkmU9NKeV7gVBvkf7Je0PlzFl04G047XVaOV5mYBA5dYxjQw/Gib7EWE7XAO9gB9woCtFiKTeIaZ1dWMCGWAxRjTnb+eTtMQd2+U0VyDeMRD8joF2FuPnSwacSbccRzoa+Eg0PUKS/jB7iSDj1o7oBf3pgakogR5rwTx/i9QC866vYHQOHbVOT0MsWEiUlKhoyHxSXbnSF ...
OpenSSL 指令產生 EC 私鑰和公鑰
本篇文章介紹使用 openssl 指令產生 EC 橢圓曲線的私鑰和公鑰，包含 PEM 和 DER 格式。其中 PEM 分為 PKCS#1 和 PKCS#8 兩種格式。同時也說明如何生成包含密碼的方式。 產生私鑰無密碼PEM (PKCS#1)輸入下面指令，會產生 private.pem 私鑰檔案 1openssl ecparam -name secp256k1 -genkey -noout -out private.pem 檔案內容大概長這樣 12345-----BEGIN EC PRIVATE KEY-----MHQCAQEEILQ9di0umjx6JoN3j6oOf9AC09z6M2X1dmRJHQ2tjinHoAcGBSuBBAAKoUQDQgAEtPaEJXHpn09OBCz34QDeEltOVhAgs+qyB2MnyFr8t/lpmsgFyTKr80+pP7R3UV99tzMjSZ2DI/udIQOjKFdgEg==-----END EC PRIVATE KEY----- 其中，secp256k1 是指定的曲線，可以自行設定。以下指令可以查詢有哪些曲線可用： 1openss ...
Nginx 限制請求速率 (ngx_http_limit_req_module)
說明本篇文章介紹 Nginx 的限制請求速率模組 ngx_http_limit_req_module，說明可用指令和基本範例。限制請求速率通常用來防止 DDOS 或是暴力破解密碼等惡意攻擊，該模組有以下指令： limit_req_zone limit_req limit_req_dry_run limit_req_log_level limit_req_status 指令limit_req_zone 標題 內容 語法 limit_req_zone key zone=name:size rate=rate [sync]; 預設值 - Context http 這個指令是定義規則，相關的參數如下 key：可以視為符合的條件，例如照 IP、Server Name 或國家等等不同條件，參考最後的範例。 name：唯一名稱。 size：配置多少記憶體。 rate：限制的速率，可以是每秒或是每分多少次。 sync：是商業版的功能，暫時先不討論。 簡單的例子 1limit_req_zone $binary_remote_addr zone=perip ...
Nginx 限制連線數 (ngx_http_limit_conn_module)
說明本篇文章介紹 Nginx 的限制連線數模組 ngx_http_limit_conn_module，說明可用指令和基本範例。限制連線數通常用來防止 DDOS 等惡意攻擊，該模組有以下指令： limit_conn_zone limit_conn limit_conn_dry_run limit_conn_log_level limit_conn_status 指令limit_conn_zone 標題 內容 語法 limit_conn_zone key zone=name:size; 預設值 - Context http 這個指令是定義規則，相關的參數如下 key：可以視為符合的條件，例如照 IP、Server Name 或國家等等不同條件，參考最後的範例。 name：唯一名稱。 size：配置多少記憶體。 簡單的例子 1limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn 標題 內容 語法 limit_conn zone number; 預設值 - Con ...
Rails + Passenger 解決 Request queue full (configured max. size: 100)
問題透過 Passenger 的相關 HTTP Request 回應 503，出現下面錯誤訊息 1Request queue full (configured max. size: 100) 原因Passenger 使用多個程序 (Process) 來處理 HTTP 請求，預設為 6 個。當大量 Request 進來時，處理不及的會先放在 Queue 等待處理，預設 100 個，當超過 Queue 的上限時會出現這錯誤。 處理請求速度不夠，來不及消化是出現錯誤的原因，然而處理速度不夠的原因就有很多可能，而對應的解決方式也都不同。這邊列出幾個我想得到的原因： 設定問題 程式效能問題 大量 HTTP 請求 程式存在 Bug 底層框架或套件有 Bug 網路上可能會看到有人說去修改 passenger_max_request_queue_size 的設定，來增加 Queue 的大小，但這沒有根本解決問題，還是要找出原因來對做應處理。 設定問題說明比較常見的是 Passenger 使用 ActionCable 時設定沒有正確。ActionCable 使用 Socket 持續連線，所以會常時 ...
Rails ActionCable 效能測試
本篇文章說明連線數上限相關設定，以及實測 ActionCable 預設模式、Standalone 模式和 AnyCable 三種方案的效能比較。 準備首先建立一個 Rails 專案來測試 ActionCable 連線效能，先寫一個簡單的 Channel 12345class MessageChannel < ApplicationCable::Channel def subscribed stream_for 'message_channel' endend 在 config/environments/development.rb 加上 1config.action_cable.disable_request_forgery_protection = true 然後寫一個 Node Client 程式來測試，使用套件 @anycable/web 和 ws 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849imp ...
Solidity 智能合約 - 工廠模式的搶先交易問題 (Front Running)
之前的文章 Solidity 智能合約 - 工廠模式的重組問題 (Reorg) 說明了重組問題和解決方案，但是並不能防止搶先交易 (Front Running)。本篇文章將說明這個安全問題，以及解決方式。 搶先交易 (Front Running)這是區塊鏈常見的一種獲利手法，也可以說是一種攻擊，監控未確認的交易來預知未來將發生的事情，讓自己的交易搶先執行而獲利。例如看到有人要用大單買入 ETH，就搶先買入後抬高價格賣給他。 問題延續上一篇文章的情境： 使用者 A 用 salt 0xabcd... 建立一個多簽錢包 0x9876...。 使用者 A 轉入 ETH 到 0x9876...。 假設使用者 A 先預測了生成的錢包為 0x9876...，並連續送出第二筆交易。這時候在鏈上，存在這兩筆未確認交易，攻擊者看到後搶先送出他的交易： 攻擊者 C 用 salt 0xabcd... 建立一個多簽錢包 0x9876...。 使用者 A 用 salt 0xabcd... 建立一個多簽錢包 0x9876...。已存在，交易失敗。 使用者 A 轉入 ETH 到 0x9876...。 結果 E ...
Solidity 智能合約 - 工廠模式的重組問題 (Reorg)
之前的文章 Solidity 智能合約 - 工廠模式 (Factory Pattern) 和 Solidity 智能合約 - 地址生成規則說明了工廠模式和地址生成的規則。在了解這些之後我們會發現某些情況可能存在重組的問題，本篇文章將說明這個安全問題，以及解決方式。 重組 (Reorg)我們這裡只簡略的說明這個現象，簡單說就是區塊打包的結果有可能發生變動，造成原本執行交易的結果發生變化 問題在工廠模式中採用 create 的地址生成規則的時候，會和執行順序有關。我們考慮以下的模擬情境： 使用者 A 建立一個多簽錢包 0x1234...。 使用者 A 轉入 ETH 到 0x1234...。 使用者 B 建立一個多簽錢包 0x5678...。 由於發生重組，順序改變了： 使用者 B 建立一個多簽錢包 0x1234...。 使用者 A 建立一個多簽錢包 0x5678...。 使用者 A 轉入 ETH 到 0x1234...。 結果使用者 A 的 ETH 跑到使用者 B 建立的 0x1234... 解決方案等待區塊確認如同中心化交易所入金一樣，等待足夠多的區塊確認後再進行下一步，使用者 ...