Merge pull request #6 from certtools/main

merge

Author: aaronkaplan

mkdocs.yml

@@ -31,7 +31,10 @@ nav:
   - References: references.md
 
 
-theme: readthedocs
-
-
-
+theme: material
+plugins:
+  - to-pdf:
+      author: L. Aaron Kaplan, Sebastian Wagner
+      cover_title: Remaining weaknesses in ECH
+      cover_subtitle: TODO
+      output_path: build/document.pdf

report/attacks/correlations.md

@@ -1,11 +1,11 @@
 # Correlations on traffic patterns
 
-Various existing research on this
+There is extensive research on this topic. Traffic corrections do not depend on unencrypted SNI, so ECH will not have any effect on this.
 
-"Encrypted (Network) Traffic Classification"
+We refer to existing materials on the subject of "Encrypted (Network) Traffic Classification".
+Examples include:
 
 * <https://www.sciencedirect.com/science/article/pii/S2090447923002502>
 * <https://ieeexplore.ieee.org/document/8622812>
 * <https://www.mdpi.com/2073-8994/13/6/1080>
 
-Does *not* depend on unencrypted SNI!

report/attacks/legal.md

@@ -0,0 +1,5 @@
+# By Legal Means
+
+As discussed in the section [Censorship](../censorship.md), some countries, such as Russia, already use legal measures to enforce censorship.
+Others are expected to adopt similar practices in the near future.
+ECH is unable to influence or bypass these restrictions.

report/attacks/metadata.md

@@ -1,9 +1,22 @@
-## Explicit metadata
 
-What is left in the protocols?
+# De-anonymization by Metadata
+## Explicit: ECH usage
 
-## Implicit metadata
+The ECH standard appears to be well designed minimizing metadata.
 
-### CRL
+Only the usage of ECH itself is left as a suspicious marker, drawing the attention of censors to possibly interesting traffic. See [Censorship](../censorship.md) for more information.
 
-http usage
+## Implicit: DNS queries
+
+As the [Deployment Overview](../deployment/overview.md) outlines, clients request the ECH configuration via DNS during the initial setup and for subsequent refreshes.
+Since the recommended lifespan for the keys is one hour, clients must update their ECH keys at least once every hour.
+
+Browsers utilize the same DNS-over-HTTPS (DoH) server across all installations, which presents several risks:
+
+- Single point of failure
+- Single point of truth
+- Central point for de-anonymization attacks
+
+These risks can be mitigated by using decentralized DoT, as with Do53, instead of central DoH servers.
+
+Further, the WKECH standard could be used by browsers for key refreshment, reducing the metadata at DNS server operators.

report/censorship.md

@@ -1,21 +1,56 @@
 # Censorship
 
-## RU
+This section provides an overview of the regions currently use SNI for censorship purposes, those blocking ECH usage, and countries that may soon implement similar measures.
 
-* Russia disallowing CDNs in order to block ECH: <https://github.com/net4people/bbs/issues/417>
-  * <https://therecord.media/russia-blocks-thousands-of-websites-that-use-cloudflare-service>
+For a comprehensive analysis of internet censorship practices around the globe, see [A Survey of Worldwide Censorship Techniques](https://www.ietf.org/archive/id/draft-irtf-pearg-censorship-10.html).
 
-## CN
+## Russia
 
-- Not blocking ECH currently
-- Do they need to block ECH at all?
-	- Do they control the clients?
-	- Do they need to block anything because they have other means (Social Credits)?
+Russia is know to block ECH traffic:
 
-## KR
+- <https://github.com/net4people/bbs/issues/417>
+- <https://therecord.media/russia-blocks-thousands-of-websites-that-use-cloudflare-service>
 
-- Blocking by SNI:
-	- <https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/>
-	- <https://www.technadu.com/south-korea-extend-site-blocking-snooping-sni/58125/>
-- Workaround: VPNs and ESNI
-	- ESNI was removed from browses, ECH follows but harder to adopt
+The government uses SNI information as a method for implementing censorship measures. Furthermore, foreign content delivery networks (CDNs) are prohibited, enforces the use of domestic service providers. This keeps the control over data transmission and access national.
+
+## China
+
+The Great Firewall (GFW) of China is one of the most extensive censorship implementation in the world and reports indicate that China is blocking ESNI and ECH.
+
+The GFW utilizes SNI alongside other technologies enforce content blocking.
+
+Sources:
+
+- <https://gfw.report/blog/gfw_esni_blocking/en/>
+- <https://github.com/net4people/bbs/issues/43>
+
+## South Korea
+
+South Korea uses SNI to restrict access to specific online resources.
+
+While people in South Korea could previously used ESNI as a workaround to bypass these restrictions, browser updates have removed support for ESNI, complicating efforts to maintain online privacy.
+
+As laid out in [Incenctives](deployment/incentives.md), the affected industries have also commercial interest in using ECH.
+
+It is yet unclear how South Korea's authorities will react to ECH.
+
+- <https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/>
+
+- <https://www.technadu.com/south-korea-extend-site-blocking-snooping-sni/58125/>
+
+## Kazakhstan
+
+Kazakhstan uses a national Certificate Authority (CA) to intercept and decrypt TLS traffic.
+In this case, ECH offers no benefit at all, as the central decyption of all traffic serves all counter-measures ineffective.
+
+Sources:
+
+- <https://censoredplanet.org/kazakhstan>
+
+## Others
+
+Several countries use unencrypted SNI for filtering and blocking websites, including:
+
+Cuba, Egypt, India, Iran, Saudi Arabia, Syria, Turkey, Turkmenistan, United Arab Emirates, Vietnam
+
+Once ECH plays a relevant role, we expect that these countries block ESNI/ECH to ensure the effectiveness of their measures.

report/clients/browsers.md

@@ -1,39 +1,43 @@
-# Browsers
+# Browsers and ECH
 
-browsers are permissive
-if dns is misconfigured, browser tries without ECH
+Modern web browsers are notably permissive toward emerging standards, often prioritizing user functionality over enforcing new security features if the potential impact is too disruptive. With their quick adoption of new technologies and fast release cycles, they effectively serve as experimental platforms for evaluating and implementing new protocols in real-world environments.
 
-explore how FF and other browsers behave with famility safety software exactly, so far not tested
+The leading browsers Firefox, Chrome, Edge and further Brave, Opera, Vivaldi adopted DoH as their default setting, reverting back to Do53 should a DoH connection fail to establish. Such failures can arise from active downgrade attacks, where malicious entities intercept and manipulate traffic. Consequently, the implementation of ECH can be thwarted if an attacker holds sway over any part of the network path between the user and the intended target.
 
-## Non-pure-HTTPS traffic
+For the implementation of ECH, attention must not only be paid to pure HTTPS traffic but also to other communication channels such as WebRTC and network proxies, as neglecting ECH on these channels can introduce ways for de-anonymization.
 
-### Jitsi
+## Browsers' Policy Enforcement Power
 
-- UDP/10000 Jitsi video bridge
-- UDP/3478 STUN server (coturn)
-- TCP/5349 fall-back connection for video/audio communication (in case the UDP connection did not work)
-- TCP/443 (HTTPS) only for the UI, protected with ECH by default
+In the past, Browsers and the CA/Browser forum have repeatedly shown that they can enforce new policies towards network and website operators, pushing them to fast adjustments to not risk their website's reputations, such as:
 
-### Network Proxy
+- Starting in 2015, Browsers gradually marked unencrypted HTTP connections as unsafe, pushing all website operators to use HTTPS.
+- Previous to 2011, certificate lifetimes of up to 10 years were allowed by standards and accepted by browsers. Since 2020, a year is the maximum allowed lifetime. Discussions on further reductions are ongoing.
+- Other examples include: Deprecation of SHA-1 (2014-2017) and Deprecation of RSA Keys (since 2010), Distrust of CAs (Symantec, 2017–2018), Mixed Content Blocking, [Requirements to CAs](https://cabforum.org/baseline-requirements/) such as Certificate Transparency, OCSP, `SubjectAltName`, Domain Validation Methods, Deprecation of Certificates for Internal Server Names (2011-2016), Deprecation of TLS protocols and cipher suites
 
-SOCKS, HTTPS
+The reasons for this effectiveness lie in the huge market share of a small number of browsers and, on the operators' side, the high reputation risk: Website operators simply cannot afford security warnings or site breakage.
 
-### OCSP and CRL
+These policies are increasingly getting tighter, pushing the operators to more automation and more complex environments. This, in turn makes the operation less efficient pushing many of them to centralized service operators. This counteracts the original intention of a decentralized Internet.
 
-Downloaded via HTTP but signed by the CA
-Blocking the access to the lists is possible with packet inspection due to the traffic being unencrypted
-Browser soft-fail by default
-OCSP is dead: <https://letsencrypt.org/2022/09/07/new-life-for-crls/>
-Work ongoing to fix these issues
+**Therefore, we emphasize that the CA/Browser forum must not use its power to enforce ECH** because it pushes users to DoH.
 
-### QUIC and SPDY
+## DoH server oligarchy
 
-should work
+Firefox and Edge use Coudflare's DoH server, and Chrome uses Google's DoH server.
+Just two DoH servers provide DoH services to the majority of browser users.
+This imbalance implies various problem areas:
 
-## Firefox
+- Privacy: Despite their emphasis that they won't save the query data, these policies can change at any time. Users are locked into a trust dependency without opt-in.
+- Jurisdiction and Geopolitics: The DoH servers are operated by companies in a single country. Their legal system can force them to share the query data at any time, impacting users **worldwide** without any possibility for them to notice.
+- Market dominance: Just two operators control the majority of all DoH traffic. This creates a huge market dominance. In the future, this can lead to them effectively taking over the role of Domain registrars.
 
-timing issue FF: no new information
+As DoH is required for ECH, these problems are worsened by ECH.
+ECH aims to defend users' privacy, but its dependency on DoH thwarts this goal.
 
-### Deliberately disabled
+## OCSP and CRL
 
-The Interop report mentions that ECH is disabled deliberately when local interception software is detected, and also with ISP- or state-level censorship
+Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRL) are core components in the validation of digital WebPKI certificates. The data is typically transmitted over HTTP but verified through signing by the Certificate Authority (CA).
+Access to these lists can be obstructed through packet inspection due to the unencrypted nature of the traffic. Browsers generally employ a soft-fail approach for CRL validations by default, meaning the information about a revoked certificate may not reach the client. If an adversary has the capability to interfere at this stage, they may effectively disrupt other, more important connections as well.
+
+OCSP has recently been called into question and may be nearing obsolescence: <https://letsencrypt.org/2022/09/07/new-life-for-crls/>. As a result, the CRLs' importance increases again.
+
+This study found no relevant interplay of ECH on CRL and OCSP mechanisms.

report/clients/iot_and_libs.md

@@ -0,0 +1,21 @@
+# Libraries and Devices in the Internet of Things
+
+## Internet of Things
+
+The Internet of Things (IoT) is formed of a vast range of device types that typically have a significantly longer lifecycle compared to traditional internet-connected devices like clients and servers. Their applications can range from huge medical imaging tools to tiny gadgets. The extended lifespan and - in many cases - great certification efforts lead to variable software update cycles. When a vulnerability is identified within the software stack, the challenge of rolling out the necessary updates becomes substantially more complex.
+
+Moreover, numerous IoT devices lack automatic update capabilities at all, and in some instances, these updates are not feasible at all. The underlying software quality often suffers as well, driven by constraints related to financial resources and the sheer scale of development. Paradoxically, due to the critical nature of maintaining device security amid the difficulties associated with updates, the quality of the software must actually be higher to mitigate these risks effectively beforehand.
+
+## Libraries and Packagin
+
+TLS libraries that are often package by other software of provided by [package management systems](https://en.wikipedia.org/wiki/Package_manager).
+They might also face a similar challenge as IoT devices, but to a much smaller extent.
+Operating system providers for are keen on stability, new features are often released in batches as major/minor releases. For server systems these span can in practice be five years or more.
+The percentage of early adopters will likely be very small, and only viable for those with strong incentives.
+
+## Command Line Tools
+
+Often settings for TLS configuration can only be enabled by less known obscure command-line flags.
+Therefore, good default values for ECH are crucial.
+
+Otherwise, they can impose a side-channel leaking domain names leading to de-anonymization.

report/clients/tor.md

@@ -1,9 +1,9 @@
 # TOR Network
 
 Currently, Encrypted ClientHello (ECH) is not supported on the TOR network, primarily because the Firefox foundation mandates the use of DNS over HTTPS (DoH) for ECH functionality, while TOR disables DoH in order to uphold user privacy.
-TOR’s architecture is designed to enhance security and privacy, which mitigates the necessity for the additional layers that DoH and ECH provide. By operating through a decentralized network of volunteer-run relays, TOR ensures that user data remains obscured from potential surveillance.
-Contrary to Do53 and DoH, TOR employs an alternative approach, utilizing DNS over the TOR network and subsequently through the exit node.
-TOR inherently addresses the concerns that both DoH and ECH aim to resolve, particularly through its TOR onion services.
+TOR’s architecture is designed to enhance security and privacy, which mitigates the necessity for the additional layers that DoH and ECH provide. For more information how TOR protects their users' privacy, please refer to the [TOR website](https://support.torproject.org/censorship/).
+Contrary to DoT and DoH, TOR employs an alternative approach, utilizing DNS over the TOR network and subsequently through the exit node.
+TOR addresses the concerns that both DoH and ECH aim to resolve, through its TOR onion services.
 
 - Detailed explanation on TOR's non-usage of DoH can be found here: <https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/6GDO7CYEFIKID7QQCRVYVFNIVETWWWWY/#6ZBFGNSRPWRCEO7PVPSHHVLAOGF7KN3C>
 - Discussion on DNS over HTTPS (DoH) in TOR: <https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30753>