Let's Encrypt 是個 CA (Certificate Authority)，打算免費提供 SSL certificate，致力於普及網路加密技術。
由於 CA 是架構在稽核程序確保安全性，所以整個設置作業會非常長，最近總算快告一段落了。前幾天放出正式開放的時程：「Let's Encrypt Launch Schedule」。
也就是 2015/07/27 會開放，但這個時間點暫時不會有任何 client 支援 (需要手動安裝他們的 root CA)，而到了 2015/09/14 後，IdenTrust 會交叉簽名，屆時大多數的 client 都可以認得。
AWS 推出了「Amazon API Gateway – Build and Run Scalable Application Backends」，使得 Scalable API 又前進了一步。
API Gateway 可以直接將 HTTP Endpoint 接上 AWS Lambda 提供服務，並且也會自動接上 CloudFront，不過 CloudFront 不可選等級，目前看起來是最低的 Class 100，所以老問題還是沒解，如果不是用 168.95.1.1 或 168.95.192.1，我們家的 IP 會被解去 ARN (Stockholm Arlanda Airport) XD
4.|-- snuh-3201.hinet.net 0.0% 10 0.3 0.3 0.3 0.3 0.0
5.|-- tpdt-3011.hinet.net 0.0% 10 6.7 9.0 4.8 12.5 2.8
6.|-- r4101-s2.tp.hinet.net 0.0% 10 0.5 0.9 0.5 1.5 0.0
7.|-- r4001-s2.tp.hinet.net 0.0% 10 3.8 1.1 0.5 3.8 1.2
8.|-- r11-pa.us.hinet.net 0.0% 10 199.8 151.6 143.1 199.8 19.0
9.|-- las-bb1-link.telia.net 0.0% 10 140.6 142.6 140.5 159.7 6.0
10.|-- sjo-b21-link.telia.net 0.0% 10 141.6 142.1 141.5 146.1 1.2
11.|-- nyk-bb2-link.telia.net 0.0% 10 217.0 218.9 217.0 224.0 2.6
12.|-- kbn-bb4-link.telia.net 0.0% 10 305.7 305.8 305.7 306.2 0.0
13.|-- s-bb4-link.telia.net 0.0% 10 316.4 316.4 316.4 316.6 0.0
14.|-- s-b9-link.telia.net 10.0% 10 316.4 316.5 316.4 317.5 0.0
15.|-- amazon-ic-300293-s-b9.c.t 10.0% 10 311.5 311.5 311.4 311.5 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- server-54-230-96-67.arn1. 10.0% 10 311.5 311.8 311.5 313.2 0.4
除了使用提供的 url 以外 (HTTPS Endpoint)，也可以接上自己的 domain (以及對應的 SSL certificate)：
另外功能是產生 SDK，支援 iOS、Android 以及 JavaScript 三種版本：
這樣又簡化了不少東西...
Tony Hunt 在「We’re struggling to get traction with SSL because it’s still a “premium service”」這篇文章裡抱怨了目前 web 要朝向 HTTPS only 還很遠，甚至還酸了一下 Let's Encrypt 冨樫問題：
可是東尼... 你的站也沒上 HTTPS 啊 :/
順便整理一下目前 HTTPS 技術發展出來的優點：
現在網站的 best practice 是 HTTPS + HTTP/2，對 SEO 好、速度又快 (這兩個對營收有影響)，而另外也可以增加安全性 (對聲譽有幫助)。
在使用 CDN 前，先考慮上 SPDY 或 HTTP/2 (i.e. 全站 HTTPS)，改善的效果跟 CDN latency 帶來的效益有得拼。尤其是 server 放在美國機房的情況，SPDY 與 HTTP/2 帶來的效能提昇是相當明顯的。
會寫這篇是因為這兩個禮拜意外被問到好幾次，所以來整理幾家如果讓我來選，我會選擇的 CDN。至少再被問到的時候可以直接從這邊開始說明。
下面的圖是從我家裡 HiNet 光世代測試的結果 (最後是走兩條電話線)，所以會有個 10ms 的 latency 基底，如果要計算 latency 的效能影響請考慮進去。
先講 Akamai。
Akamai 的歷史很久了，再加上併購了不少公司，所以產品成熟度很夠，你要什麼產品都有提供，只要拿的出錢就可以。
KKBOX (敝公司) 用過 PMD、DSD、DSA 三個產品，其中 PMD 與 DSD 只有保障服務可靠度 (availability)，DSA 還有保障效能提昇 (performance)。早期是用 PMD + DSD，現在改用 PMD + DSA。
在功能面上，雖然 Akamai 是大公司，但各種新功能跟的蠻快的。主要就是為了 SPDY 以及之後預期會有的 HTTP/2 而選了 DSA，另外也剛好有效能提昇 SLA 需求而一併升級。
品質上來說，Akamai 在全球的點 (PoP) 夠密集 (差不多是有 ISP 機房就會放)，當初會選擇 Akamai 是為了敝公司在泰國與馬來西亞兩個地區的用戶，而 PMD 在這兩個地區的品質都還不錯。
在台灣也有好幾個點，但除非你買的產品線等級夠高 (i.e. 合約有保證 performance，像是 DSA)，不然平常不會分到台灣的點，以最近的情況來說是深夜才有機會指回台灣。
這是 Akamai DSD 的圖：
而這是 DSA 的圖：
可以看得出來 latency 的差異。
在 SLA 的部份，是目前少數有提供保證 100% availability SLA 的 CDN。
成本考量上，價錢是最硬的，但由於 CDN 這個領域競爭得很激烈，只要超過某一個 commit level 後有機會壓到跟 CloudFront 拼的價錢，也就是說，有經濟規模就有機會在台灣變成重點客戶而坐下來談價錢 (不確定多少，但 CloudFront 的第一個級距 10TB/month 應該是基本吧)。
另一方面，因為透過業務談價錢，會需要開會討論，所以對使用方的人力成本偏高。不過因為如此，台灣有 Akamai 辦公室與經銷商，稅務會比較好處理。(參考：「零壹科技正式代理Akamai 推展雲端優化服務解決方案」)
總結來說，適合已經有量，而且台灣是重要客群的公司。
再來講 EdgeCast。
EdgeCast 的功能比 Akamai 少很多，自從被 Verizon 買進去後就沒推出什麼比較有趣的產品了 (參考「Verizon 打算買下 EdgeCast...」)，感覺上是電信公司買來補產品線的啦，所以也不用太期待之後會有什麼新產品推出來...
比較特別的是 EdgeCast 跟 HiNet 有合作 (參考「EdgeCast 與 HiNet 合作...」)，所以也是少數在台灣有機房的 CDN 業者。在台灣的 PoP 據說是在高雄 HiNet 機房內：
另外 EdgeCast 有 Network Map 可以看在全球有哪些 PoP。
價錢上聽朋友說比 Akamai 低了不少，不過自己沒經手過無法確認。同樣是透過業務談，所以也有類似的人力與稅務優缺點。不過據說也可以直接 bypass 國內的業務，直接跟國外談，不過這樣搞境外稅務的問題就要自己解決了。
綜合來說，也是適合已經有量，由於沒有 SPDY 與 HTTP/2，就看 PoP 的點決定合不合用。
Amazon CloudFront 算是很多 startup 的第一嘗試，no commit 以及帳單在同一張可以省下不少功夫。
在 CloudFront 上分成三個不同等級的產品，通常下載用可以拿 Price Class 100 (只有北美與歐洲的 PoP)，而真正要加速用的再拿 Price Class All 用。
而功能面上，CloudFront 的功能說不定還比 EdgeCast 多，不過還是沒支援 SPDY 或 HTTP/2，所以基本上是靠台灣的 PoP 在撐 latency 的。而台灣的 PoP 據說在內湖：
價錢在官網上就擺出來給大家看了，比較大的缺點是不同區域是分開算錢的，不過是可以找台灣的經銷商談 commit level 包價錢啦，不過價錢還是很難談。
綜合來說，適合 startup 用。
CloudFlare 也是很多人問的一個選擇，不看流量價錢固定是賣點之一。
功能非常多，SSL certificate 涵蓋在所有產品內，另外也是目前少數支援 SPDY 的 CDN。技術上是走 Anycast 而非 GeoDNS dispatch。
HiNet 過去的品質爛到爆炸 (重點在於會 packet loss)，也常常是被 DDoS 的目標。台灣其他的 ISP 過去大多都是到日本機房，但 HiNet 會到香港機房，而 HiNet 的這條線路相當壅塞：
主要還是靠 SPDY 的能耐硬是把效能撐到「堪用」的程度，而 CloudFlare 遇到 DDoS 時就慘了。
價錢也是公開的，但以商用水準的品質來說，已經低到及格線以下了...
綜合來說，自己玩玩的東西還可以啦，任何商業性質的網站都不應該單獨用 (與其他 CDN 服務動態偵測服務搭配著用還加減可以用用)。所以目前看到用最多的服務就是內容農場 (Content Farm) 在用，為了節省頻寬與伺服器的負荷，不太在意品質。
最後補充在台灣有機房的 CDN 業者：(可能有漏)
前幾天在「TVBS 的 CloudFlare 客製化...」這邊提到這件事情，當天就先隨手測了一些東西。
首先是 CloudFlare 的服務 IP 是互通的，也就是說，我就算拿其他人的 CNAME mapping 來用，只要有送出對應的 Host: 或是 SNI (for HTTPS) 就會通，而 TVBS 當時的 IP address (以及網段) 對於台灣 HiNet 使用者剛好會導到美國機房，還算可以用。
另外 CloudFlare 有提供列表 (文字格式，一行一個網段)，分別是 IPv4 的 https://www.cloudflare.com/ips-v4 以及 IPv6 的 https://www.cloudflare.com/ips-v6。
所以就有幾種組合了，一種是寫 Google Chrome 的 extension 直接改 IP address，不過看了看 JavaScript APIs - Google Chrome 想不出來怎麼寫。
另外一個是先用 iptables 把這些網段的流量導去美國的 CloudFlare 機房。結果這時候發現 HiNet 到 TVBS 已經改回到香港機房了 orz
實際抓了一下發現 188.114.97.100 在巴西機房 (GRU 是 IATA 代碼)，就變成只是測試看看這有沒有用了：
$ curl -x http://188.114.97.100:80/ http://s.plurk.com/cdn-cgi/trace fl=42f16 h=s.plurk.com ip=114.32.152.63 ts=1441004146.723 visit_scheme=http uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 colo=GRU spdy=off
由於是自己機器出去的封包，不能用 PREROUTING 做，要用 OUTPUT 做：
iptables -t nat -A OUTPUT -d 190.93.240.0/20 -j DNAT --to-destination 188.114.97.100
然後再直接連到 s.plurk.com 就可以看到：
$ curl http://s.plurk.com/cdn-cgi/trace fl=42f16 h=s.plurk.com ip=114.32.152.63 ts=1441004011.195 visit_scheme=http uag=curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 colo=GRU spdy=off
不過巴西也太遠了點，而且不知道哪天這段 IP 又會被 anycast 進去... orz
Adobe 的 Typekit 宣佈之後的 embed code 預設就會是 HTTPS only：「Font loading update: All HTTPS, all the time」。
主要的原因是出自於最近發現的安全問題，攻擊者可以藉由字型處理的 security issue 攻擊，而導入 HTTPS 後可以降低這部分的風險：
We’ve made this change as a response to the recent vulnerabilities and exploits in the OpenType and TrueType font formats. A malicious attacker could use these vulnerabilities to modify a Typekit font while it is being transmitted from our servers to your browser. Serving fonts (and other resources) over HTTPS ensures that the communication channel between your browser and our servers is not compromised and fonts are delivered in a secure way.
就目前看起來，use.typekit.net 還是使用 EdgeCast 的 CDN 服務，在 HTTPS 上還是沒有 SPDY 或是 HTTP/2，對效能的影響還是要測試過才知道...
昨天的大新聞，CloudFlare 宣佈跟百度合作進入中國市場：「How We Extended CloudFlare's Performance and Security Into Mainland China」。
在「China network」這邊可以看到各種限制，首先是需要有牌 (ICP) 才能用：
CloudFlare customers that wish to serve traffic for their domains across the China network must possess a valid Internet Content Provider (ICP) license. An ICP license is a Chinese government issued license required to host or cache Internet content within mainland China. Learn more about how you can obtain an ICP license here.
另外是不支援 HTTPS：
For the moment the China network does not support HTTPS traffic (HTTP only). Support for SSL/TLS will be made available in the coming months.
目前只開放給 Enterprise 用戶：
Initially, the China network will be limited to Enterprise customers. Over time, as we are better able to operationalize the onboarding of customers, we hope to extend the benefits to all plan levels.
由於要 ICP 的關係，對於境外網站沒有太多幫助。另外也不確定是不是還是用 Anycast 技術，如果是的話就要煩惱某些網站的流量有機會被導到中國了。
Let's Encrypt 宣佈有新的進度了，已經可以從 Root Certificate 簽其他的 SSL Certificate 了：「Our First Certificate Is Now Live」。
測試的網站在 https://helloworld.letsencrypt.org/ 這邊，目前應該還是屬於不信任狀態。一旦 cross sign 或是被加到瀏覽器內，這個網站應該就會馬上生效了。
接下來會同時做幾件事情：
總算又聽到新的進度了...
在「Using testssl.sh」這邊看到「testssl.sh」這個工具。
需要新版的 OpenSSL 會掃的比較完整，不過看起來 Ubuntu 14.04 內建的就可以掃不少東西了 (當然還是少了 ChaCha20+Poly1305)。
Qualys 的「SSL Server Test」只能掃有開放給公開使用的站台，而這個工具就可以拿來掃內部網站了。
拿官方給的 screenshot 來看結果：
前幾天 nginx 釋出 1.9.5 版，支援 HTTP/2 (ngx_http_v2_module)：「NGINX Open Source 1.9.5 Released with HTTP/2 Support」。
不過預設是沒有編進去的，需要用 --with-http_v2_module 開起來：
This module is not built by default, it should be enabled with the --with-http_v2_module configuration parameter.
要注意的是，由於是透過 ALPN 實作，需要 OpenSSL 1.0.2 之後的版本：
Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed.
不過 PPA 的 NGINX Mainline 這邊還沒更新到 1.9.5，反正 SPDY 現在的佔有率還是比 HTTP/2 高，再等等吧...
Google 宣佈 Blogspot (Blogger) 將會支援 HTTPS：「HTTPS support coming to Blogspot」。
配合 2014 年 Google 就已經公佈的「HTTPS as a ranking signal」，算是整個 Google 的趨勢...
剛剛出的 Google Chrome 46 除了安全性更新外，還修改了在 Mixed Content 時的 HTTPS icon：「Simplifying the Page Security Icon in Chrome」。
官方的這張圖就給了不錯的解釋：
本來是用黃色三角形表示，現在直接變成跟 HTTP 一樣沒有 Secure Icon，這樣減少了使用者要了解的情況：
This change will reduce the number of page security states in Chrome from four to three.
而接下來還打算再減少：
In the long term, we hope that most sites on the internet will become secure, and we plan to reduce the icon to just two states: secure and not secure. The change announced in this post is a small step in that direction.
在「How is NSA breaking so much crypto?」這邊提到了 2012 年有文章說明 NSA 有能力解開部份的加密通訊，而後來 Snowden 所提供的資料也證實了這點：
In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a “computing breakthrough” that gave them “the ability to crack current public encryption.” The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand.
但在這之前一直都不清楚是怎麼解出來的，直到最近才猜測應該是 Diffie-Hellman 的強度以及實作問題：「Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice」。
而成果其實非常驚人，由於強度不夠以及實作問題，有相當可觀的數量是可被攻擊的：
We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We estimate that even in the 1024-bit case, the computations are plausible given nation-state resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024-bit group would allow passive eavesdropping on 18% of popular HTTPS sites, and a second group would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.
作者群給的建議有三個方向，一個是把長度加長到 2048 bits，另外一個是改用 ECDH，而最差的情況 (如果還是需要使用 1024 bits DH) 則是避免使用固定的 prime number。
KeyCDN 是目前幾個有支援 HTTP/2 的 CDN 其中一個，所以有這個數字可以看：「HTTP/2 Statistics: KeyCDN Report on HTTP/2 Distribution」。可以看到 HTTPS 流量中，HTTP/2 的流量已經超過 HTTP/1.1：
另外有個有趣的數據，是 Google Chrome 上 HTTPS 的比率比 HTTP 高出不少：
over the past year the number of HTTPS navigations in Chrome has grown by ~5% (up to ~63%): https://t.co/9fksNNOLdD pic.twitter.com/NVrZCjrMD2
— Ilya Grigorik (@igrigorik) October 13, 2015
其中 2013 年的突起據作者猜測是 Facebook 轉 HTTPS 化：「Secure browsing by default」，不過時間軸好像對不起來，也許要再找看看有什麼大型網站在那個時間點做了什麼事情...
IPFS (InterPlanetary File System)，或是被稱作 The Permanent Web。
起因在於目前 HTTP (Web) 在設計時是 1990 年代的想法，許多威脅在當時並不明顯。而到了現在，來自攻擊者的威脅與政府監控的威脅使得必須在 HTTP (Web) 上架構許多 workaround。
最知名的 workaround 就是 HTTPS 以及對應的 CA 架構了，前者因為 HTTPS 協定本身高度複雜，實作的單位經常出錯而產生安全漏洞。而後者靠著大量的稽核檢查來避免出問題，不過畢竟還是 workaround，常常會有一堆「誤發」的狀況發生。
另外 HTTP 發展到現在其實是去中心化「Decenteralized」的架構，政府單位可以抓著其中幾個結點就可以大量監控，而 IPFS 想要做到真正的分散式「Distributed」：
前陣子 IPFS 在 GitHub 上放出了 prototype 讓大家玩：「ipfs implementation in go.」，而最近有人把這個點子實作成 image hosting：「ipfs.pics」(一樣是放在 GitHub 上)，並且提供對應的網頁上傳介面：「Decentralized picture hosting in ipfs」。
我試著丟一張圖片上 ipfs.pics 後，得到的 hash 值是 QmRpNqK33gDDKdu8y6Wx5DQsuiJbsnwojNzH5nUwCpwoS9，也可以在 IPFS 看到這張圖：
來玩看看好了 :o
依照「Beta Program Announcements」這邊的指示去填單申請 Let's Encrypt 的 SSL certificate (先幫 home.gslin.org 申請)，等了好幾天，在剛剛收到信就弄了弄，還蠻順利就設好了。
可以看到 Let's Encrypt Authority X1 被 DST Root CA X3 簽名的情況，而後者已經被大多數瀏覽器所確認了：
首先是先把 letsencrypt client 拉下來：
$ git clone https://github.com/letsencrypt/letsencrypt
接著執行認證：
$ cd letsencrypt $ ./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly
執行時會先建立環境 (由於需要寫到 /etc/letsencrypt 裡面，會需要 root 或 sudo 權限)。
接下來會跳出一些畫面讓你設定，包括 hostname 以及聯絡資訊，再來就是認證的方式 (我是跳出使用 apache 或是 standalone web server)，由於我的 port 443 已經被 apache 吃掉，所以需要用 apache。
最後認證成功會出現：
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/home.gslin.org/fullchain.pem. Your cert will expire on 2016-02-02. To obtain a new version of the certificate in the future, simply run Let's Encrypt again.
有效期限 90 days，雖然裡面是講 fullchain.pem，但其實每個檔案都有拆開放，看一下 /etc/letsencrypt/live/home.gslin.org/ 路徑裡的檔案，設定對應的 cert/chain/key 應該還是比較習慣的作法。
官方目前的建議是 60 days 重新 renew 一次，也許可以設成 cron，每兩個月自動更新一次 (並且 reload apache)。
看到「sniffly」這個工具，可以利用 HSTS 資訊檢測逛過哪些網站，程式碼在「diracdeltas/sniffly」這邊可以找到：
Sniffly is an attack that abuses HTTP Strict Transport Security and Content Security Policy to allow arbitrary websites to sniff a user's browsing history. It has been tested in Firefox and Chrome.
測試網站則可以在這邊看到，作者拿 Alexa 上的資料網站來掃，所以熱門網站應該都會被放進去...
主要是利用 HSTS + CSP policy 的 timing attack (有逛過網站而瀏覽器裡有 HSTS 時的 redirect 會比較快，沒有逛過的時候會因為有網路連線而比較慢)：
Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial! If the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits Sniffly.
When an image gets blocked by CSP, its onerror handler is called. In this case, the onerror handler does some fancy tricks to time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image's domain before. If it's on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn't visited the image's domain.
由於這個技巧，HTTPS Everywhere 必須關閉才會比較準確。
在「Creating An Amazon API Gateway With aws-cli For Domain Redirect」這邊看到用 Amazon API Gateway 重導整個網域的方法。一般的做法是用 Amazon S3 (用 web hosting 重導) + Amazon CloudFront (for HTTPS) 堆出來，事實上這個方法成本也比較低，這篇文章只是示範怎麼用而已：
I’m not saying the API Gateway method is better than using S3 plus CloudFront for simple hostname redirection. In fact, it costs more (though still cheap), takes more commands to set up, and isn’t quite as flexible in what URL paths get redirected from the source domain. It does, however, work and may be useful as an API Gateway aws-cli example.
可以從中間學到一些東西，尤其是可以看到如何使用 aws-cli 操作 Amazon API Gateway 的部分...
Dell 在出廠的電腦上裝了 Root Certificate (eDellRoot)，並且附上 Private Key：「Dell apologizes for HTTPS certificate fiasco, provides removal tool」。
出自 Reddit 上 rotorcowboy 的爆破：「Dell ships laptops with rogue root CA, exactly like what happened with Lenovo and Superfish」。
Dell 官方的正式回應：「Response to Concerns Regarding eDellroot Certificate」。
由於有 Private Key，有人架了一個檢測網站，在「Are you affected by the eDellRoot-Certificate issue?」這邊可以確認電腦是否中獎。
大家都超愛搞這套的 XDDD
Amazon 之前放 s2n 出來當作 TLS protocol 的方案，於是就有人摸出東西來：「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。
即使是經過外部資安檢證，仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery：
At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.
攻擊分成兩個階段：
Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.
最後還是酸了一下 Amazon：
It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.
Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。
![[SweetSub&LoliHouse] 小书痴的下克上 领主的养女 / Honzuki no Gekokujou S04 - 05 [WebRip...](http://files.seeusercontent.com/2026/04/08/dRa8/Honzuki.jpg)
