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

Let's Encrypt 的 Embed SCT 支援

翻到 Let's EncryptUpcoming Features 時看到:

Embed SCT receipts in certificates
ETA: February, 2018

對 Embed SCT 不熟,所以查了查這個功能。

這指的是在簽發 SSL certficiate 後,把資料丟給 Certificate Transparency (CT) 伺服器後,伺服器會提供 signed certificate timestamp (SCT);而這個資料放到 SSL certificate 內叫做 Embed SCT:(出自 CT 的 FAQ)

What is an SCT?
An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

當使用 ECC 時會小於 100 bytes:

How big is an SCT?
SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

這樣才能試著解釋前幾天提到要拔掉 HPKP 的事情:「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」,也就是為什麼他們是提 CT 解,而不是 DNS CAA 解...

不過我記得 CT server 可以自己架自己 submit 不是嗎?後來有另外規定一定要用第三方的嗎?這樣又很怪...

紐約時報網站上 Tor 的 Hidden Service (i.e. Tor Onion Service)

紐約時報官方把整個站台放到 TorHidden Service 上了:「The New York Times is Now Available as a Tor Onion Service」。

而且也買了 SSL certficiate:

The address for our Onion Service is:


The Times is dedicated to delivering quality, independent journalism, and our engineering team is committed to making sure that readers can access our journalism securely. This is why we are exploring ways to improve the experience of readers who use Tor to access our website.

Google Cloud Platform 的 DLP API

在「New ways to manage sensitive data with the Data Loss Prevention API」這邊提到三月的時候就推出了 DLP API (在「Discover and redact sensitive data with the Data Loss Prevention API」這邊提到的),不過沒什麼印象:

The Data Loss Prevention (DLP) API, which went beta in March, can help you quickly find and protect over 50 types of sensitive data such as credit card numbers, names and national ID numbers.



美國的電信商提供 API,讓第三方透過 IP 就可以知道你的真實身份

前陣子的報料,美國的電信商提供 API 給第三方,讓第三方可以用 IP address 查出你的真實身份:「Want to see something crazy? Open this link on your phone with WiFi turned off.」,像是這樣:

These services are using your mobile phone’s IP address to look up your phone number, your billing information and possibly your phone’s current location as provided by cell phone towers (no GPS or phone location services required).

目前所有的網站都已經被下架了,但可以從當時的截圖看到有多少資訊。AT&T 的新聞稿在「AT&T Helps Businesses Improve Mobile Transaction Security with New Mobile Identity API Toolkit」,新聞稿沒被下掉我猜可能是因為上市公司受法令限制的關係?


But what these services show us is even more alarming: US telcos appear to be selling direct, non-anonymized, real-time access to consumer telephone data to third party services — not just federal law enforcement officials — who are then selling access to that data.

而且作者在 GitHub 上看到有程式碼針對韓國電信商提供的 API 呼叫,所以韓國也有類似服務:

I found what looks like a third-party API implementation for a Korean Danal API on GitHub. The author wrote the code for South Korean telcos, so there may be differences with US carriers. The query parameters in the HTTP requests are similar to what I remember seeing in the Danal demo. It’s unclear from my reading of the code whether or not this API requires operation inside of e.g. a Danal Inc. hosted-iframe for identity confirmation. The diagram on page 4 of this documentation describing the Korean “Danal Pay” service appears to show the client interacting with the customer’s servers only.


Windows 將引入 TruePlay,推出作弊偵測的 API

在「Windows now includes gaming cheat detection at the system level」這邊看到微軟將會引入 TruePlay (然後跟 Sonostrueplay 衝名 XDDD) 作弊偵測機制。


As Microsoft notes, "to protect customer privacy, no data is shared or transmitted until permission is granted," and no information is sent until "processing has determined cheating is likely to have occurred."

這不是把人當傻子嗎,遊戲一開始就會要求你同意才能玩啊,所以資料一定會送出的啊... 而且 TruePlay 變成作業系統的標準配備後,作弊程式就會找 workaround 才會推出 :o

Android 將測試 DNS over TLS

從「Android getting "DNS over TLS" to prevent ISPs from knowing what websites you visit」這邊看到的報導,原
文在「Android getting “DNS over TLS” support to stop ISPs from knowing what websites you visit」這邊可以看到。

It appears that “DNS over TLS” support is being added to Android, according to several commits added to the Android Open Source Project (AOSP). The addition in the Android repository shows that a new setting will be added under Developer Options allowing users to turn on or off DNS over TLS. Presumably, if such an option is being added to Developer Options, then that means it is in testing and may arrive in a future version of Android such as version 8.1.

這邊用的應該是 RFC 7858 的「Specification for DNS over Transport Layer Security (TLS)」,已經是 Standards Track 了。預設使用 TCP port 853:

By default, a DNS client desiring privacy from DNS over TLS from a particular server MUST establish a TCP connection to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over TLS.

而且建議如果另外定義的話,不要用 port 53:

This recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks.

另外也說明了在 port 853 上禁用明文傳輸:

DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages.

另外一個還在發展的標準是 Cisco 的人推出的「DNS over Datagram Transport Layer Security (DTLS)」,走的是 UDP port 853,不過看起來因為 stateless 的特性,需要考慮比較多問題... (尤其這類服務常配合 anycast)

不過即使將 DNS query 保護起來,TLS 本身還是會透漏 hostname 的部份 (因為 SNI 的關係),所以就 privacy 面向考量的話,沒有實質的意義... 主要還是考慮被竄改的問題?但如果是這樣的話,目前 TLS 連線本身就已經有這樣的保護了?暫時沒想到可以解什麼實際的問題...

ROCA:Infineon Technologies 的 RSA 實做問題

最近的另外一個大包,不過這包是 Infineon Technologies 在實做 RSA 算法時的問題,倒不是 RSA 算法本身有問題。之所以會「大」是因為有太多人用了:「ROCA: Vulnerable RSA generation (CVE-2017-15361)」。

起因於 Infineon Technologies 在產生 key 時的組合有限,於是要猜測的 keyspace 小很多。

以研究者的估算,可以看出 CPU year 都被大幅減少了,都是屬於「可行」的範圍:

The time complexity and cost for the selected key lengths (Intel E5-2650 v3@3GHz Q2/2014):

512 bit RSA keys - 2 CPU hours (the cost of $0.06);
1024 bit RSA keys – 97 CPU days (the cost of $40-$80);
2048 bit RSA keys – 140.8 CPU years, (the cost of $20,000 - $40,000).

而且這邊是用 CPU year 估算,如果考慮 FPGA 加速計算,應該會短更多...


2nd of November 2017 - Presentation of all details at the ACM CCS conference (to come)
16th of October 2017 - The initial version of the public disclosure published
May to October 2017 - Cooperation with the manufacturer and other affected parties to help evaluate and mitigate the vulnerability
1st of February - The vulnerability disclosed to Infineon Technologies AG
End of January - The vulnerability found

過一陣子就會去 conference 上報告了...

CircleCI 的隱私問題

作者看 CircleCI 網站時發現的問題:「CircleCI trusts 8 analytics companies with your source code and API tokens」。

CircleCI 網站引用了這八個網站的 javascript:

  • Pusher
  • Intercom
  • Launch Darkly
  • Amplitude
  • Appcues
  • Quora (??)
  • elev.io
  • Optimizely

有些有很明顯目的而且也夠大,但有些就沒聽過了... 不過照 BuiltWith 上分析的資料「circleci.com Technology Profile」,遠超過這些啊 XDDD

可以看到 GitHub 站上只引用了 Facebook (不過這是哪邊出現的啊?),另外因為使用 Fastly 的 CDN 服務,所以 Fastly 也是屬於 GitHub 的信任名單;這兩家都算夠大的 vendor:「github.com Technology Profile」。

Travis CI 則是 Google Analytics 與 Fastly,也是兩家夠大的 vendor:「travis-ci.com Technology Profile」。



在「California bosses can no longer ask you about your previous salary」這邊看到的消息。繼「麻州立法禁止詢問前一份工作的薪資」與「紐約市也將禁止雇主詢問薪資」後,加州也加入了這個行列。

The salary privacy bill, was enacted by Gov. Jerry Brown on Thursday, Oct. 12, at a celebratory signing ceremony at Women’s Empowerment, a Sacramento nonprofit for homeless women. He was surrounded by members of the California Legislative Women’s Caucus.

法案將於 2018 年生效:

The salary privacy bill takes effect on January 1, 2018.

DHS 要求郵件系統都必須使用 STARTTLS、DMARC,並且全面禁用 RC4 與 3DES

Twitter 上看到 18F 貼了 DHS 的新規定:「Enhance Email and Web Security」。

郵件系統的部份,要求要有 STARTTLS,並且設定 SPFDMARC。另外禁用 SSLv2 SSLv3,以及 RC43DES

網站的部份,則是要求 HTTPS 以及 HSTS。另外也與郵件系統一樣禁用 SSLv2、SSLv3,以及 RC4 與 3DES。

不只 18F 一個單位在推動,這樣整體的速度才會加快...