Home » Archive by category "Privacy" (Page 4)

Google 開放 .app 註冊,是個 HSTS Preload TLD

Google 宣佈了 .app 的網域將開放註冊:「Introducing .app, a more secure home for apps on the web」。

整個 .app 網域都已經被 Google 設定 HSTS Preload 了:

A key benefit of the .app domain is that security is built in—for you and your users. The big difference is that HTTPS is required to connect to all .app websites, helping protect against ad malware and tracking injection by ISPs, in addition to safeguarding against spying on open WiFi networks. Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way.

如果要註冊下來,開發的時候得注意...

台固的網域名稱轉出到 Gandi,以及 GDPR...

看到 othree 的「TFN 域名轉出」這篇,剛好前陣子把 git.tw 也轉到 Gandi 上,也遇到一樣的問題... 以往的經驗是網域註冊商會提供 authorization code,但台固的系統是讓你自己輸入,懂這點後就好處理了:

所以結論是,TFN 域名轉出時要輸入的移轉中密碼其實就是給使用者自訂 authorization code,而且還有個蠻短的長度限制 XD

另外是因為 GDPR 所以看不到 whois 資料了,像是 othree 提到的 markdown.tw

gslin@GSLIN-HOME [~] [14:32/W2] whois markdown.tw
Domain Name: markdown.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2020-03-07 (YYYY-MM-DD)
   Record created on 2011-03-07 (YYYY-MM-DD)

   Domain servers in listed order:
      ns-171-a.gandi.net      
      ns-114-b.gandi.net      
      ns-144-c.gandi.net      

Registration Service Provider: GANDI SAS

我自己的 git.tw 也是:

gslin@GSLIN-HOME [~] [14:34/W2] whois git.tw
Domain Name: git.tw
   Domain Status: clientTransferProhibited
   Registrant:
      
      Not displayed due to GDPR
      FR

   Administrative Contact:
      Not displayed due to GDPR

   Technical Contact:
      Not displayed due to GDPR

   Record expires on 2019-05-23 (YYYY-MM-DD)
   Record created on 2008-05-23 (YYYY-MM-DD)

   Domain servers in listed order:
      kristin.ns.cloudflare.com      
      paul.ns.cloudflare.com         

Registration Service Provider: GANDI SAS

這樣就有點麻煩了,以後如果要聯絡的話只剩下 DNS 內的 SOA record

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域,現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了:「Custom domains on GitHub Pages gain support for HTTPS」:

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準,也稱為 ANAME,有些 DNS provider 有支援,主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record,則是需要更新 IP 位置:

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項:

以前 HTTPS 還得自己弄伺服器處理,現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構,IP 是 Fastly 的,所以應該是跟 Fastly 合作,但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證,或是 Fastly 提供 Port 80/443 的 TCP Proxy?

Intel 最新的 Ice Lake 系列對 AES 的加速

Twitter 上看到這篇,講 Intel 推出新的指令集,對 AES 的加速效果:

進去看以後發現是講四月推出的 Ice Lake,在上面新增的 VPCLMULQDQ 指令對效能的幫助:

The introduction of the processor instructions AES-NI and VPCLMULQDQ, that are designed for speeding up encryption, and their continual performance improvements through processor generations, has significantly reduced the costs of encryption overheads.

而他們發表出來的數據說 AES-GCM 的效率直接從 ~23 cycles/byte 降到 0.64 cycles/byte,大約是 35 倍的改進?

More and more applications and platforms encrypt all of their data and traffic. As an example, we note the world wide proliferation of the use of AES-GCM, with performance dropping down to 0.64 cycles per byte (from ~23 before the instructions), on the latest Intel processors.

就算不是 AES-GCM,而是其他的 AES 相關演算法,也是三倍以上的改善:

這效能差異...

Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊:

現在要看這個資訊比較麻煩,之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來,Let's Encrypt 上個月也支援 SCT 了:「Engineering deep dive: Encoding of SCTs in certificates」,不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例),但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的,沒看到 SCT 資訊... 要等下一次的 renew 了。

HTTPS Everywhere 改變更新 Ruleset 機制,變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件,裡面有 Ruleset,會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS,這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況,以及網站本身有支援 HTTPS 但沒有設定 HSTS 時,在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時,包在軟體內一起更新。這樣的缺點是更新速度比較慢,但好處是不需要伺服器端,而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本,以加速 Ruleset 更新的速度:「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助:

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的,也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

Cloudflare 推出在 HTTPS 下的壓縮機制

在 TLS (HTTPS) 環境下基本上都不能開壓縮,主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出,像是 CRIMEBREACHTIMEHEIST (沒完結過...),而因為全面關閉壓縮,對於效能的影響很大。

Cloudflare 就試著去找方法,是否可以維持壓縮,但又不會洩漏 secret token 的方式,於是就有了這篇:「A Solution to Compression Oracles on the Web」。

重點在於 Our Solution 這段的開頭:

We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.

透過 regex 判斷那些東西屬於 secret token,然後對這些資料例外處理不要壓縮,而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降,但不透漏 secret token。然後因為這個想法其實很特別,沒有被實證過,所以成立了 Challenge Site 讓大家打:

We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.

這個方向如果可行的話,應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token,這樣一來就更能確保因為漏判而造成的 leaking...

Qubes OS 4.0 推出

也是個放在 tab 上一陣子的連結,Qubes OS 推出了 4.0 版:「Qubes OS 4.0 has been released!」。這個作業系統的副標蠻有趣的,不是「絕對安全的作業系統」,而是用了 「reasonably」這樣的描述:

A reasonably secure operating system

主要是透過虛擬機隔離,但實做了常見會因為虛擬機而被擋下的功能,像是讓你可以直接剪下貼上。而界面上也是儘量做成無縫,像是這張 screenshot 就可以看到三個環境,但儘量給出視窗的感覺,而非 VM 的感覺:

有機會重灌的時候再說好了,系統轉移好累... Orz

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務:「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」,主打項目是隱私以及效能。

然後因為這個 IP 的特殊性,上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去):

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNSOpenDNS 比較),可以看到平均速度快不少:

在台灣的話,HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency:

可以比較同一台機器對 168.95.1.1 的反應速度:

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種,不透過 PPPoE,直接設定 IP address 使用 bridge mode 連線的使用者),兩者的 latency 就差不多,不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/,理論上不會發 IP-based 的 SSL certificate 才對?不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update:查了資料發現是可以發的,只是大多數的 CA 沒有提供而已...

TLS 1.3 進入 Proposed Standard

最近蠻熱的一個新聞,TLS 1.3 的 draft-ietf-tls-tls13-28.txt 進入 Proposed Standard 了 (在「draft-ietf-tls-tls13-28 - The Transport Layer Security (TLS) Protocol Version 1.3」這邊可以看到歷史記錄):「Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)」。

沒意外的話這就會是最終版本了。如果要看 TLS 1.2 與 TLS 1.3 的差異,看維基百科上的 Transport Layer Security - TLS 1.3 會比較清楚。

大家等很久了... 像是 OpenSSL 1.1.1 其實一部分也是在等 TLS 1.3 正式推出:(出自「Using TLS1.3 With OpenSSL」)

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the meantime the OpenSSL git master branch contains our development TLSv1.3 code which can be used for testing purposes (i.e. it is not for production use).

主要還是期待非 NSA 派系的 cipher (其實幾乎都是 djb 的戰果) 與 1-RTT handshake,後續等 TLS 1.3 變成 Standard Track 應該就會被各家瀏覽器開預設值了...

Archives