├── .gitignore ├── Makefile ├── README.md ├── draft-muffett-same-origin-onion-certificates.md ├── readme-original.md ├── revoked-onions.png └── text ├── draft-muffett-same-origin-onion-certificates.basic.html ├── draft-muffett-same-origin-onion-certificates.basic.md ├── draft-muffett-same-origin-onion-certificates.html ├── draft-muffett-same-origin-onion-certificates.txt └── draft-muffett-same-origin-onion-certificates.xml /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | NAME=draft-muffett-same-origin-onion-certificates 2 | DIR=text 3 | 4 | all: $(DIR)/$(NAME).txt $(DIR)/$(NAME).html 5 | 6 | push: all 7 | git push 8 | 9 | $(DIR)/$(NAME).html: $(DIR)/$(NAME).xml 10 | ( cd $(DIR) && xml2rfc --html --v3 $(NAME).xml ) 11 | 12 | $(DIR)/$(NAME).txt: $(DIR)/$(NAME).xml 13 | ( cd $(DIR) && xml2rfc --text --v3 $(NAME).xml ) 14 | 15 | $(DIR)/$(NAME).xml: $(NAME).md 16 | mmark -markdown $(NAME).md >$(DIR)/$(NAME).basic.md 17 | mmark -html $(NAME).md >$(DIR)/$(NAME).basic.html 18 | mmark $(NAME).md >$(DIR)/$(NAME).xml 19 | 20 | clean: 21 | rm -f *~ 22 | rm $(DIR)/* 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Same Origin Onion Certificates 2 | 3 | * [same-origin-onion-certificates](text/draft-muffett-same-origin-onion-certificates.txt) (TXT) 4 | * [same-origin-onion-certificates](draft-muffett-same-origin-onion-certificates.md) (Source Markdown) 5 | * [same-origin-onion-certificates](text/draft-muffett-same-origin-onion-certificates.xml) (Generated XML) 6 | * [same-origin-onion-certificates](text/draft-muffett-same-origin-onion-certificates.html) (Generated HTML from XML) 7 | * [same-origin-onion-certificates](text/draft-muffett-same-origin-onion-certificates.basic.md) (Generated MD from MD) 8 | * [same-origin-onion-certificates](text/draft-muffett-same-origin-onion-certificates.basic.html) (Generated HTML from MD) 9 | * [Google Doc: Draft Text Discussion, August 2019](https://docs.google.com/document/d/1xE5eaDMiOKphDxijK9tfIWHUB-h-fTG8tb3laofXLSc/edit?usp=sharing) 10 | * [Original Proposal Text, Deprecated August 2019](readme-original.md) 11 | * [Daily Swig: How Tor can enable verification with DV certs, March 2019](https://portswigger.net/daily-swig/how-tor-can-enable-verification-with-dv-certs) 12 | 13 | ## Notes 14 | 15 | * [markdown syntax](https://mmark.miek.nl/post/syntax/) 16 | * [writing-internet-drafts-in-markdown](https://github.com/danyork/writing-internet-drafts-in-markdown/tree/master/example-mmark) 17 | -------------------------------------------------------------------------------- /draft-muffett-same-origin-onion-certificates.md: -------------------------------------------------------------------------------- 1 | %%% 2 | title = "Same Origin Onion Certificates" 3 | abbrev = "sooc" 4 | category = "info" 5 | docName = "apparently this tool demands a doc name but does not use it" 6 | ipr ="trust200902" 7 | area = "Internet" 8 | workgroup = "Transport Layer Security" 9 | keyword = ["tor", "onion", "tls", "ssl"] 10 | 11 | [seriesInfo] 12 | status = "informational" 13 | name = "Internet-Draft" 14 | value = "draft-muffett-same-origin-onion-certificates-00" 15 | stream = "IETF" 16 | 17 | [[author]] 18 | initials="A." 19 | surname="Muffett" 20 | fullname="Alec Muffett" 21 | organization = "Independent" 22 | [author.address] 23 | email = "alec.muffett@gmail.com" 24 | %%% 25 | 26 | .# Abstract 27 | 28 | Onion networking [@RFC7686] offers technical features which obviate 29 | many of the risks upon which led to the development of our modern 30 | Certificate Authority Public Key Infrastructure; as an increasingly 31 | popular technology for networking with strong trust requirements, 32 | onion networking would benefit from easier access to TLS certificates 33 | for HTTPS use. 34 | 35 | At the moment only EV certificates are available for onion network 36 | addresses, although DV certificates are under discussion; the 37 | potential downsides of issuing DV certificates for Onion Addresses are 38 | discussed below. 39 | 40 | This document defines a third possible mechanism - SOOC: Same Origin 41 | Onion Certificates - that would enable real-time, client-side 42 | validation of per-onion-address TLS certificates, fully equivalent (in 43 | defined circumstances) to validation of a certificate trust chain, but 44 | involving none of third parties, trust chains, or financial cost. 45 | 46 | In the simpest possible terms, SOOC is *not* a "self-signed 47 | certificate" proposal; instead it is a proposal that "in very limited 48 | circumstances, we shall not care about signatures at all", with a 49 | codicil regarding how this may be improved in future. 50 | 51 | This distinction is important because it highlights that the initial 52 | implementation of SOOC certificates contain no additional features 53 | above or beyond the specifications of standard DV certificates, and 54 | require no tools to create other than standard `openssl` or `mkcert` 55 | to create. This is part of the value proposition of SOOC, in order to 56 | lower the barriers to adoption by small sites and experimenters with 57 | limited experience of TLS. 58 | 59 | {mainmatter} 60 | 61 | # SOOC Certificate Specification 62 | 63 | Using the Public Suffix List, let `baseDomain` be the Registrable 64 | Domain of the connected origin, e.g., `abcdefghijklmnop.onion` 65 | 66 | 1. A SOOC Certificate is a properly formatted DV or EV TLS 67 | certificate, per the browser's concept of web standards 68 | 1. where the certificate, if the browser were to trust the 69 | certificate's trust chain, would otherwise be a fully valid and 70 | trusted certificate 71 | 1. where the certificate, if it has a basicConstraints extension, that 72 | extension **MUST** only be CA:FALSE 73 | 1. where the certificate, if it has a commonName, that commonName 74 | **MUST** be equal to the baseDomain as defined above 75 | 1. where the certificate, if it has subjectAlternativeNames, those 76 | subjectAlternativeNames **MUST** all be of type dNSname, **MUST** 77 | all be of valid DV format (wildcards permitted) and each of which 78 | **MUST** have the baseDomain as the rightmost two labels. 79 | 1. where the certificate, if it cites any subjectAlternativeNames or 80 | other regisitrable domains, all of those subjectAlternativeNames or 81 | other registrable domains **MUST** have the baseDomain as the 82 | rightmost two labels. 83 | 84 | If all of these contstraints are satisfied, the certificate is a valid 85 | SOOC certificate. 86 | 87 | # SOOC Example Protocol 88 | 89 | If you are a Browser, and... 90 | 91 | 1. You connect to `site.geo.subdomain.foo.onion` to `GET` a URL via 92 | HTTPS in the normal way 93 | 1. and you observe that the rightmost label of the TLD is .onion 94 | 1. and that `site.geo.subdomain.foo.onion` offers you a certificate 95 | 1. then you **MUST** confirm that you have an opt-in setting enabled 96 | (probably default in TorBrowser) 97 | 1. and you **MUST** confirm that the certificate satisfies ALL of the 98 | conditions of being a valid SOOC certificate with the baseDomain 99 | of `foo.onion` 100 | 1. and you **MUST** confirm that the baseDomain for the certificate, 101 | matches the rightmost two labels of the URL site 102 | 1. and you **MUST** confirm that the certificate's 103 | subjectAlternativeNames would successfully match 104 | `site.geo.subdomain.foo.onion` 105 | 1. If all of the above are confirmed, then your certificate validation 106 | code **MUST** skip checking the certificiate trust chain. 107 | 108 | 109 | 110 | # Why SOOC is Necessary 111 | 112 | There are many reasons why the Internet and WWW are equipped with a 113 | public key infrastructure (PKI), and the PKI offers many features and 114 | benefits; however its inarguable primary function is to provide a form 115 | of identity assurance, that when a person types a hostname such as 116 | "www.example.com" into a web browser's URL bar, they should have some 117 | reasonable expectation - and ideally a strong guarantee - that the 118 | network-connected-service from which they are eventually served 119 | content is one that would commonly be accepted as being capable, 120 | permitted and expected to serve content which people who own the 121 | "www.example.com" intentionally supply. 122 | 123 | The PKI mechanism has evolved to provide such identity assurance in a 124 | heavily-layered network environment which lacks overarching trust 125 | mechanisms and which is riven with potential for attack at (or: 126 | across) different layers. 127 | 128 | For instance: 129 | 130 | * ARP: first-hop, last-hop, or indeed any other hop may be hijacked 131 | with spoofed layer-2 address resolution; indeed some firewall 132 | devices rely upon this mechanism for their function 133 | * TCP: traffic may be blocked, dropped, modified, injected, or 134 | redirected to fake machines 135 | * BGP: bearer traffic and entire flows may be blocked, dropped, or 136 | redirected to fake machines 137 | * DNS: namespaces can be domain-jacked, responses can be forged, 138 | cache-poisoned, or simply tampered-with in flight, also homoglyph 139 | "lookalike" domains (eg: www.examp1e.com) are also possible 140 | 141 | The benefits of any intra-layer trust mechanism - eg: IPsec 142 | Authentication Header (AH) & Encapsulating Security Payload (ESP) at 143 | layer-3 - are typically isolated and not known to other layers of the 144 | stack - eg: the web browser - which therefore cannot take 145 | consideration of their benefits. 146 | 147 | In this environment our HTTPS ecosystem has evolved in the expectation 148 | of ignoring transport security - such as IPsec - and has instead has 149 | built its own, where a server's "identity" may be provisionally 150 | bootstrapped by DNS resolution of of a layer-3 IP address, however 151 | that identity **MUST** be proven by proof-of-possession of a 152 | cryptographic key that has been blessed by a trusted authority as 153 | pertaining to "www.example.com". 154 | 155 | The extent of such blessing is variable: for DV certificates the 156 | requisite test is one of consistent DNS resolution (eg: LetsEncrypt); 157 | and for EV certificates there are additional, expensive, and arguably 158 | superfluous corporate identity checks. 159 | 160 | ## Onion Networking compared to TLS PKI 161 | 162 | Tor "onion networking" is an alternate, software-defined, flat layer-3 163 | network space which exists on top of TCP/IP and the rest of the 164 | internet. 165 | 166 | Onion addresses are either hashes of (in 80-bit version 2 addresses), 167 | or are literally and entirely (in 256-bit version 3 addresses) the 168 | public keys which sign all data that pertains to communication with 169 | that address. 170 | 171 | Like most cryptographic keys, onion addresses appear essentially to be 172 | strings of random bits, although it's possible via "mining" to 173 | eventually generate one which appears meaningful to human beings, eg: 174 | "facebookcorewwwi.onion" 175 | 176 | For purposes of PKI, the most interesting aspect of onion addresses is 177 | their textual representation; unlike IPv4's "dotted quads" or IPv6's 178 | colon-separated hexadecimal, onion addresses are required ([@RFC7686] 179 | section 1) to be written in a DNS-compatible text format: as base-32 180 | encoded binary with addition of the IANA Special-Use Domain Name 181 | suffix, ".onion", and they are interpreted ignoring any labels other 182 | than the rightmost two. 183 | 184 | Thus: the onion address "www.exampleonionaddr.onion" would be a 185 | version 2 onion address representing a server that possesses a 186 | 1024-bit RSA public key which has an 80-bit-truncated SHA-1 hash of 187 | 0x25c0c7ac8e6a1cd00c71 ([@RFC3548] base32 "EXAMPLEONIONADDR"); and 188 | where the "www" prefix hostname/subdomain will ignored, although if 189 | specified it will be passed onward in an HTTPS "Host:" header. 190 | 191 | This representation pierces all of the layers of the network stack, 192 | and in one encoding it addresses most of the problems which the TLS 193 | PKI stack has gradually evolved to solve for TCP/IP: 194 | 195 | * There is no DNS name resolution service in onion networking, and in 196 | fact [@RFC7686] section 2 specifies that there **MUST NOT** be 197 | overlap with DNS; this is an important point to which we will return 198 | later. 199 | * What the user types into the browser bar will defacto prove what 200 | site they are connected to; the Tor Onion Network at layer 3 will 201 | consequently assert "proof-of-possession of a cryptographic key" 202 | that will correspond absolutely to the remote service; this is 203 | isomorphic to the model of a TLS certificate proving the identity of 204 | a webserver. 205 | * Because onion addresses are layer-3 addresses, there is no concept 206 | of "subdomains" nor of "hostnames" and therefore any such 207 | information is considered "advisory"; however in this format they 208 | are backwards compatible in a way that "subdomains" for "dotted 209 | quad" addresses would not be, eg: "www.192.168.1.1" 210 | * All other connectivity redirections or "hijacks" are inhibited by 211 | the Tor network stack. 212 | 213 | # SOOC In Context 214 | 215 | As described above, the security characteristics and protections of 216 | layer-3 networking (eg: IPsec) are generally not visible to HTTPS 217 | applications at layer-7, and therefore cannot be relied upon. 218 | 219 | However: the encoding of onion addresses explicitly solves this problem: 220 | 221 | * The connection **must** be an onion connection, because it was made 222 | using Tor-capable software, and because the ".onion" Special Use 223 | Domain Name is reserved for that purpose. 224 | * The connection **must** be to "exampleonionaddr.onion" because the 225 | Tor network will not permit otherwise. 226 | * Any subdomain or hostname is subordinate to the fact that the 227 | connection is made to "exampleonionaddr.onion", because (as a 228 | layer-3 address) there are actually no such things as "subdomains" 229 | or "hostnames", and thus this information is purely advisory, or for 230 | compatability. 231 | 232 | Therefore it is possible for a client to assure itself - when 233 | presented with a TLS certificate for "www.exampleonionaddr.onion" - to 234 | assure itself that it is genuinely and authoritatively connected to 235 | "exampleonionaddr.onion" by simply performing a string comparison with 236 | the hostname to which is it connected - without any reference to a 237 | certificate authority trust chain nor any other third party resource. 238 | 239 | This observation is the basis of "Same Origin Onion Certificate" 240 | checking; that onion sites may offer (eg: homebrew DV-compliant) TLS 241 | certificates which correspond solely and uniquely to themselves, and 242 | under those limited circumstances the client may skip the certificate 243 | chain checks that might otherwise be required to validate identity. 244 | 245 | # SOOC Edge-Cases, and "SOOC-EV" 246 | 247 | It is necessary to recognise that there is one "weak" spot in the 248 | assertion that string comparison is sufficient to prove the binding 249 | between an Onion Address and a SSL Certificate SubjectAlternativeName, and 250 | that is in a scenario where the content webserver has been been 251 | deployed on one (or more) machines which are separate from the machine 252 | that terminates (i.e.: "hosts") the Onion Address AND, where the Tor 253 | daemon makes a direct TCP-level connection onwards to those servers. 254 | 255 | Those unfamiliar with how Tor works, may analogise this as 256 | "port-forwarding over SSH, where a port on the local host is forwarded 257 | to the remote server, which then forwards the data further onwards 258 | over a fresh TCP connection to a given port on a separate, third-party 259 | machine." 260 | 261 | The threat is: if a malicious actor can present themselves to the 262 | server-side Tor daemon as the IP address of the "third party" 263 | webserver - for instance a load-balancer, or a member of a 264 | load-balanced server tier - then under SOOC the malicious actor who 265 | achieves this could create a certificate permitthing them to 266 | impersonate a genuine SSL-certificate-enabled system *for* that onion 267 | address. 268 | 269 | This is a question of trust boundaries and real world deployments; at 270 | the moment the "onion networking" service space is broadly comprised 271 | of unencrypted HTTP, and as such any typical onion service deployment 272 | which uses a load-balancer would already be at risk of this attack. 273 | As such, currently lacking TLS-layer security, almost nobody typically 274 | deploys their onion server backend in a manner which could fall victim 275 | to this. Most onion HTTP services are typically served over loopback. 276 | 277 | Equally: any onion site which uses a "rewriter" reverse-proxy (e.g.: 278 | New York Times, BBC, Deutsche Welle, Propublica, Internet Archive) is 279 | also typically NOT at risk from this attack, because the inbound HTTPS 280 | request is terminated on the "onion" host, immediately rewritten in 281 | terms of the address of the upstream service, and is passed over 282 | loopback onward as a fresh HTTPS reverse-proxy connection. 283 | 284 | As far as the author is aware, the only onion service deployment where 285 | the above threat scenario would be a potential issue, is at Facebook; 286 | and if the Facebook devops team are at risk of someone interposing a 287 | fake server and server certificate into their infrastructure, then 288 | they have far bigger problems than mere onion service impersonation. 289 | 290 | ## Advanced Mitigations: SOOC-EV 291 | 292 | Generally at this point, enthusiastic cryptographers will point at 293 | Version 3 Onion Addresses and note that they are actual public keys, 294 | and "couldn't they just sign the SOOC Certificate, and the browser 295 | would check the signature, and that would be the end of the problem?" 296 | 297 | They are correct to say this, however this raises two problems: 298 | 299 | 1. This would orphan Version 2 Onion addresses without SOOC, expressly 300 | against the intent of this document. 301 | 2. The Version 3 Onion addresses are (by Tor policy) never used to 302 | sign anything https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n557 303 | 304 | Quote: 305 | 306 | > Master (hidden service) identity key -- A master signing keypair 307 | > used as the identity for a hidden service. This key is long term and 308 | > not used on its own to sign anything; it is only used to generate 309 | > blinded signing keys as described in [KEYBLIND] 310 | 311 | In Version 3 Onion Addressing, the address-key is used to derive 312 | short-term, time-locked, "blinded" keys in a fixed manner that can be 313 | replicated by a client which wishes to connect to the master onion 314 | address. The blinded keys are used to sign connection information 315 | that is loaded up into the "HSDir" distributed hash-table that 316 | describes Onion connectivity. 317 | 318 | Ergo: to implement a form of "Extended Validation" certificate 319 | extension that would bind a TLS certificate to an onion address, the 320 | certificate would have to contain the onion public key (for V2) or a 321 | blinded public key for a reasonable timestamp (for V3), and this 322 | public key would be used to validate a hash of some portion of the 323 | certificate, all in order to address this niche deployment risk. 324 | 325 | This is certainly possible to achieve, and is fairly straightforward, 326 | however it is a tremendous hassle for a niche risk, and I believe that 327 | it should not be an progress to implmenting SOOC without implementing 328 | these "Extended Validation"-type checks. 329 | 330 | My rationale for deferring SOOC-EV - apart from the nicheness aspect - 331 | is also bolstered by the observation that "Appendix F" of CA/B-Forum 332 | Ballot 144: 333 | 334 | https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ 335 | 336 | This describes the "CAB Forum Tor Service Descriptor Hash Extension", 337 | a hash of the V2 Onion Public Key which Certificate Authorities are 338 | obliged to bind into the EV TLS Onion Certificates that they issue, 339 | ostensibly to both link the onion public key more tightly to the TLS 340 | certificate in the event that a colliding V2 Onion address is 341 | generated, but also to protect against the above described kinds of 342 | attack. 343 | 344 | There exists absolutely no client code actually implemented to check 345 | for, nor validate, this descriptor, to the extent that when Digicert 346 | misissued a certificate without the extension (compare 347 | https://crt.sh/?id=240277340 with https://crt.sh/?id=241547157), 348 | no-one actually noticed, except for Digicert. 349 | 350 | As such, I don't believe that this attack is currently worthy of 351 | consideration, especially as it is within the power of the service 352 | provider to mitigate in alternative ways, and in any case we may still 353 | evolve towards SOOC-EV as the the technology matures. 354 | 355 | To be clear: I do believe that SOOC-EV should probably be done. But I 356 | do not believe that it should be a pre-requisite condition for SOOC, 357 | nor is it necessary to do it "now", nor is any threat great enough to 358 | block SOOC until SOOC-EV is defined. Apart from the reasons stated 359 | above, there is likely still some need for V3 Onion Address blinding 360 | and key-derivation algorithms to mature and prove stability in 361 | deployments for a few years. 362 | 363 | ## Reciprocal Attack: Shared Tor Gateways? 364 | 365 | Having comprehended the above, there is also obviously a reciprocal 366 | risk which can be stated: 367 | 368 | * What about shared onion gateways? What if many people use one Tor 369 | proxy to access Tor? One could interpose a fake SOCKS5 370 | man-in-the-middle and respond to Onion connection requests with a 371 | fake SOOC TLS certificate! 372 | 373 | The response to which, again, is that although such may happen 374 | experimentally, the overwhelming means by which people access Tor is 375 | by using a local client over loopback, one (or more) per user. At the 376 | "client" end, access to the Tor proxy is within the local trust 377 | boundary, where worse things can happen. 378 | 379 | # Linkfarm TBD 380 | 381 | For more on Onion Networking as a layer-3 network, see: 382 | https://www.youtube.com/watch?v=pebRZyg_bh8 383 | 384 | IANA Special-Use Domain Names 385 | https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml 386 | 387 | Facebook Onion Announcement 388 | https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237/ 389 | 390 | # Topics for possible expansion 391 | 392 | * SOOC Use Cases 393 | * SOOC and Certificate Transparency 394 | * SOOC and DV Certificates 395 | * Potential negative consequences of DV certificates for Onion Addresses 396 | * SOOC and EV Certificates 397 | * SOOC and HSTS 398 | * SOOC and LetsEncrypt 399 | * SOOC to complement, not replace, EV (and perhaps DV) 400 | 401 | {backmatter} 402 | -------------------------------------------------------------------------------- /readme-original.md: -------------------------------------------------------------------------------- 1 | ## Press Coverage 2 | 3 | * https://portswigger.net/daily-swig/how-tor-can-enable-verification-with-dv-certs 4 | 5 | # SOOC: Same-Origin Onion Certificate checks for DV TLS 6 | 7 | **A simple proposal to provide DV TLS certificates to Onion Sites** 8 | 9 | ## Outline 10 | 11 | [Onion sites](https://tools.ietf.org/html/rfc7686) provide self-authenticating network addresses which offer high assurance that a user of "onion networking" is connected to the service - strictly: to the possessor of a cryptographic private key - which they intended. 12 | 13 | This degree of assurance in the TCP/IP network stack is provided by certificate authorities who provide various checks prior of issuance of a certificate to a website owner. Depending upon the nature of the end certificate, some or all of these checks are redundant in the Onion networking space. 14 | 15 | Onion-networking-enabled browsers are capable of delivering most, possibly all, of their streams-based services and user experiences over onion networking; this is evidenced by work at [Facebook](https://www.facebookcorewwwi.onion/) and the [New York Times](https://www.nytimes3xbfgragh.onion/) and [Cloudflare](https://blog.cloudflare.com/cloudflare-onion-service/), amongst others. These sites are equipped with EV certificates issued under the terms of [Ballot 144 of the CA/Browser Forum](https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/) which opened up official provision for onion networking. 16 | 17 | EV certificates are not available to individual users, and DV certificates are not available to onion addresses, for many reasons not least the justifiable liability concerns of Certificate Authorities; however the increasing popularity of onion networking, combined with the increasing number of applications which mandate use of HTTPS, leads towards a bifurcation of trust: that onion addresses offer high assurance, but there is no means for that to be leveraged in the HTTPS stack unless one is an organisation and capable of purchasing an EV certificate. This situation inhibits innovation in the network stack. 18 | 19 | Also: there are considerations of HTTP/2, that in the TCP/IP network space, a single TCP connection which has been authenticated with a certificate offering SubjectAltNames of both `foo.com` and `bar.net`, will be treated as a pre-existing connection to `bar.net` for connection reuse even if the connection was originally made with the intention of fetching a resource from `foo.com`. It is probable that this level of trust may only be viable by provision of a licensed Certificate Authority as an arbiter. 20 | 21 | However, this does not prohibit us from offering what we believe is a viable and simple solution for in-browser trust of DV certificates for onion addresses: 22 | 23 | ## Proposal 24 | 25 | Consider a website with the onion address `examplewebsitexx.onion` offering services at URIs such as: 26 | 27 | * `https://examplewebsitexx.onion` 28 | * `https://www.examplewebsitexx.onion/foo.html` 29 | * `https://m.staging.examplewebsitexx.onion/foo/bar.mp3` 30 | 31 | A browser will consider a DV certificate to be valid for connections to this site, if one of the two following conditions is true: 32 | 33 | ### Condition 1: (already works) 34 | 35 | * The connection certificate is a valid DV certificate (eg: such as those created by [Filippo Valsorda's `mkcert`](https://github.com/FiloSottile/mkcert)) 36 | * **and** the certificate satisfies the standard trust rules for the webpage in question 37 | * **and** the certificate is signed by a Certificate Authority Key which matches a root certificate that has been manually added to the local trust store 38 | 39 | ...or... 40 | 41 | ### Condition 2: (to be added) 42 | 43 | * The connection certificate is a valid DV certificate (eg: `mkcert`, again) 44 | * **and** the certificate satisfies the standard trust rules for the webpage in question 45 | * **but** the certificate is signed by a Certificate Authority Key that **cannot** be resolved in the local trust store 46 | * **however** the rightmost label of **all Subject Alt Names in the certificate, without exception**, is `onion` 47 | * **and** the rightmost two labels of **all Subject Alt Names in the certificate, without exception**, match those of the given onion site (ie: `examplewebsitexx.onion`) 48 | * **and** no Common Name is supplied on the certificate 49 | * **and** the certificate is a "leaf" / not used for validating other certs. 50 | 51 | ## Which browsers would this target? 52 | 53 | The goal would be to put this in Firefox as a default-false option, and have TorBrowser and other Tor-aware clients set it to default-true as a matter of choice or design. 54 | 55 | ## Rationale 56 | 57 | **Condition 1** has been extensively tested by the author, and is simple, obvious, and practically redundant: *it already works*. Extant web browsers do not take any special steps to avoid connections to `.onion` websites, and when connected to the Tor network they are abstracted from the network via a standard `SOCKS5` proxy which also performs name resolution, thereby obviating any DNS concerns. 58 | 59 | **Condition 2** is novel, but conceptually simple: to validate a DV certificate fully for connecting to a given site - including, eg: failing validation if not-before / not-after date boundaries are exceeded - *except* to selectively ignore failure to validate the certificate chain / an inability to resolve the Certificate Authority Key Identifier, in the circumstances that the certificate **could exclusively and only be used to communicate with a "layer 7" onion address/sitename that corresponds to the exact same "layer 3" onion address**. 60 | 61 | I believe this proposal addresses the trust requirements of binding onion addresses to TLS certificates, preventing the issues of HTTP/2 connection reuse on the basis of Onion DV-certificates, and provides a self-serve route forwards for individuals to build-out onion services, via use of tools like `mkcert`. 62 | 63 | This proposal also (currently) leaves open a non-exclusionary role[1] for existing EV Onion Certificates: for those purposes where more than one Onion address, or a mixture of Onion Addresses and DNS Names, **must** be present in a single certificate; at first consideration this would broadly be in line with the original vision of EV certificates as being "extra validated" 64 | 65 | ## Proposed Implementation 66 | 67 | * Trap the failure condition where the certificate chain for a connection to `examplewebsitexx.onion` has been found not to validiate, on the specific grounds that the Certificate Authority Key Identifier cannot be found in the trust root. 68 | * Check that the certificate is DV 69 | * Check that the certificate is exclusively citing Subject Alt Names which end in two labels `examplewebsitexx.onion` 70 | * Don't just do a simple `strcmp()`, check the label boundaries because subdomains, etc; do it properly 71 | * Check that there is no CN in the certificate 72 | * Check that you are processing a "leaf" certificate, not halfway up a chain of trust. 73 | * If all conditions are met, ignore this specific failure condition and continue validation processing. 74 | 75 | ## Potential FAQs 76 | 77 | * Q: What if a "real" CA issues a DV certificate containing both Onion and DNS addresses? 78 | * A: They're not allowed to, but in any case if someone really wanted one they could buy a "combo" EV certificate which can contain both already 79 | * Q: Why repeat the "rightmost label" stuff? 80 | * A: Mostly emphasis / to suggest a "sniff test" for implementers; plus I was vaguely wondering about the converse, viz: whether it was necessary to somehow "ban" `mkcert` users from generating their own "combo" certs, before I realised that it would be foolish, fruitless and unnecessary to do so. 81 | * Q: Why the CN thing? 82 | * A: The goal of requiring no Common Name is simply to be doubly-certain regarding potential for trust leaks; this may be redundant / pointless / is a matter for consideration. 83 | * Q: why not self-signed certs? 84 | * A: Truly "self-signed certificates", suck. Aside from the aspect of "an infinite hell of security popups", there is also the matter that a solution would require "OMG we need to define a standard for a self-signed Onion Cert" and endless bickering; on the other hand, the above proposal is easy to explain and reason about. 85 | * Q: isn't this the same as self-signed certs? 86 | * A: This is close, but not really the same as self-signed certs. This proposal merely means that you can skip DV chain validation **if** it is not already possible **and** where there is no practicable benefit in doing so (because of the self-authenticating nature of onion addresses, and no risk of HTTP/2 circuit-reuse leaks) 87 | * Q: you're relying on tor to provide a secure channel here, which ends at the egress tor node with its onion address private keys, so your path from that last hop to your httpd should be over localhost 88 | * A: yes, but you're presuming the implementer's intention, here. This is no more of an risk than a terminate-and-forward TCP/IP load-balancer would be (is) for an EV certificate. 89 | * Q: Doesn't this mean that the cert will be issued to a network connection, rather than a person or company? 90 | * Basically the same as LetsEncrypt, then. 91 | * Q: why all this fuss? Why not just make self-authenticating Tor connections accept "any old certificate"? 92 | * Various reasons, not least of which is remaining orthogonal with upstream application expectations; you wouldn't want to connect to an random onion website and have it (via its certificate) offering to provide a HTTP/2 connection back to facebook.com, would you? Unless it was the genuine facebook onion address via Alt-Svc headers, of course... 93 | * Q: Why do certificate authorities not issue DV certificates for onions? 94 | * A: many reasons, mostly due to liability: stuff like *"ZOMG v2 onion addresses are 80 bits of truncated SHA1 hash and if an attacker had a few squillions of dollars to spare then they could collide a key... and we (certificate authorities) might get sued for issuing a cert to a collided key."* - which is fair enough. One joy of the self-service approach to Onion DV keys is an "on your own head, be it" approach to liability: it is neither more, nor less, risk than mining and using the address in the first place. See also this essay: https://medium.com/@alecmuffett/onions-certs-browsers-a-three-way-mexican-standoff-7dc987b8ebc8 95 | * Q: Can you simply short-cut Condition 1 if you see Condition 2? 96 | * A: Nope; because someone might be using Condition 1 in order to test an eventual EV-cert deployment architecture, including mixed Onion-and-DNS-Addresses amongst the SANs, which Condition 2 would forbid. 97 | 98 | ## Discussion: On "binding" Onion Addresses with SSL Certificates 99 | 100 | The **EV** Onion Certificate mechanism [takes additional steps to embed a hash of the Onion public key](https://cabforum.org/pipermail/public/2017-April/010706.html) into the certificate; this was a last minute thought in the EV Onion Certificate specification, meant as some guarantee against "impersonating an onion site". 101 | 102 | I did not understand this choice from the outset, and in practice it has greatly complicated the issuance of EV onion certs with a demand for new and specialised tooling and process, to no apparent practical benefit. 103 | 104 | It was failure to embed a proper hash [(SEE IMAGE)](revoked-onions.png) which led to the [revocation of one NYT certificate](https://crt.sh/?id=240277340) and its [rapid replacement by another](https://crt.sh/?id=241547157) - so this requirement for an extra hash adds bureaucratic load, and possibility for error, and therefore adds cost; however I *did* install that certificate in the NYT for 24 hours, and it *did* work, so apparently no browser is checking this information. 105 | 106 | Further: how does one "impersonate an onion site"? On reflection there might be some edge cases where that's a risk, but this is my take on it: 107 | 108 | By definition an onion site someone who possesses a public key (and the corresponding private one) which they can register with the Tor network; the public key of the Onion address *is* Tor's defacto network address, and anyone with the corresponding private key can represent themselves as that Onion address *upon* the Tor network, and they *will* receive traffic for that network address. 109 | 110 | Unlike in the cleartext internet, **Tor's layer-3 behaviour is the source of truth** regarding network endpoint identity, rather than the contents of a HTTPS certificate which is supported by the infrastructures of IP-hosting, DNS-hosting, Certificate Authorities, and ISP behaviour. There is an absolute binding between (say) `facebookcorewwwi.onion` and Facebook, without reference to third parties. 111 | 112 | ### Mapping a Certificate to an Onion Address 113 | 114 | If we are given a HTTPS certificate for an onion address, how do we know which Onion Public Key it is referring to? 115 | 116 | Simple: we look at the ("DNSName") onion addresses that are stored in the SubjectAltNames field: 117 | 118 | * With v3 onion addresses, the onion address string is *literally* the entire public key; therefore the public key will be embedded, probably several times over, in the SubjectAltNames of the certificate; string comparison of the rightmost two labels will guarantee the binding, and the additional "cabf-TorServiceDescriptorHash" is unnecessary. 119 | * With v2 addresses, the onion address string is a 80-bit truncated SHA-1 hash of the public key; again string comparison of the rightmost two labels can provide the binding, but the question is whether a truncated hash is "sufficient" binding. The answer is yes, because the Tor network **itself** will accept as legitimate any public key which can match this hash, and will send traffic to it. (See "source of truth", above) 120 | 121 | In the circumstances that an onion-address private/public keypair is leaked (irrespective of v2 or v3) then it is a "game-over" situation; there is absolutely no "putting the genie back in the bottle" as there might be on the cleartext internet where a (stale?) DNS domain is hijacked, its addresses redirected, and a LetsEncrypt DV certificate is issued for the hijacker's machines. 122 | 123 | ### Mapping (in reverse) an Onion Address to a Certificate 124 | 125 | If we are given an Onion Public Key / Address, how do we know what is the HTTPS Certificate for that connection? 126 | 127 | Simple: we connect to the onion address, and we retrieve the certificate. The layer-3 connection is defacto authenticated to a level which is similar to HTTPS, so any HTTPS certificate which we receive over such a connection can be assumed to be genuine. It is "true" because we received it over that link. 128 | 129 | This leaves open three edge cases: 130 | 131 | * What if - when connecting to a third party like `foo.com` - we receive a **DV certificate** which cites both `foo.com` and `bar.onion`, in the hope of stealing Onion traffic by means of redirecting it to `foo.com` because of `Alt-Svc` headers? 132 | * This cannot happen, because Certificate Authorities are forbidden from issuing DV certificates which contain onion addresses. 133 | * What if - when connecting to a third party like `foo.com` - we receive a **EV certificate** which cites both `foo.com` and `bar.onion`? 134 | * This is fine, and may be desirable behaviour for attribution, because the additional checks of EV mitigate the risks of misissuance. 135 | * What if the user is connecting to a public and untrusted SOCKS5 onion proxy, which is then in a position to forge / rewrite all content, connections, and HTTPS certificates, and present itself as `bar.onion`? 136 | 137 | This latter is a real and absolute risk, and (other than via EV certificates) I do not currently see any reasonable way to fix it, but I will point out that untrusted proxies are a deployment architecture actively discouraged by the Tor community. There are services such as [Tor2web](https://www.tor2web.org) which approximate this architecture, but they are deprecated and loudly proclaimed to be insecure. Quote: 138 | 139 | > WARNING: Tor2web only protects publishers, not readers. As a reader installing Tor Browser will give you much greater anonymity, confidentiality, and authentication than using Tor2web. Using Tor2web trades off security for convenience and usability. 140 | 141 | The notion of having a solitary tor proxy for your entire home is more plausible, but this collapses to the question of where one draws the line of one's own "security perimeter" and how much one trusts that. The recommended deployment architecture for Tor remains having one daemon per host, and for all the apps on that host to talk to it over loopback. 142 | 143 | Above I write: *I do not currently see any reasonable way to fix * - why is that? Because if SSL certificates are to resolve trust issues over an untrusted network (eg: *the internet*; or, equally, *accessing onion networks over an untrusted proxy*) then the only way to resolve this is by reference to a trust root that is already established in the browser. 144 | 145 | We already have a mechanism for this: the EV Onion Certificate. 146 | 147 | However: the whole point of this proposal is to enable a DV-like Onion Certificate which would complement the self-service nature of Onion Networking. People create their own onion addresses and use them without requiring the intercession of a third party, and therefore they should be provided with some manner of HTTPS certificate which can also function without the intercession of a third party. 148 | 149 | Traditionally this latter might be a self-signed certificate — because onion addresses are equally self-signed — but rather than create a whole new certificate specification, instead it seems more efficient to simply either: 150 | 151 | 1. steal the DV specification and then amend it to add "don't act as a CA, and plz ignore the certificate chain", or 152 | 2. amend the DV validation rules in a sympathetic way 153 | 154 | Hence the above proposal. 155 | 156 | Aside from *"fetching the certificate over the onion connection, and narrowing its scope to be relevant only to that onion connection"* - any other proposition to "bind an onion address to a certificate", such as proposing that the certificate be signed by the private key for the onion, runs into technical challenges: 157 | 158 | 1. what are you going to do with this signature? staple it into the HTTPS protocol somehow? It can't go into the thing that is being signed... 159 | 2. with v2 onions, the address is a truncated hash of the public key, rather than the public key itself; lacking the whole 1023-bit public key inhibits validation. Version2 onions are due to be deprecated, but given the above ("source of truth", q.v.) and that no certificate authority exists to be sued for misissuance in a self-service DV onion scenario, I see no reason to exclude them from HTTPS protection. 160 | 161 | - Alec Muffett, 10 Feb 2019 162 | 163 | [1] ie: individuals can work around it by careful provision of multiple certificates 164 | 165 | -------------------------------------------------------------------------------- /revoked-onions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alecmuffett/onion-dv-certificate-proposal/76cb843b426e16f7cec3650f4733998a2a9dcd50/revoked-onions.png -------------------------------------------------------------------------------- /text/draft-muffett-same-origin-onion-certificates.basic.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Same Origin Onion Certificates 5 | 6 | 7 | 8 | 9 | 10 |

Abstract

11 | 12 |

Onion networking [RFC7686] offers technical features which obviate 13 | many of the risks upon which led to the development of our modern 14 | Certificate Authority Public Key Infrastructure; as an increasingly 15 | popular technology for networking with strong trust requirements, 16 | onion networking would benefit from easier access to TLS certificates 17 | for HTTPS use.

18 | 19 |

At the moment only EV certificates are available for onion network 20 | addresses, although DV certificates are under discussion; the 21 | potential downsides of issuing DV certificates for Onion Addresses are 22 | discussed below.

23 | 24 |

This document defines a third possible mechanism - SOOC: Same Origin 25 | Onion Certificates - that would enable real-time, client-side 26 | validation of per-onion-address TLS certificates, fully equivalent (in 27 | defined circumstances) to validation of a certificate trust chain, but 28 | involving none of third parties, trust chains, or financial cost.

29 | 30 |

In the simpest possible terms, SOOC is not a “self-signed 31 | certificate” proposal; instead it is a proposal that “in very limited 32 | circumstances, we shall not care about signatures at all”, with a 33 | codicil regarding how this may be improved in future.

34 | 35 |

This distinction is important because it highlights that the initial 36 | implementation of SOOC certificates contain no additional features 37 | above or beyond the specifications of standard DV certificates, and 38 | require no tools to create other than standard openssl or mkcert 39 | to create. This is part of the value proposition of SOOC, in order to 40 | lower the barriers to adoption by small sites and experimenters with 41 | limited experience of TLS.

42 |
43 |

SOOC Certificate Specification

44 | 45 |

Using the Public Suffix List, let baseDomain be the Registrable 46 | Domain of the connected origin, e.g., abcdefghijklmnop.onion

47 | 48 |
    49 |
  1. A SOOC Certificate is a properly formatted DV or EV TLS 50 | certificate, per the browser’s concept of web standards
    2. 51 |
  2. where the certificate, if the browser were to trust the 52 | certificate’s trust chain, would otherwise be a fully valid and 53 | trusted certificate
    3. 54 |
  3. where the certificate, if it has a basicConstraints extension, that 55 | extension MUST only be CA:FALSE
    4. 56 |
  4. where the certificate, if it has a commonName, that commonName 57 | MUST be equal to the baseDomain as defined above
    5. 58 |
  5. where the certificate, if it has subjectAlternativeNames, those 59 | subjectAlternativeNames MUST all be of type dNSname, MUST 60 | all be of valid DV format (wildcards permitted) and each of which 61 | MUST have the baseDomain as the rightmost two labels.
    6. 62 |
  6. where the certificate, if it cites any subjectAlternativeNames or 63 | other regisitrable domains, all of those subjectAlternativeNames or 64 | other registrable domains MUST have the baseDomain as the 65 | rightmost two labels.
    7. 66 |
67 | 68 |

If all of these contstraints are satisfied, the certificate is a valid 69 | SOOC certificate.

70 | 71 |

SOOC Example Protocol

72 | 73 |

If you are a Browser, and…

74 | 75 |
    76 |
  1. You connect to site.geo.subdomain.foo.onion to GET a URL via 77 | HTTPS in the normal way
    2. 78 |
  2. and you observe that the rightmost label of the TLD is .onion
    3. 79 |
  3. and that site.geo.subdomain.foo.onion offers you a certificate 80 | 81 |
      82 |
    1. then you MUST confirm that you have an opt-in setting enabled 83 | (probably default in TorBrowser)
      2. 84 |
    2. and you MUST confirm that the certificate satisfies ALL of the 85 | conditions of being a valid SOOC certificate with the baseDomain 86 | of foo.onion
      3. 87 |
    3. and you MUST confirm that the baseDomain for the certificate, 88 | matches the rightmost two labels of the URL site
      4. 89 |
    4. and you MUST confirm that the certificate’s 90 | subjectAlternativeNames would successfully match 91 | site.geo.subdomain.foo.onion
      5. 92 |
    4. 93 |
  4. If all of the above are confirmed, then your certificate validation 94 | code MUST skip checking the certificiate trust chain.
    5. 95 |
96 | 97 |

Why SOOC is Necessary

98 | 99 |

There are many reasons why the Internet and WWW are equipped with a 100 | public key infrastructure (PKI), and the PKI offers many features and 101 | benefits; however its inarguable primary function is to provide a form 102 | of identity assurance, that when a person types a hostname such as 103 | “www.example.com” into a web browser’s URL bar, they should have some 104 | reasonable expectation - and ideally a strong guarantee - that the 105 | network-connected-service from which they are eventually served 106 | content is one that would commonly be accepted as being capable, 107 | permitted and expected to serve content which people who own the 108 | “www.example.com” intentionally supply.

109 | 110 |

The PKI mechanism has evolved to provide such identity assurance in a 111 | heavily-layered network environment which lacks overarching trust 112 | mechanisms and which is riven with potential for attack at (or: 113 | across) different layers.

114 | 115 |

For instance:

116 | 117 | 129 | 130 |

The benefits of any intra-layer trust mechanism - eg: IPsec 131 | Authentication Header (AH) & Encapsulating Security Payload (ESP) at 132 | layer-3 - are typically isolated and not known to other layers of the 133 | stack - eg: the web browser - which therefore cannot take 134 | consideration of their benefits.

135 | 136 |

In this environment our HTTPS ecosystem has evolved in the expectation 137 | of ignoring transport security - such as IPsec - and has instead has 138 | built its own, where a server’s “identity” may be provisionally 139 | bootstrapped by DNS resolution of of a layer-3 IP address, however 140 | that identity MUST be proven by proof-of-possession of a 141 | cryptographic key that has been blessed by a trusted authority as 142 | pertaining to “www.example.com”.

143 | 144 |

The extent of such blessing is variable: for DV certificates the 145 | requisite test is one of consistent DNS resolution (eg: LetsEncrypt); 146 | and for EV certificates there are additional, expensive, and arguably 147 | superfluous corporate identity checks.

148 | 149 |

Onion Networking compared to TLS PKI

150 | 151 |

Tor “onion networking” is an alternate, software-defined, flat layer-3 152 | network space which exists on top of TCP/IP and the rest of the 153 | internet.

154 | 155 |

Onion addresses are either hashes of (in 80-bit version 2 addresses), 156 | or are literally and entirely (in 256-bit version 3 addresses) the 157 | public keys which sign all data that pertains to communication with 158 | that address.

159 | 160 |

Like most cryptographic keys, onion addresses appear essentially to be 161 | strings of random bits, although it’s possible via “mining” to 162 | eventually generate one which appears meaningful to human beings, eg: 163 | “facebookcorewwwi.onion”

164 | 165 |

For purposes of PKI, the most interesting aspect of onion addresses is 166 | their textual representation; unlike IPv4’s “dotted quads” or IPv6’s 167 | colon-separated hexadecimal, onion addresses are required ([RFC7686] 168 | section 1) to be written in a DNS-compatible text format: as base-32 169 | encoded binary with addition of the IANA Special-Use Domain Name 170 | suffix, “.onion”, and they are interpreted ignoring any labels other 171 | than the rightmost two.

172 | 173 |

Thus: the onion address “www.exampleonionaddr.onion” would be a 174 | version 2 onion address representing a server that possesses a 175 | 1024-bit RSA public key which has an 80-bit-truncated SHA-1 hash of 176 | 0x25c0c7ac8e6a1cd00c71 ([RFC3548] base32 “EXAMPLEONIONADDR”); and 177 | where the “www” prefix hostname/subdomain will ignored, although if 178 | specified it will be passed onward in an HTTPS “Host:” header.

179 | 180 |

This representation pierces all of the layers of the network stack, 181 | and in one encoding it addresses most of the problems which the TLS 182 | PKI stack has gradually evolved to solve for TCP/IP:

183 | 184 | 203 | 204 |

SOOC In Context

205 | 206 |

As described above, the security characteristics and protections of 207 | layer-3 networking (eg: IPsec) are generally not visible to HTTPS 208 | applications at layer-7, and therefore cannot be relied upon.

209 | 210 |

However: the encoding of onion addresses explicitly solves this problem:

211 | 212 | 224 | 225 |

Therefore it is possible for a client to assure itself - when 226 | presented with a TLS certificate for “www.exampleonionaddr.onion” - to 227 | assure itself that it is genuinely and authoritatively connected to 228 | “exampleonionaddr.onion” by simply performing a string comparison with 229 | the hostname to which is it connected - without any reference to a 230 | certificate authority trust chain nor any other third party resource.

231 | 232 |

This observation is the basis of “Same Origin Onion Certificate” 233 | checking; that onion sites may offer (eg: homebrew DV-compliant) TLS 234 | certificates which correspond solely and uniquely to themselves, and 235 | under those limited circumstances the client may skip the certificate 236 | chain checks that might otherwise be required to validate identity.

237 | 238 |

SOOC Edge-Cases, and “SOOC-EV”

239 | 240 |

It is necessary to recognise that there is one “weak” spot in the 241 | assertion that string comparison is sufficient to prove the binding 242 | between an Onion Address and a SSL Certificate SubjectAlternativeName, and 243 | that is in a scenario where the content webserver has been been 244 | deployed on one (or more) machines which are separate from the machine 245 | that terminates (i.e.: “hosts”) the Onion Address AND, where the Tor 246 | daemon makes a direct TCP-level connection onwards to those servers.

247 | 248 |

Those unfamiliar with how Tor works, may analogise this as 249 | “port-forwarding over SSH, where a port on the local host is forwarded 250 | to the remote server, which then forwards the data further onwards 251 | over a fresh TCP connection to a given port on a separate, third-party 252 | machine.”

253 | 254 |

The threat is: if a malicious actor can present themselves to the 255 | server-side Tor daemon as the IP address of the “third party” 256 | webserver - for instance a load-balancer, or a member of a 257 | load-balanced server tier - then under SOOC the malicious actor who 258 | achieves this could create a certificate permitthing them to 259 | impersonate a genuine SSL-certificate-enabled system for that onion 260 | address.

261 | 262 |

This is a question of trust boundaries and real world deployments; at 263 | the moment the “onion networking” service space is broadly comprised 264 | of unencrypted HTTP, and as such any typical onion service deployment 265 | which uses a load-balancer would already be at risk of this attack. 266 | As such, currently lacking TLS-layer security, almost nobody typically 267 | deploys their onion server backend in a manner which could fall victim 268 | to this. Most onion HTTP services are typically served over loopback.

269 | 270 |

Equally: any onion site which uses a “rewriter” reverse-proxy (e.g.: 271 | New York Times, BBC, Deutsche Welle, Propublica, Internet Archive) is 272 | also typically NOT at risk from this attack, because the inbound HTTPS 273 | request is terminated on the “onion” host, immediately rewritten in 274 | terms of the address of the upstream service, and is passed over 275 | loopback onward as a fresh HTTPS reverse-proxy connection.

276 | 277 |

As far as the author is aware, the only onion service deployment where 278 | the above threat scenario would be a potential issue, is at Facebook; 279 | and if the Facebook devops team are at risk of someone interposing a 280 | fake server and server certificate into their infrastructure, then 281 | they have far bigger problems than mere onion service impersonation.

282 | 283 |

Advanced Mitigations: SOOC-EV

284 | 285 |

Generally at this point, enthusiastic cryptographers will point at 286 | Version 3 Onion Addresses and note that they are actual public keys, 287 | and “couldn’t they just sign the SOOC Certificate, and the browser 288 | would check the signature, and that would be the end of the problem?”

289 | 290 |

They are correct to say this, however this raises two problems:

291 | 292 |
    293 |
  1. This would orphan Version 2 Onion addresses without SOOC, expressly 294 | against the intent of this document.
    2. 295 |
  2. The Version 3 Onion addresses are (by Tor policy) never used to 296 | sign anything https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n557
    3. 297 |
298 | 299 |

Quote:

300 | 301 |
302 |

Master (hidden service) identity key – A master signing keypair 303 | used as the identity for a hidden service. This key is long term and 304 | not used on its own to sign anything; it is only used to generate 305 | blinded signing keys as described in [KEYBLIND]

306 |
307 | 308 |

In Version 3 Onion Addressing, the address-key is used to derive 309 | short-term, time-locked, “blinded” keys in a fixed manner that can be 310 | replicated by a client which wishes to connect to the master onion 311 | address. The blinded keys are used to sign connection information 312 | that is loaded up into the “HSDir” distributed hash-table that 313 | describes Onion connectivity.

314 | 315 |

Ergo: to implement a form of “Extended Validation” certificate 316 | extension that would bind a TLS certificate to an onion address, the 317 | certificate would have to contain the onion public key (for V2) or a 318 | blinded public key for a reasonable timestamp (for V3), and this 319 | public key would be used to validate a hash of some portion of the 320 | certificate, all in order to address this niche deployment risk.

321 | 322 |

This is certainly possible to achieve, and is fairly straightforward, 323 | however it is a tremendous hassle for a niche risk, and I believe that 324 | it should not be an progress to implmenting SOOC without implementing 325 | these “Extended Validation”-type checks.

326 | 327 |

My rationale for deferring SOOC-EV - apart from the nicheness aspect - 328 | is also bolstered by the observation that “Appendix F” of CA/B-Forum 329 | Ballot 144:

330 | 331 |

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

332 | 333 |

This describes the “CAB Forum Tor Service Descriptor Hash Extension”, 334 | a hash of the V2 Onion Public Key which Certificate Authorities are 335 | obliged to bind into the EV TLS Onion Certificates that they issue, 336 | ostensibly to both link the onion public key more tightly to the TLS 337 | certificate in the event that a colliding V2 Onion address is 338 | generated, but also to protect against the above described kinds of 339 | attack.

340 | 341 |

There exists absolutely no client code actually implemented to check 342 | for, nor validate, this descriptor, to the extent that when Digicert 343 | misissued a certificate without the extension (compare 344 | https://crt.sh/?id=240277340 with https://crt.sh/?id=241547157), 345 | no-one actually noticed, except for Digicert.

346 | 347 |

As such, I don’t believe that this attack is currently worthy of 348 | consideration, especially as it is within the power of the service 349 | provider to mitigate in alternative ways, and in any case we may still 350 | evolve towards SOOC-EV as the the technology matures.

351 | 352 |

To be clear: I do believe that SOOC-EV should probably be done. But I 353 | do not believe that it should be a pre-requisite condition for SOOC, 354 | nor is it necessary to do it “now”, nor is any threat great enough to 355 | block SOOC until SOOC-EV is defined. Apart from the reasons stated 356 | above, there is likely still some need for V3 Onion Address blinding 357 | and key-derivation algorithms to mature and prove stability in 358 | deployments for a few years.

359 | 360 |

Reciprocal Attack: Shared Tor Gateways?

361 | 362 |

Having comprehended the above, there is also obviously a reciprocal 363 | risk which can be stated:

364 | 365 | 371 | 372 |

The response to which, again, is that although such may happen 373 | experimentally, the overwhelming means by which people access Tor is 374 | by using a local client over loopback, one (or more) per user. At the 375 | “client” end, access to the Tor proxy is within the local trust 376 | boundary, where worse things can happen.

377 | 378 |

Linkfarm TBD

379 | 380 |

For more on Onion Networking as a layer-3 network, see: 381 | https://www.youtube.com/watch?v=pebRZyg_bh8

382 | 383 |

IANA Special-Use Domain Names 384 | https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

385 | 386 |

Facebook Onion Announcement 387 | https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237/

388 | 389 |

Topics for possible expansion

390 | 391 | 404 |
405 |

Bibliography

406 |
407 |
408 |
[RFC3548]
409 |
410 |
[RFC7686]
411 |
412 |
413 |
414 | 415 | 416 | 417 | 418 | -------------------------------------------------------------------------------- /text/draft-muffett-same-origin-onion-certificates.basic.md: -------------------------------------------------------------------------------- 1 | %%% 2 | title = "Same Origin Onion Certificates" 3 | abbrev = "sooc" 4 | category = "info" 5 | docName = "apparently this tool demands a doc name but does not use it" 6 | ipr ="trust200902" 7 | area = "Internet" 8 | workgroup = "Transport Layer Security" 9 | keyword = ["tor", "onion", "tls", "ssl"] 10 | 11 | [seriesInfo] 12 | status = "informational" 13 | name = "Internet-Draft" 14 | value = "draft-muffett-same-origin-onion-certificates-00" 15 | stream = "IETF" 16 | 17 | [[author]] 18 | initials="A." 19 | surname="Muffett" 20 | fullname="Alec Muffett" 21 | organization = "Independent" 22 | [author.address] 23 | email = "alec.muffett@gmail.com" 24 | %%% 25 | 26 | .# Abstract 27 | 28 | Onion networking [@RFC7686] offers technical features which obviate many of the risks upon which led 29 | to the development of our modern Certificate Authority Public Key Infrastructure; as an increasingly 30 | popular technology for networking with strong trust requirements, onion networking would benefit 31 | from easier access to TLS certificates for HTTPS use. 32 | 33 | At the moment only EV certificates are available for onion network addresses, although DV 34 | certificates are under discussion; the potential downsides of issuing DV certificates for Onion 35 | Addresses are discussed below. 36 | 37 | This document defines a third possible mechanism - SOOC: Same Origin Onion Certificates - that would 38 | enable real-time, client-side validation of per-onion-address TLS certificates, fully equivalent 39 | (in defined circumstances) to validation of a certificate trust chain, but involving none of third 40 | parties, trust chains, or financial cost. 41 | 42 | In the simpest possible terms, SOOC is *not* a "self-signed certificate" proposal; instead it is 43 | a proposal that "in very limited circumstances, we shall not care about signatures at all", with a 44 | codicil regarding how this may be improved in future. 45 | 46 | This distinction is important because it highlights that the initial implementation of SOOC 47 | certificates contain no additional features above or beyond the specifications of standard DV 48 | certificates, and require no tools to create other than standard `openssl` or `mkcert` to create. 49 | This is part of the value proposition of SOOC, in order to lower the barriers to adoption by small 50 | sites and experimenters with limited experience of TLS. 51 | 52 | {mainmatter} 53 | 54 | # SOOC Certificate Specification 55 | 56 | Using the Public Suffix List, let `baseDomain` be the Registrable Domain of the connected origin, 57 | e.g., `abcdefghijklmnop.onion` 58 | 59 | 1. A SOOC Certificate is a properly formatted DV or EV TLS certificate, per the browser's concept 60 | of web standards 61 | 62 | 2. where the certificate, if the browser were to trust the certificate's trust chain, would 63 | otherwise be a fully valid and trusted certificate 64 | 65 | 3. where the certificate, if it has a basicConstraints extension, that extension **MUST** only be 66 | CA:FALSE 67 | 68 | 4. where the certificate, if it has a commonName, that commonName **MUST** be equal to the 69 | baseDomain as defined above 70 | 71 | 5. where the certificate, if it has subjectAlternativeNames, those subjectAlternativeNames **MUST** 72 | all be of type dNSname, **MUST** all be of valid DV format (wildcards permitted) and each of 73 | which **MUST** have the baseDomain as the rightmost two labels. 74 | 75 | 6. where the certificate, if it cites any subjectAlternativeNames or other regisitrable domains, 76 | all of those subjectAlternativeNames or other registrable domains **MUST** have the baseDomain 77 | as the rightmost two labels. 78 | 79 | If all of these contstraints are satisfied, the certificate is a valid SOOC certificate. 80 | 81 | # SOOC Example Protocol 82 | 83 | If you are a Browser, and... 84 | 85 | 1. You connect to `site.geo.subdomain.foo.onion` to `GET` a URL via HTTPS in the normal way 86 | 87 | 2. and you observe that the rightmost label of the TLD is .onion 88 | 89 | 3. and that `site.geo.subdomain.foo.onion` offers you a certificate 90 | 91 | 1. then you **MUST** confirm that you have an opt-in setting enabled (probably default in 92 | TorBrowser) 93 | 94 | 2. and you **MUST** confirm that the certificate satisfies ALL of the conditions of being a 95 | valid SOOC certificate with the baseDomain of `foo.onion` 96 | 97 | 3. and you **MUST** confirm that the baseDomain for the certificate, matches the rightmost two 98 | labels of the URL site 99 | 100 | 4. and you **MUST** confirm that the certificate's subjectAlternativeNames would successfully 101 | match `site.geo.subdomain.foo.onion` 102 | 103 | 4. If all of the above are confirmed, then your certificate validation code **MUST** skip checking 104 | the certificiate trust chain. 105 | 106 | # Why SOOC is Necessary 107 | 108 | There are many reasons why the Internet and WWW are equipped with a public key infrastructure (PKI), 109 | and the PKI offers many features and benefits; however its inarguable primary function is to provide 110 | a form of identity assurance, that when a person types a hostname such as "www.example.com" into a 111 | web browser's URL bar, they should have some reasonable expectation - and ideally a strong guarantee 112 | - that the network-connected-service from which they are eventually served content is one that would 113 | commonly be accepted as being capable, permitted and expected to serve content which people who own 114 | the "www.example.com" intentionally supply. 115 | 116 | The PKI mechanism has evolved to provide such identity assurance in a heavily-layered network 117 | environment which lacks overarching trust mechanisms and which is riven with potential for attack at 118 | (or: across) different layers. 119 | 120 | For instance: 121 | 122 | * ARP: first-hop, last-hop, or indeed any other hop may be hijacked with spoofed layer-2 address 123 | resolution; indeed some firewall devices rely upon this mechanism for their function 124 | 125 | * TCP: traffic may be blocked, dropped, modified, injected, or redirected to fake machines 126 | 127 | * BGP: bearer traffic and entire flows may be blocked, dropped, or redirected to fake machines 128 | 129 | * DNS: namespaces can be domain-jacked, responses can be forged, cache-poisoned, or simply 130 | tampered-with in flight, also homoglyph "lookalike" domains (eg: www.examp1e.com) are also 131 | possible 132 | 133 | The benefits of any intra-layer trust mechanism - eg: IPsec Authentication Header (AH) & 134 | Encapsulating Security Payload (ESP) at layer-3 - are typically isolated and not known to other 135 | layers of the stack - eg: the web browser - which therefore cannot take consideration of their 136 | benefits. 137 | 138 | In this environment our HTTPS ecosystem has evolved in the expectation of ignoring transport 139 | security - such as IPsec - and has instead has built its own, where a server's "identity" may be 140 | provisionally bootstrapped by DNS resolution of of a layer-3 IP address, however that identity 141 | **MUST** be proven by proof-of-possession of a cryptographic key that has been blessed by a trusted 142 | authority as pertaining to "www.example.com". 143 | 144 | The extent of such blessing is variable: for DV certificates the requisite test is one of consistent 145 | DNS resolution (eg: LetsEncrypt); and for EV certificates there are additional, expensive, and 146 | arguably superfluous corporate identity checks. 147 | 148 | ## Onion Networking compared to TLS PKI 149 | 150 | Tor "onion networking" is an alternate, software-defined, flat layer-3 network space which exists on 151 | top of TCP/IP and the rest of the internet. 152 | 153 | Onion addresses are either hashes of (in 80-bit version 2 addresses), or are literally and entirely 154 | (in 256-bit version 3 addresses) the public keys which sign all data that pertains to communication 155 | with that address. 156 | 157 | Like most cryptographic keys, onion addresses appear essentially to be strings of random bits, 158 | although it's possible via "mining" to eventually generate one which appears meaningful to human 159 | beings, eg: "facebookcorewwwi.onion" 160 | 161 | For purposes of PKI, the most interesting aspect of onion addresses is their textual representation; 162 | unlike IPv4's "dotted quads" or IPv6's colon-separated hexadecimal, onion addresses are required 163 | ([@RFC7686] section 1) to be written in a DNS-compatible text format: as base-32 encoded binary with 164 | addition of the IANA Special-Use Domain Name suffix, ".onion", and they are interpreted ignoring any 165 | labels other than the rightmost two. 166 | 167 | Thus: the onion address "www.exampleonionaddr.onion" would be a version 2 onion address representing 168 | a server that possesses a 1024-bit RSA public key which has an 80-bit-truncated SHA-1 hash 169 | of 0x25c0c7ac8e6a1cd00c71 ([@RFC3548] base32 "EXAMPLEONIONADDR"); and where the "www" prefix 170 | hostname/subdomain will ignored, although if specified it will be passed onward in an HTTPS "Host:" 171 | header. 172 | 173 | This representation pierces all of the layers of the network stack, and in one encoding it addresses 174 | most of the problems which the TLS PKI stack has gradually evolved to solve for TCP/IP: 175 | 176 | * There is no DNS name resolution service in onion networking, and in fact [@RFC7686] section 2 177 | specifies that there **MUST NOT** be overlap with DNS; this is an important point to which we 178 | will return later. 179 | 180 | * What the user types into the browser bar will defacto prove what site they are connected to; the 181 | Tor Onion Network at layer 3 will consequently assert "proof-of-possession of a cryptographic 182 | key" that will correspond absolutely to the remote service; this is isomorphic to the model of a 183 | TLS certificate proving the identity of a webserver. 184 | 185 | * Because onion addresses are layer-3 addresses, there is no concept of "subdomains" nor of 186 | "hostnames" and therefore any such information is considered "advisory"; however in this format 187 | they are backwards compatible in a way that "subdomains" for "dotted quad" addresses would not 188 | be, eg: "www.192.168.1.1" 189 | 190 | * All other connectivity redirections or "hijacks" are inhibited by the Tor network stack. 191 | 192 | # SOOC In Context 193 | 194 | As described above, the security characteristics and protections of layer-3 networking (eg: IPsec) 195 | are generally not visible to HTTPS applications at layer-7, and therefore cannot be relied upon. 196 | 197 | However: the encoding of onion addresses explicitly solves this problem: 198 | 199 | * The connection **must** be an onion connection, because it was made using Tor-capable software, 200 | and because the ".onion" Special Use Domain Name is reserved for that purpose. 201 | 202 | * The connection **must** be to "exampleonionaddr.onion" because the Tor network will not permit 203 | otherwise. 204 | 205 | * Any subdomain or hostname is subordinate to the fact that the connection is made to 206 | "exampleonionaddr.onion", because (as a layer-3 address) there are actually no such things as 207 | "subdomains" or "hostnames", and thus this information is purely advisory, or for compatability. 208 | 209 | Therefore it is possible for a client to assure itself - when presented with a TLS certificate for 210 | "www.exampleonionaddr.onion" - to assure itself that it is genuinely and authoritatively connected 211 | to "exampleonionaddr.onion" by simply performing a string comparison with the hostname to which 212 | is it connected - without any reference to a certificate authority trust chain nor any other third 213 | party resource. 214 | 215 | This observation is the basis of "Same Origin Onion Certificate" checking; that onion sites 216 | may offer (eg: homebrew DV-compliant) TLS certificates which correspond solely and uniquely to 217 | themselves, and under those limited circumstances the client may skip the certificate chain checks 218 | that might otherwise be required to validate identity. 219 | 220 | # SOOC Edge-Cases, and "SOOC-EV" 221 | 222 | It is necessary to recognise that there is one "weak" spot in the assertion that string 223 | comparison is sufficient to prove the binding between an Onion Address and a SSL Certificate 224 | SubjectAlternativeName, and that is in a scenario where the content webserver has been been deployed 225 | on one (or more) machines which are separate from the machine that terminates (i.e.: "hosts") 226 | the Onion Address AND, where the Tor daemon makes a direct TCP-level connection onwards to those 227 | servers. 228 | 229 | Those unfamiliar with how Tor works, may analogise this as "port-forwarding over SSH, where a port 230 | on the local host is forwarded to the remote server, which then forwards the data further onwards 231 | over a fresh TCP connection to a given port on a separate, third-party machine." 232 | 233 | The threat is: if a malicious actor can present themselves to the server-side Tor daemon as 234 | the IP address of the "third party" webserver - for instance a load-balancer, or a member of a 235 | load-balanced server tier - then under SOOC the malicious actor who achieves this could create a 236 | certificate permitthing them to impersonate a genuine SSL-certificate-enabled system *for* that 237 | onion address. 238 | 239 | This is a question of trust boundaries and real world deployments; at the moment the "onion 240 | networking" service space is broadly comprised of unencrypted HTTP, and as such any typical onion 241 | service deployment which uses a load-balancer would already be at risk of this attack. As such, 242 | currently lacking TLS-layer security, almost nobody typically deploys their onion server backend 243 | in a manner which could fall victim to this. Most onion HTTP services are typically served over 244 | loopback. 245 | 246 | Equally: any onion site which uses a "rewriter" reverse-proxy (e.g.: New York Times, BBC, Deutsche 247 | Welle, Propublica, Internet Archive) is also typically NOT at risk from this attack, because the 248 | inbound HTTPS request is terminated on the "onion" host, immediately rewritten in terms of the 249 | address of the upstream service, and is passed over loopback onward as a fresh HTTPS reverse-proxy 250 | connection. 251 | 252 | As far as the author is aware, the only onion service deployment where the above threat scenario 253 | would be a potential issue, is at Facebook; and if the Facebook devops team are at risk of someone 254 | interposing a fake server and server certificate into their infrastructure, then they have far 255 | bigger problems than mere onion service impersonation. 256 | 257 | ## Advanced Mitigations: SOOC-EV 258 | 259 | Generally at this point, enthusiastic cryptographers will point at Version 3 Onion Addresses and 260 | note that they are actual public keys, and "couldn't they just sign the SOOC Certificate, and the 261 | browser would check the signature, and that would be the end of the problem?" 262 | 263 | They are correct to say this, however this raises two problems: 264 | 265 | 1. This would orphan Version 2 Onion addresses without SOOC, expressly against the intent of this 266 | document. 267 | 268 | 2. The Version 3 Onion addresses are (by Tor policy) never used to sign anything 269 | 270 | 271 | Quote: 272 | 273 | > Master (hidden service) identity key -- A master signing keypair used as the identity for a 274 | > hidden service. This key is long term and not used on its own to sign anything; it is only used to 275 | > generate blinded signing keys as described in [KEYBLIND] 276 | 277 | In Version 3 Onion Addressing, the address-key is used to derive short-term, time-locked, "blinded" 278 | keys in a fixed manner that can be replicated by a client which wishes to connect to the master 279 | onion address. The blinded keys are used to sign connection information that is loaded up into the 280 | "HSDir" distributed hash-table that describes Onion connectivity. 281 | 282 | Ergo: to implement a form of "Extended Validation" certificate extension that would bind a TLS 283 | certificate to an onion address, the certificate would have to contain the onion public key (for V2) 284 | or a blinded public key for a reasonable timestamp (for V3), and this public key would be used to 285 | validate a hash of some portion of the certificate, all in order to address this niche deployment 286 | risk. 287 | 288 | This is certainly possible to achieve, and is fairly straightforward, however it is a tremendous 289 | hassle for a niche risk, and I believe that it should not be an progress to implmenting SOOC without 290 | implementing these "Extended Validation"-type checks. 291 | 292 | My rationale for deferring SOOC-EV - apart from the nicheness aspect - is also bolstered by the 293 | observation that "Appendix F" of CA/B-Forum Ballot 144: 294 | 295 | 296 | 297 | This describes the "CAB Forum Tor Service Descriptor Hash Extension", a hash of the V2 Onion Public 298 | Key which Certificate Authorities are obliged to bind into the EV TLS Onion Certificates that they 299 | issue, ostensibly to both link the onion public key more tightly to the TLS certificate in the event 300 | that a colliding V2 Onion address is generated, but also to protect against the above described 301 | kinds of attack. 302 | 303 | There exists absolutely no client code actually implemented to check for, nor validate, this 304 | descriptor, to the extent that when Digicert misissued a certificate without the extension (compare 305 | with , no-one actually noticed, except 306 | for Digicert. 307 | 308 | As such, I don't believe that this attack is currently worthy of consideration, especially as it 309 | is within the power of the service provider to mitigate in alternative ways, and in any case we may 310 | still evolve towards SOOC-EV as the the technology matures. 311 | 312 | To be clear: I do believe that SOOC-EV should probably be done. But I do not believe that it should 313 | be a pre-requisite condition for SOOC, nor is it necessary to do it "now", nor is any threat great 314 | enough to block SOOC until SOOC-EV is defined. Apart from the reasons stated above, there is likely 315 | still some need for V3 Onion Address blinding and key-derivation algorithms to mature and prove 316 | stability in deployments for a few years. 317 | 318 | ## Reciprocal Attack: Shared Tor Gateways? 319 | 320 | Having comprehended the above, there is also obviously a reciprocal risk which can be stated: 321 | 322 | * What about shared onion gateways? What if many people use one Tor proxy to access Tor? One could 323 | interpose a fake SOCKS5 man-in-the-middle and respond to Onion connection requests with a fake 324 | SOOC TLS certificate! 325 | 326 | The response to which, again, is that although such may happen experimentally, the overwhelming 327 | means by which people access Tor is by using a local client over loopback, one (or more) per user. 328 | At the "client" end, access to the Tor proxy is within the local trust boundary, where worse things 329 | can happen. 330 | 331 | # Linkfarm TBD 332 | 333 | For more on Onion Networking as a layer-3 network, see: 334 | 335 | 336 | IANA Special-Use Domain Names 337 | 338 | 339 | Facebook Onion Announcement 340 | 341 | 342 | # Topics for possible expansion 343 | 344 | * SOOC Use Cases 345 | 346 | * SOOC and Certificate Transparency 347 | 348 | * SOOC and DV Certificates 349 | 350 | - Potential negative consequences of DV certificates for Onion Addresses 351 | 352 | * SOOC and EV Certificates 353 | 354 | * SOOC and HSTS 355 | 356 | * SOOC and LetsEncrypt 357 | 358 | * SOOC to complement, not replace, EV (and perhaps DV) 359 | 360 | {backmatter} 361 | -------------------------------------------------------------------------------- /text/draft-muffett-same-origin-onion-certificates.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Same Origin Onion Certificates 7 | 8 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 874 | 875 | 876 | 877 | 937 | 938 | 939 | 940 | 941 | 942 | 943 | 944 | 945 | 946 | 947 | 948 |
Internet-DraftsoocMarch 2020
MuffettExpires 18 September 2020[Page]
949 |
950 |
951 |
Workgroup:
952 |
Transport Layer Security
953 |
Internet-Draft:
954 |
draft-muffett-same-origin-onion-certificates-00
955 |
Published:
956 |
957 | 958 |
959 |
Intended Status:
960 |
Informational
961 |
Expires:
962 |
963 |
Author:
964 |
965 |
966 |
A. Muffett
967 |
Independent
968 |
969 |
970 |
971 |
972 |

Same Origin Onion Certificates

973 |
974 |

Abstract

975 |

Onion networking [RFC7686] offers technical features which obviate 976 | many of the risks upon which led to the development of our modern 977 | Certificate Authority Public Key Infrastructure; as an increasingly 978 | popular technology for networking with strong trust requirements, 979 | onion networking would benefit from easier access to TLS certificates 980 | for HTTPS use.

981 |

At the moment only EV certificates are available for onion network 982 | addresses, although DV certificates are under discussion; the 983 | potential downsides of issuing DV certificates for Onion Addresses are 984 | discussed below.

985 |

This document defines a third possible mechanism - SOOC: Same Origin 986 | Onion Certificates - that would enable real-time, client-side 987 | validation of per-onion-address TLS certificates, fully equivalent (in 988 | defined circumstances) to validation of a certificate trust chain, but 989 | involving none of third parties, trust chains, or financial cost.

990 |

In the simpest possible terms, SOOC is not a "self-signed 991 | certificate" proposal; instead it is a proposal that "in very limited 992 | circumstances, we shall not care about signatures at all", with a 993 | codicil regarding how this may be improved in future.

994 |

This distinction is important because it highlights that the initial 995 | implementation of SOOC certificates contain no additional features 996 | above or beyond the specifications of standard DV certificates, and 997 | require no tools to create other than standard openssl or mkcert 998 | to create. This is part of the value proposition of SOOC, in order to 999 | lower the barriers to adoption by small sites and experimenters with 1000 | limited experience of TLS.

1001 |
1002 |
1003 |
1004 |

1005 | Status of This Memo 1006 |

1007 |

1008 | This Internet-Draft is submitted in full conformance with the 1009 | provisions of BCP 78 and BCP 79.

1010 |

1011 | Internet-Drafts are working documents of the Internet Engineering Task 1012 | Force (IETF). Note that other groups may also distribute working 1013 | documents as Internet-Drafts. The list of current Internet-Drafts is 1014 | at https://datatracker.ietf.org/drafts/current/.

1015 |

1016 | Internet-Drafts are draft documents valid for a maximum of six months 1017 | and may be updated, replaced, or obsoleted by other documents at any 1018 | time. It is inappropriate to use Internet-Drafts as reference 1019 | material or to cite them other than as "work in progress."

1020 |

1021 | This Internet-Draft will expire on 18 September 2020.

1022 |
1023 |
1024 | 1044 |
1045 |
1046 | ▲

1047 | Table of Contents 1048 |

1049 | 1092 |
1093 |
1094 |
1095 |
1096 |

1097 | 1. SOOC Certificate Specification 1098 |

1099 |

Using the Public Suffix List, let baseDomain be the Registrable 1100 | Domain of the connected origin, e.g., abcdefghijklmnop.onion

1101 |
    1102 |
  1. 1103 |

    A SOOC Certificate is a properly formatted DV or EV TLS 1104 | certificate, per the browser's concept of web standards

    1105 |
    2. 1106 |
  2. 1107 |

    where the certificate, if the browser were to trust the 1108 | certificate's trust chain, would otherwise be a fully valid and 1109 | trusted certificate

    1110 |
    3. 1111 |
  3. 1112 |

    where the certificate, if it has a basicConstraints extension, that 1113 | extension MUST only be CA:FALSE

    1114 |
    4. 1115 |
  4. 1116 |

    where the certificate, if it has a commonName, that commonName 1117 | MUST be equal to the baseDomain as defined above

    1118 |
    5. 1119 |
  5. 1120 |

    where the certificate, if it has subjectAlternativeNames, those 1121 | subjectAlternativeNames MUST all be of type dNSname, MUST 1122 | all be of valid DV format (wildcards permitted) and each of which 1123 | MUST have the baseDomain as the rightmost two labels.

    1124 |
    6. 1125 |
  6. 1126 |

    where the certificate, if it cites any subjectAlternativeNames or 1127 | other regisitrable domains, all of those subjectAlternativeNames or 1128 | other registrable domains MUST have the baseDomain as the 1129 | rightmost two labels.

    1130 |
    7. 1131 |
1132 |

If all of these contstraints are satisfied, the certificate is a valid 1133 | SOOC certificate.

1134 |
1135 |
1136 |
1137 |
1138 |

1139 | 2. SOOC Example Protocol 1140 |

1141 |

If you are a Browser, and...

1142 |
    1143 |
  1. 1144 |

    You connect to site.geo.subdomain.foo.onion to GET a URL via 1145 | HTTPS in the normal way

    1146 |
    2. 1147 |
  2. 1148 |

    and you observe that the rightmost label of the TLD is .onion

    1149 |
    3. 1150 |
  3. 1151 |

    and that site.geo.subdomain.foo.onion offers you a certificate

    1152 |
      1153 |
    1. 1154 |

      then you MUST confirm that you have an opt-in setting enabled 1155 | (probably default in TorBrowser)

      1156 |
      2. 1157 |
    2. 1158 |

      and you MUST confirm that the certificate satisfies ALL of the 1159 | conditions of being a valid SOOC certificate with the baseDomain 1160 | of foo.onion

      1161 |
      3. 1162 |
    3. 1163 |

      and you MUST confirm that the baseDomain for the certificate, 1164 | matches the rightmost two labels of the URL site

      1165 |
      4. 1166 |
    4. 1167 |

      and you MUST confirm that the certificate's 1168 | subjectAlternativeNames would successfully match 1169 | site.geo.subdomain.foo.onion

      1170 |
      5. 1171 |
    1172 |
    4. 1173 |
  4. 1174 |

    If all of the above are confirmed, then your certificate validation 1175 | code MUST skip checking the certificiate trust chain.

    1176 |
    5. 1177 |
1178 |
1179 |
1180 |
1181 |
1182 |

1183 | 3. Why SOOC is Necessary 1184 |

1185 |

There are many reasons why the Internet and WWW are equipped with a 1186 | public key infrastructure (PKI), and the PKI offers many features and 1187 | benefits; however its inarguable primary function is to provide a form 1188 | of identity assurance, that when a person types a hostname such as 1189 | "www.example.com" into a web browser's URL bar, they should have some 1190 | reasonable expectation - and ideally a strong guarantee - that the 1191 | network-connected-service from which they are eventually served 1192 | content is one that would commonly be accepted as being capable, 1193 | permitted and expected to serve content which people who own the 1194 | "www.example.com" intentionally supply.

1195 |

The PKI mechanism has evolved to provide such identity assurance in a 1196 | heavily-layered network environment which lacks overarching trust 1197 | mechanisms and which is riven with potential for attack at (or: 1198 | across) different layers.

1199 |

For instance:

1200 |
    1201 |
  • 1202 |

    ARP: first-hop, last-hop, or indeed any other hop may be hijacked 1203 | with spoofed layer-2 address resolution; indeed some firewall 1204 | devices rely upon this mechanism for their function

    1205 |
    • 1206 |
  • 1207 |

    TCP: traffic may be blocked, dropped, modified, injected, or 1208 | redirected to fake machines

    1209 |
    • 1210 |
  • 1211 |

    BGP: bearer traffic and entire flows may be blocked, dropped, or 1212 | redirected to fake machines

    1213 |
    • 1214 |
  • 1215 |

    DNS: namespaces can be domain-jacked, responses can be forged, 1216 | cache-poisoned, or simply tampered-with in flight, also homoglyph 1217 | "lookalike" domains (eg: www.examp1e.com) are also possible

    1218 |
    • 1219 |
1220 |

The benefits of any intra-layer trust mechanism - eg: IPsec 1221 | Authentication Header (AH) & Encapsulating Security Payload (ESP) at 1222 | layer-3 - are typically isolated and not known to other layers of the 1223 | stack - eg: the web browser - which therefore cannot take 1224 | consideration of their benefits.

1225 |

In this environment our HTTPS ecosystem has evolved in the expectation 1226 | of ignoring transport security - such as IPsec - and has instead has 1227 | built its own, where a server's "identity" may be provisionally 1228 | bootstrapped by DNS resolution of of a layer-3 IP address, however 1229 | that identity MUST be proven by proof-of-possession of a 1230 | cryptographic key that has been blessed by a trusted authority as 1231 | pertaining to "www.example.com".

1232 |

The extent of such blessing is variable: for DV certificates the 1233 | requisite test is one of consistent DNS resolution (eg: LetsEncrypt); 1234 | and for EV certificates there are additional, expensive, and arguably 1235 | superfluous corporate identity checks.

1236 |
1237 |
1238 |

1239 | 3.1. Onion Networking compared to TLS PKI 1240 |

1241 |

Tor "onion networking" is an alternate, software-defined, flat layer-3 1242 | network space which exists on top of TCP/IP and the rest of the 1243 | internet.

1244 |

Onion addresses are either hashes of (in 80-bit version 2 addresses), 1245 | or are literally and entirely (in 256-bit version 3 addresses) the 1246 | public keys which sign all data that pertains to communication with 1247 | that address.

1248 |

Like most cryptographic keys, onion addresses appear essentially to be 1249 | strings of random bits, although it's possible via "mining" to 1250 | eventually generate one which appears meaningful to human beings, eg: 1251 | "facebookcorewwwi.onion"

1252 |

For purposes of PKI, the most interesting aspect of onion addresses is 1253 | their textual representation; unlike IPv4's "dotted quads" or IPv6's 1254 | colon-separated hexadecimal, onion addresses are required ([RFC7686] 1255 | section 1) to be written in a DNS-compatible text format: as base-32 1256 | encoded binary with addition of the IANA Special-Use Domain Name 1257 | suffix, ".onion", and they are interpreted ignoring any labels other 1258 | than the rightmost two.

1259 |

Thus: the onion address "www.exampleonionaddr.onion" would be a 1260 | version 2 onion address representing a server that possesses a 1261 | 1024-bit RSA public key which has an 80-bit-truncated SHA-1 hash of 1262 | 0x25c0c7ac8e6a1cd00c71 ([RFC3548] base32 "EXAMPLEONIONADDR"); and 1263 | where the "www" prefix hostname/subdomain will ignored, although if 1264 | specified it will be passed onward in an HTTPS "Host:" header.

1265 |

This representation pierces all of the layers of the network stack, 1266 | and in one encoding it addresses most of the problems which the TLS 1267 | PKI stack has gradually evolved to solve for TCP/IP:

1268 |
    1269 |
  • 1270 |

    There is no DNS name resolution service in onion networking, and in 1271 | fact [RFC7686] section 2 specifies that there MUST NOT be 1272 | overlap with DNS; this is an important point to which we will return 1273 | later.

    1274 |
    • 1275 |
  • 1276 |

    What the user types into the browser bar will defacto prove what 1277 | site they are connected to; the Tor Onion Network at layer 3 will 1278 | consequently assert "proof-of-possession of a cryptographic key" 1279 | that will correspond absolutely to the remote service; this is 1280 | isomorphic to the model of a TLS certificate proving the identity of 1281 | a webserver.

    1282 |
    • 1283 |
  • 1284 |

    Because onion addresses are layer-3 addresses, there is no concept 1285 | of "subdomains" nor of "hostnames" and therefore any such 1286 | information is considered "advisory"; however in this format they 1287 | are backwards compatible in a way that "subdomains" for "dotted 1288 | quad" addresses would not be, eg: "www.192.168.1.1"

    1289 |
    • 1290 |
  • 1291 |

    All other connectivity redirections or "hijacks" are inhibited by 1292 | the Tor network stack.

    1293 |
    • 1294 |
1295 |
1296 |
1297 |
1298 |
1299 |
1300 |
1301 |

1302 | 4. SOOC In Context 1303 |

1304 |

As described above, the security characteristics and protections of 1305 | layer-3 networking (eg: IPsec) are generally not visible to HTTPS 1306 | applications at layer-7, and therefore cannot be relied upon.

1307 |

However: the encoding of onion addresses explicitly solves this problem:

1308 |
    1309 |
  • 1310 |

    The connection must be an onion connection, because it was made 1311 | using Tor-capable software, and because the ".onion" Special Use 1312 | Domain Name is reserved for that purpose.

    1313 |
    • 1314 |
  • 1315 |

    The connection must be to "exampleonionaddr.onion" because the 1316 | Tor network will not permit otherwise.

    1317 |
    • 1318 |
  • 1319 |

    Any subdomain or hostname is subordinate to the fact that the 1320 | connection is made to "exampleonionaddr.onion", because (as a 1321 | layer-3 address) there are actually no such things as "subdomains" 1322 | or "hostnames", and thus this information is purely advisory, or for 1323 | compatability.

    1324 |
    • 1325 |
1326 |

Therefore it is possible for a client to assure itself - when 1327 | presented with a TLS certificate for "www.exampleonionaddr.onion" - to 1328 | assure itself that it is genuinely and authoritatively connected to 1329 | "exampleonionaddr.onion" by simply performing a string comparison with 1330 | the hostname to which is it connected - without any reference to a 1331 | certificate authority trust chain nor any other third party resource.

1332 |

This observation is the basis of "Same Origin Onion Certificate" 1333 | checking; that onion sites may offer (eg: homebrew DV-compliant) TLS 1334 | certificates which correspond solely and uniquely to themselves, and 1335 | under those limited circumstances the client may skip the certificate 1336 | chain checks that might otherwise be required to validate identity.

1337 |
1338 |
1339 |
1340 |
1341 |

1342 | 5. SOOC Edge-Cases, and "SOOC-EV" 1343 |

1344 |

It is necessary to recognise that there is one "weak" spot in the 1345 | assertion that string comparison is sufficient to prove the binding 1346 | between an Onion Address and a SSL Certificate SubjectAlternativeName, and 1347 | that is in a scenario where the content webserver has been been 1348 | deployed on one (or more) machines which are separate from the machine 1349 | that terminates (i.e.: "hosts") the Onion Address AND, where the Tor 1350 | daemon makes a direct TCP-level connection onwards to those servers.

1351 |

Those unfamiliar with how Tor works, may analogise this as 1352 | "port-forwarding over SSH, where a port on the local host is forwarded 1353 | to the remote server, which then forwards the data further onwards 1354 | over a fresh TCP connection to a given port on a separate, third-party 1355 | machine."

1356 |

The threat is: if a malicious actor can present themselves to the 1357 | server-side Tor daemon as the IP address of the "third party" 1358 | webserver - for instance a load-balancer, or a member of a 1359 | load-balanced server tier - then under SOOC the malicious actor who 1360 | achieves this could create a certificate permitthing them to 1361 | impersonate a genuine SSL-certificate-enabled system for that onion 1362 | address.

1363 |

This is a question of trust boundaries and real world deployments; at 1364 | the moment the "onion networking" service space is broadly comprised 1365 | of unencrypted HTTP, and as such any typical onion service deployment 1366 | which uses a load-balancer would already be at risk of this attack. 1367 | As such, currently lacking TLS-layer security, almost nobody typically 1368 | deploys their onion server backend in a manner which could fall victim 1369 | to this. Most onion HTTP services are typically served over loopback.

1370 |

Equally: any onion site which uses a "rewriter" reverse-proxy (e.g.: 1371 | New York Times, BBC, Deutsche Welle, Propublica, Internet Archive) is 1372 | also typically NOT at risk from this attack, because the inbound HTTPS 1373 | request is terminated on the "onion" host, immediately rewritten in 1374 | terms of the address of the upstream service, and is passed over 1375 | loopback onward as a fresh HTTPS reverse-proxy connection.

1376 |

As far as the author is aware, the only onion service deployment where 1377 | the above threat scenario would be a potential issue, is at Facebook; 1378 | and if the Facebook devops team are at risk of someone interposing a 1379 | fake server and server certificate into their infrastructure, then 1380 | they have far bigger problems than mere onion service impersonation.

1381 |
1382 |
1383 |

1384 | 5.1. Advanced Mitigations: SOOC-EV 1385 |

1386 |

Generally at this point, enthusiastic cryptographers will point at 1387 | Version 3 Onion Addresses and note that they are actual public keys, 1388 | and "couldn't they just sign the SOOC Certificate, and the browser 1389 | would check the signature, and that would be the end of the problem?"

1390 |

They are correct to say this, however this raises two problems:

1391 |
    1392 |
  1. 1393 |

    This would orphan Version 2 Onion addresses without SOOC, expressly 1394 | against the intent of this document.

    1395 |
    2. 1396 |
  2. 1397 |

    The Version 3 Onion addresses are (by Tor policy) never used to 1398 | sign anything https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n557

    1399 |
    3. 1400 |
1401 |

Quote:

1402 |
1403 |

Master (hidden service) identity key -- A master signing keypair 1404 | used as the identity for a hidden service. This key is long term and 1405 | not used on its own to sign anything; it is only used to generate 1406 | blinded signing keys as described in [KEYBLIND]

1407 |
1408 |

In Version 3 Onion Addressing, the address-key is used to derive 1409 | short-term, time-locked, "blinded" keys in a fixed manner that can be 1410 | replicated by a client which wishes to connect to the master onion 1411 | address. The blinded keys are used to sign connection information 1412 | that is loaded up into the "HSDir" distributed hash-table that 1413 | describes Onion connectivity.

1414 |

Ergo: to implement a form of "Extended Validation" certificate 1415 | extension that would bind a TLS certificate to an onion address, the 1416 | certificate would have to contain the onion public key (for V2) or a 1417 | blinded public key for a reasonable timestamp (for V3), and this 1418 | public key would be used to validate a hash of some portion of the 1419 | certificate, all in order to address this niche deployment risk.

1420 |

This is certainly possible to achieve, and is fairly straightforward, 1421 | however it is a tremendous hassle for a niche risk, and I believe that 1422 | it should not be an progress to implmenting SOOC without implementing 1423 | these "Extended Validation"-type checks.

1424 |

My rationale for deferring SOOC-EV - apart from the nicheness aspect - 1425 | is also bolstered by the observation that "Appendix F" of CA/B-Forum 1426 | Ballot 144:

1427 |

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

1428 |

This describes the "CAB Forum Tor Service Descriptor Hash Extension", 1429 | a hash of the V2 Onion Public Key which Certificate Authorities are 1430 | obliged to bind into the EV TLS Onion Certificates that they issue, 1431 | ostensibly to both link the onion public key more tightly to the TLS 1432 | certificate in the event that a colliding V2 Onion address is 1433 | generated, but also to protect against the above described kinds of 1434 | attack.

1435 |

There exists absolutely no client code actually implemented to check 1436 | for, nor validate, this descriptor, to the extent that when Digicert 1437 | misissued a certificate without the extension (compare 1438 | https://crt.sh/?id=240277340 with https://crt.sh/?id=241547157), 1439 | no-one actually noticed, except for Digicert.

1440 |

As such, I don't believe that this attack is currently worthy of 1441 | consideration, especially as it is within the power of the service 1442 | provider to mitigate in alternative ways, and in any case we may still 1443 | evolve towards SOOC-EV as the the technology matures.

1444 |

To be clear: I do believe that SOOC-EV should probably be done. But I 1445 | do not believe that it should be a pre-requisite condition for SOOC, 1446 | nor is it necessary to do it "now", nor is any threat great enough to 1447 | block SOOC until SOOC-EV is defined. Apart from the reasons stated 1448 | above, there is likely still some need for V3 Onion Address blinding 1449 | and key-derivation algorithms to mature and prove stability in 1450 | deployments for a few years.

1451 |
1452 |
1453 |
1454 |
1455 |

1456 | 5.2. Reciprocal Attack: Shared Tor Gateways? 1457 |

1458 |

Having comprehended the above, there is also obviously a reciprocal 1459 | risk which can be stated:

1460 |
    1461 |
  • 1462 |

    What about shared onion gateways? What if many people use one Tor 1463 | proxy to access Tor? One could interpose a fake SOCKS5 1464 | man-in-the-middle and respond to Onion connection requests with a 1465 | fake SOOC TLS certificate!

    1466 |
    • 1467 |
1468 |

The response to which, again, is that although such may happen 1469 | experimentally, the overwhelming means by which people access Tor is 1470 | by using a local client over loopback, one (or more) per user. At the 1471 | "client" end, access to the Tor proxy is within the local trust 1472 | boundary, where worse things can happen.

1473 |
1474 |
1475 |
1476 |
1477 |
1478 |
1479 |

1480 | 6. Linkfarm TBD 1481 |

1482 |

For more on Onion Networking as a layer-3 network, see: 1483 | https://www.youtube.com/watch?v=pebRZyg_bh8

1484 |

IANA Special-Use Domain Names 1485 | https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

1486 |

Facebook Onion Announcement 1487 | https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237/

1488 |
1489 |
1490 |
1491 |
1492 |

1493 | 7. Topics for possible expansion 1494 |

1495 |
    1496 |
  • 1497 |

    SOOC Use Cases

    1498 |
    • 1499 |
  • 1500 |

    SOOC and Certificate Transparency

    1501 |
    • 1502 |
  • 1503 |

    SOOC and DV Certificates

    1504 |
      1505 |
    • 1506 |

      Potential negative consequences of DV certificates for Onion Addresses

      1507 |
      • 1508 |
    1509 |
    • 1510 |
  • 1511 |

    SOOC and EV Certificates

    1512 |
    • 1513 |
  • 1514 |

    SOOC and HSTS

    1515 |
    • 1516 |
  • 1517 |

    SOOC and LetsEncrypt

    1518 |
    • 1519 |
  • 1520 |

    SOOC to complement, not replace, EV (and perhaps DV)

    1521 |
    • 1522 |
1523 |
1524 |
1525 |
1526 |

1527 | 8. Informative References 1528 |

1529 |
1530 |
[RFC3548]
1531 |
1532 | Josefsson, S., Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, DOI 10.17487/RFC3548, 1533 | , <https://www.rfc-editor.org/info/rfc3548>.
1534 |
[RFC7686]
1535 |
1536 | Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, 1537 | , <https://www.rfc-editor.org/info/rfc7686>.
1538 |
1539 |
1540 |
1541 |
1542 |

1543 | Author's Address 1544 |

1545 |
1546 |
Alec Muffett
1547 |
Independent
1548 | 1552 |
1553 |
1554 |
1555 | 1595 | 1596 | 1597 | -------------------------------------------------------------------------------- /text/draft-muffett-same-origin-onion-certificates.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Transport Layer Security A. Muffett 6 | Internet-Draft Independent 7 | Intended status: Informational 17 March 2020 8 | Expires: 18 September 2020 9 | 10 | 11 | Same Origin Onion Certificates 12 | draft-muffett-same-origin-onion-certificates-00 13 | 14 | Abstract 15 | 16 | Onion networking [RFC7686] offers technical features which obviate 17 | many of the risks upon which led to the development of our modern 18 | Certificate Authority Public Key Infrastructure; as an increasingly 19 | popular technology for networking with strong trust requirements, 20 | onion networking would benefit from easier access to TLS certificates 21 | for HTTPS use. 22 | 23 | At the moment only EV certificates are available for onion network 24 | addresses, although DV certificates are under discussion; the 25 | potential downsides of issuing DV certificates for Onion Addresses 26 | are discussed below. 27 | 28 | This document defines a third possible mechanism - SOOC: Same Origin 29 | Onion Certificates - that would enable real-time, client-side 30 | validation of per-onion-address TLS certificates, fully equivalent 31 | (in defined circumstances) to validation of a certificate trust 32 | chain, but involving none of third parties, trust chains, or 33 | financial cost. 34 | 35 | In the simpest possible terms, SOOC is _not_ a "self-signed 36 | certificate" proposal; instead it is a proposal that "in very limited 37 | circumstances, we shall not care about signatures at all", with a 38 | codicil regarding how this may be improved in future. 39 | 40 | This distinction is important because it highlights that the initial 41 | implementation of SOOC certificates contain no additional features 42 | above or beyond the specifications of standard DV certificates, and 43 | require no tools to create other than standard "openssl" or "mkcert" 44 | to create. This is part of the value proposition of SOOC, in order 45 | to lower the barriers to adoption by small sites and experimenters 46 | with limited experience of TLS. 47 | 48 | Status of This Memo 49 | 50 | This Internet-Draft is submitted in full conformance with the 51 | provisions of BCP 78 and BCP 79. 52 | 53 | 54 | 55 | 56 | Muffett Expires 18 September 2020 [Page 1] 57 | 58 | Internet-Draft sooc March 2020 59 | 60 | 61 | Internet-Drafts are working documents of the Internet Engineering 62 | Task Force (IETF). Note that other groups may also distribute 63 | working documents as Internet-Drafts. The list of current Internet- 64 | Drafts is at https://datatracker.ietf.org/drafts/current/. 65 | 66 | Internet-Drafts are draft documents valid for a maximum of six months 67 | and may be updated, replaced, or obsoleted by other documents at any 68 | time. It is inappropriate to use Internet-Drafts as reference 69 | material or to cite them other than as "work in progress." 70 | 71 | This Internet-Draft will expire on 18 September 2020. 72 | 73 | Copyright Notice 74 | 75 | Copyright (c) 2020 IETF Trust and the persons identified as the 76 | document authors. All rights reserved. 77 | 78 | This document is subject to BCP 78 and the IETF Trust's Legal 79 | Provisions Relating to IETF Documents (https://trustee.ietf.org/ 80 | license-info) in effect on the date of publication of this document. 81 | Please review these documents carefully, as they describe your rights 82 | and restrictions with respect to this document. Code Components 83 | extracted from this document must include Simplified BSD License text 84 | as described in Section 4.e of the Trust Legal Provisions and are 85 | provided without warranty as described in the Simplified BSD License. 86 | 87 | Table of Contents 88 | 89 | 1. SOOC Certificate Specification . . . . . . . . . . . . . . . 2 90 | 2. SOOC Example Protocol . . . . . . . . . . . . . . . . . . . . 3 91 | 3. Why SOOC is Necessary . . . . . . . . . . . . . . . . . . . . 4 92 | 3.1. Onion Networking compared to TLS PKI . . . . . . . . . . 5 93 | 4. SOOC In Context . . . . . . . . . . . . . . . . . . . . . . . 6 94 | 5. SOOC Edge-Cases, and "SOOC-EV" . . . . . . . . . . . . . . . 7 95 | 5.1. Advanced Mitigations: SOOC-EV . . . . . . . . . . . . . . 8 96 | 5.2. Reciprocal Attack: Shared Tor Gateways? . . . . . . . . . 9 97 | 6. Linkfarm TBD . . . . . . . . . . . . . . . . . . . . . . . . 10 98 | 7. Topics for possible expansion . . . . . . . . . . . . . . . . 10 99 | 8. Informative References . . . . . . . . . . . . . . . . . . . 10 100 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 101 | 102 | 1. SOOC Certificate Specification 103 | 104 | Using the Public Suffix List, let "baseDomain" be the Registrable 105 | Domain of the connected origin, e.g., "abcdefghijklmnop.onion" 106 | 107 | 1. A SOOC Certificate is a properly formatted DV or EV TLS 108 | certificate, per the browser's concept of web standards 109 | 110 | 111 | 112 | Muffett Expires 18 September 2020 [Page 2] 113 | 114 | Internet-Draft sooc March 2020 115 | 116 | 117 | 2. where the certificate, if the browser were to trust the 118 | certificate's trust chain, would otherwise be a fully valid and 119 | trusted certificate 120 | 121 | 3. where the certificate, if it has a basicConstraints extension, 122 | that extension MUST only be CA:FALSE 123 | 124 | 4. where the certificate, if it has a commonName, that commonName 125 | MUST be equal to the baseDomain as defined above 126 | 127 | 5. where the certificate, if it has subjectAlternativeNames, those 128 | subjectAlternativeNames MUST all be of type dNSname, MUST all be 129 | of valid DV format (wildcards permitted) and each of which MUST 130 | have the baseDomain as the rightmost two labels. 131 | 132 | 6. where the certificate, if it cites any subjectAlternativeNames or 133 | other regisitrable domains, all of those subjectAlternativeNames 134 | or other registrable domains MUST have the baseDomain as the 135 | rightmost two labels. 136 | 137 | If all of these contstraints are satisfied, the certificate is a 138 | valid SOOC certificate. 139 | 140 | 2. SOOC Example Protocol 141 | 142 | If you are a Browser, and... 143 | 144 | 1. You connect to "site.geo.subdomain.foo.onion" to "GET" a URL via 145 | HTTPS in the normal way 146 | 147 | 2. and you observe that the rightmost label of the TLD is .onion 148 | 149 | 3. and that "site.geo.subdomain.foo.onion" offers you a certificate 150 | 151 | 1. then you MUST confirm that you have an opt-in setting enabled 152 | (probably default in TorBrowser) 153 | 154 | 2. and you MUST confirm that the certificate satisfies ALL of 155 | the conditions of being a valid SOOC certificate with the 156 | baseDomain of "foo.onion" 157 | 158 | 3. and you MUST confirm that the baseDomain for the certificate, 159 | matches the rightmost two labels of the URL site 160 | 161 | 4. and you MUST confirm that the certificate's 162 | subjectAlternativeNames would successfully match 163 | "site.geo.subdomain.foo.onion" 164 | 165 | 166 | 167 | 168 | Muffett Expires 18 September 2020 [Page 3] 169 | 170 | Internet-Draft sooc March 2020 171 | 172 | 173 | 4. If all of the above are confirmed, then your certificate 174 | validation code MUST skip checking the certificiate trust chain. 175 | 176 | 3. Why SOOC is Necessary 177 | 178 | There are many reasons why the Internet and WWW are equipped with a 179 | public key infrastructure (PKI), and the PKI offers many features and 180 | benefits; however its inarguable primary function is to provide a 181 | form of identity assurance, that when a person types a hostname such 182 | as "www.example.com" into a web browser's URL bar, they should have 183 | some reasonable expectation - and ideally a strong guarantee - that 184 | the network-connected-service from which they are eventually served 185 | content is one that would commonly be accepted as being capable, 186 | permitted and expected to serve content which people who own the 187 | "www.example.com" intentionally supply. 188 | 189 | The PKI mechanism has evolved to provide such identity assurance in a 190 | heavily-layered network environment which lacks overarching trust 191 | mechanisms and which is riven with potential for attack at (or: 192 | across) different layers. 193 | 194 | For instance: 195 | 196 | * ARP: first-hop, last-hop, or indeed any other hop may be hijacked 197 | with spoofed layer-2 address resolution; indeed some firewall 198 | devices rely upon this mechanism for their function 199 | 200 | * TCP: traffic may be blocked, dropped, modified, injected, or 201 | redirected to fake machines 202 | 203 | * BGP: bearer traffic and entire flows may be blocked, dropped, or 204 | redirected to fake machines 205 | 206 | * DNS: namespaces can be domain-jacked, responses can be forged, 207 | cache-poisoned, or simply tampered-with in flight, also homoglyph 208 | "lookalike" domains (eg: www.examp1e.com) are also possible 209 | 210 | The benefits of any intra-layer trust mechanism - eg: IPsec 211 | Authentication Header (AH) & Encapsulating Security Payload (ESP) at 212 | layer-3 - are typically isolated and not known to other layers of the 213 | stack - eg: the web browser - which therefore cannot take 214 | consideration of their benefits. 215 | 216 | In this environment our HTTPS ecosystem has evolved in the 217 | expectation of ignoring transport security - such as IPsec - and has 218 | instead has built its own, where a server's "identity" may be 219 | provisionally bootstrapped by DNS resolution of of a layer-3 IP 220 | address, however that identity MUST be proven by proof-of-possession 221 | 222 | 223 | 224 | Muffett Expires 18 September 2020 [Page 4] 225 | 226 | Internet-Draft sooc March 2020 227 | 228 | 229 | of a cryptographic key that has been blessed by a trusted authority 230 | as pertaining to "www.example.com". 231 | 232 | The extent of such blessing is variable: for DV certificates the 233 | requisite test is one of consistent DNS resolution (eg: LetsEncrypt); 234 | and for EV certificates there are additional, expensive, and arguably 235 | superfluous corporate identity checks. 236 | 237 | 3.1. Onion Networking compared to TLS PKI 238 | 239 | Tor "onion networking" is an alternate, software-defined, flat 240 | layer-3 network space which exists on top of TCP/IP and the rest of 241 | the internet. 242 | 243 | Onion addresses are either hashes of (in 80-bit version 2 addresses), 244 | or are literally and entirely (in 256-bit version 3 addresses) the 245 | public keys which sign all data that pertains to communication with 246 | that address. 247 | 248 | Like most cryptographic keys, onion addresses appear essentially to 249 | be strings of random bits, although it's possible via "mining" to 250 | eventually generate one which appears meaningful to human beings, eg: 251 | "facebookcorewwwi.onion" 252 | 253 | For purposes of PKI, the most interesting aspect of onion addresses 254 | is their textual representation; unlike IPv4's "dotted quads" or 255 | IPv6's colon-separated hexadecimal, onion addresses are required 256 | ([RFC7686] section 1) to be written in a DNS-compatible text format: 257 | as base-32 encoded binary with addition of the IANA Special-Use 258 | Domain Name suffix, ".onion", and they are interpreted ignoring any 259 | labels other than the rightmost two. 260 | 261 | Thus: the onion address "www.exampleonionaddr.onion" would be a 262 | version 2 onion address representing a server that possesses a 263 | 1024-bit RSA public key which has an 80-bit-truncated SHA-1 hash of 264 | 0x25c0c7ac8e6a1cd00c71 ([RFC3548] base32 "EXAMPLEONIONADDR"); and 265 | where the "www" prefix hostname/subdomain will ignored, although if 266 | specified it will be passed onward in an HTTPS "Host:" header. 267 | 268 | This representation pierces all of the layers of the network stack, 269 | and in one encoding it addresses most of the problems which the TLS 270 | PKI stack has gradually evolved to solve for TCP/IP: 271 | 272 | * There is no DNS name resolution service in onion networking, and 273 | in fact [RFC7686] section 2 specifies that there MUST NOT be 274 | overlap with DNS; this is an important point to which we will 275 | return later. 276 | 277 | 278 | 279 | 280 | Muffett Expires 18 September 2020 [Page 5] 281 | 282 | Internet-Draft sooc March 2020 283 | 284 | 285 | * What the user types into the browser bar will defacto prove what 286 | site they are connected to; the Tor Onion Network at layer 3 will 287 | consequently assert "proof-of-possession of a cryptographic key" 288 | that will correspond absolutely to the remote service; this is 289 | isomorphic to the model of a TLS certificate proving the identity 290 | of a webserver. 291 | 292 | * Because onion addresses are layer-3 addresses, there is no concept 293 | of "subdomains" nor of "hostnames" and therefore any such 294 | information is considered "advisory"; however in this format they 295 | are backwards compatible in a way that "subdomains" for "dotted 296 | quad" addresses would not be, eg: "www.192.168.1.1" 297 | 298 | * All other connectivity redirections or "hijacks" are inhibited by 299 | the Tor network stack. 300 | 301 | 4. SOOC In Context 302 | 303 | As described above, the security characteristics and protections of 304 | layer-3 networking (eg: IPsec) are generally not visible to HTTPS 305 | applications at layer-7, and therefore cannot be relied upon. 306 | 307 | However: the encoding of onion addresses explicitly solves this 308 | problem: 309 | 310 | * The connection *must* be an onion connection, because it was made 311 | using Tor-capable software, and because the ".onion" Special Use 312 | Domain Name is reserved for that purpose. 313 | 314 | * The connection *must* be to "exampleonionaddr.onion" because the 315 | Tor network will not permit otherwise. 316 | 317 | * Any subdomain or hostname is subordinate to the fact that the 318 | connection is made to "exampleonionaddr.onion", because (as a 319 | layer-3 address) there are actually no such things as "subdomains" 320 | or "hostnames", and thus this information is purely advisory, or 321 | for compatability. 322 | 323 | Therefore it is possible for a client to assure itself - when 324 | presented with a TLS certificate for "www.exampleonionaddr.onion" - 325 | to assure itself that it is genuinely and authoritatively connected 326 | to "exampleonionaddr.onion" by simply performing a string comparison 327 | with the hostname to which is it connected - without any reference to 328 | a certificate authority trust chain nor any other third party 329 | resource. 330 | 331 | This observation is the basis of "Same Origin Onion Certificate" 332 | checking; that onion sites may offer (eg: homebrew DV-compliant) TLS 333 | 334 | 335 | 336 | Muffett Expires 18 September 2020 [Page 6] 337 | 338 | Internet-Draft sooc March 2020 339 | 340 | 341 | certificates which correspond solely and uniquely to themselves, and 342 | under those limited circumstances the client may skip the certificate 343 | chain checks that might otherwise be required to validate identity. 344 | 345 | 5. SOOC Edge-Cases, and "SOOC-EV" 346 | 347 | It is necessary to recognise that there is one "weak" spot in the 348 | assertion that string comparison is sufficient to prove the binding 349 | between an Onion Address and a SSL Certificate 350 | SubjectAlternativeName, and that is in a scenario where the content 351 | webserver has been been deployed on one (or more) machines which are 352 | separate from the machine that terminates (i.e.: "hosts") the Onion 353 | Address AND, where the Tor daemon makes a direct TCP-level connection 354 | onwards to those servers. 355 | 356 | Those unfamiliar with how Tor works, may analogise this as "port- 357 | forwarding over SSH, where a port on the local host is forwarded to 358 | the remote server, which then forwards the data further onwards over 359 | a fresh TCP connection to a given port on a separate, third-party 360 | machine." 361 | 362 | The threat is: if a malicious actor can present themselves to the 363 | server-side Tor daemon as the IP address of the "third party" 364 | webserver - for instance a load-balancer, or a member of a load- 365 | balanced server tier - then under SOOC the malicious actor who 366 | achieves this could create a certificate permitthing them to 367 | impersonate a genuine SSL-certificate-enabled system _for_ that onion 368 | address. 369 | 370 | This is a question of trust boundaries and real world deployments; at 371 | the moment the "onion networking" service space is broadly comprised 372 | of unencrypted HTTP, and as such any typical onion service deployment 373 | which uses a load-balancer would already be at risk of this attack. 374 | As such, currently lacking TLS-layer security, almost nobody 375 | typically deploys their onion server backend in a manner which could 376 | fall victim to this. Most onion HTTP services are typically served 377 | over loopback. 378 | 379 | Equally: any onion site which uses a "rewriter" reverse-proxy (e.g.: 380 | New York Times, BBC, Deutsche Welle, Propublica, Internet Archive) is 381 | also typically NOT at risk from this attack, because the inbound 382 | HTTPS request is terminated on the "onion" host, immediately 383 | rewritten in terms of the address of the upstream service, and is 384 | passed over loopback onward as a fresh HTTPS reverse-proxy 385 | connection. 386 | 387 | As far as the author is aware, the only onion service deployment 388 | where the above threat scenario would be a potential issue, is at 389 | 390 | 391 | 392 | Muffett Expires 18 September 2020 [Page 7] 393 | 394 | Internet-Draft sooc March 2020 395 | 396 | 397 | Facebook; and if the Facebook devops team are at risk of someone 398 | interposing a fake server and server certificate into their 399 | infrastructure, then they have far bigger problems than mere onion 400 | service impersonation. 401 | 402 | 5.1. Advanced Mitigations: SOOC-EV 403 | 404 | Generally at this point, enthusiastic cryptographers will point at 405 | Version 3 Onion Addresses and note that they are actual public keys, 406 | and "couldn't they just sign the SOOC Certificate, and the browser 407 | would check the signature, and that would be the end of the problem?" 408 | 409 | They are correct to say this, however this raises two problems: 410 | 411 | 1. This would orphan Version 2 Onion addresses without SOOC, 412 | expressly against the intent of this document. 413 | 414 | 2. The Version 3 Onion addresses are (by Tor policy) never used to 415 | sign anything https://gitweb.torproject.org/torspec.git/tree/ 416 | rend-spec-v3.txt#n557 417 | (https://gitweb.torproject.org/torspec.git/tree/rend-spec- 418 | v3.txt#n557) 419 | 420 | Quote: 421 | 422 | | Master (hidden service) identity key -- A master signing keypair 423 | | used as the identity for a hidden service. This key is long term 424 | | and not used on its own to sign anything; it is only used to 425 | | generate blinded signing keys as described in [KEYBLIND] 426 | 427 | In Version 3 Onion Addressing, the address-key is used to derive 428 | short-term, time-locked, "blinded" keys in a fixed manner that can be 429 | replicated by a client which wishes to connect to the master onion 430 | address. The blinded keys are used to sign connection information 431 | that is loaded up into the "HSDir" distributed hash-table that 432 | describes Onion connectivity. 433 | 434 | Ergo: to implement a form of "Extended Validation" certificate 435 | extension that would bind a TLS certificate to an onion address, the 436 | certificate would have to contain the onion public key (for V2) or a 437 | blinded public key for a reasonable timestamp (for V3), and this 438 | public key would be used to validate a hash of some portion of the 439 | certificate, all in order to address this niche deployment risk. 440 | 441 | This is certainly possible to achieve, and is fairly straightforward, 442 | however it is a tremendous hassle for a niche risk, and I believe 443 | that it should not be an progress to implmenting SOOC without 444 | implementing these "Extended Validation"-type checks. 445 | 446 | 447 | 448 | Muffett Expires 18 September 2020 [Page 8] 449 | 450 | Internet-Draft sooc March 2020 451 | 452 | 453 | My rationale for deferring SOOC-EV - apart from the nicheness aspect 454 | - is also bolstered by the observation that "Appendix F" of CA/ 455 | B-Forum Ballot 144: 456 | 457 | https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot- 458 | onion-names/ (https://cabforum.org/2015/02/18/ballot-144-validation- 459 | rules-dot-onion-names/) 460 | 461 | This describes the "CAB Forum Tor Service Descriptor Hash Extension", 462 | a hash of the V2 Onion Public Key which Certificate Authorities are 463 | obliged to bind into the EV TLS Onion Certificates that they issue, 464 | ostensibly to both link the onion public key more tightly to the TLS 465 | certificate in the event that a colliding V2 Onion address is 466 | generated, but also to protect against the above described kinds of 467 | attack. 468 | 469 | There exists absolutely no client code actually implemented to check 470 | for, nor validate, this descriptor, to the extent that when Digicert 471 | misissued a certificate without the extension (compare 472 | https://crt.sh/?id=240277340 (https://crt.sh/?id=240277340) with 473 | https://crt.sh/?id=241547157) (https://crt.sh/?id=241547157)), no-one 474 | actually noticed, except for Digicert. 475 | 476 | As such, I don't believe that this attack is currently worthy of 477 | consideration, especially as it is within the power of the service 478 | provider to mitigate in alternative ways, and in any case we may 479 | still evolve towards SOOC-EV as the the technology matures. 480 | 481 | To be clear: I do believe that SOOC-EV should probably be done. But 482 | I do not believe that it should be a pre-requisite condition for 483 | SOOC, nor is it necessary to do it "now", nor is any threat great 484 | enough to block SOOC until SOOC-EV is defined. Apart from the 485 | reasons stated above, there is likely still some need for V3 Onion 486 | Address blinding and key-derivation algorithms to mature and prove 487 | stability in deployments for a few years. 488 | 489 | 5.2. Reciprocal Attack: Shared Tor Gateways? 490 | 491 | Having comprehended the above, there is also obviously a reciprocal 492 | risk which can be stated: 493 | 494 | * What about shared onion gateways? What if many people use one Tor 495 | proxy to access Tor? One could interpose a fake SOCKS5 man-in- 496 | the-middle and respond to Onion connection requests with a fake 497 | SOOC TLS certificate! 498 | 499 | The response to which, again, is that although such may happen 500 | experimentally, the overwhelming means by which people access Tor is 501 | 502 | 503 | 504 | Muffett Expires 18 September 2020 [Page 9] 505 | 506 | Internet-Draft sooc March 2020 507 | 508 | 509 | by using a local client over loopback, one (or more) per user. At 510 | the "client" end, access to the Tor proxy is within the local trust 511 | boundary, where worse things can happen. 512 | 513 | 6. Linkfarm TBD 514 | 515 | For more on Onion Networking as a layer-3 network, see: 516 | https://www.youtube.com/watch?v=pebRZyg_bh8 (https://www.youtube.com/ 517 | watch?v=pebRZyg_bh8) 518 | 519 | IANA Special-Use Domain Names https://www.iana.org/assignments/ 520 | special-use-domain-names/special-use-domain-names.xhtml 521 | (https://www.iana.org/assignments/special-use-domain-names/special- 522 | use-domain-names.xhtml) 523 | 524 | Facebook Onion Announcement https://www.facebook.com/notes/protect- 525 | the-graph/making-connections-to-facebook-more- 526 | secure/1526085754298237/ (https://www.facebook.com/notes/protect-the- 527 | graph/making-connections-to-facebook-more-secure/1526085754298237/) 528 | 529 | 7. Topics for possible expansion 530 | 531 | * SOOC Use Cases 532 | 533 | * SOOC and Certificate Transparency 534 | 535 | * SOOC and DV Certificates 536 | 537 | - Potential negative consequences of DV certificates for Onion 538 | Addresses 539 | 540 | * SOOC and EV Certificates 541 | 542 | * SOOC and HSTS 543 | 544 | * SOOC and LetsEncrypt 545 | 546 | * SOOC to complement, not replace, EV (and perhaps DV) 547 | 548 | 8. Informative References 549 | 550 | [RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 551 | Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003, 552 | . 553 | 554 | [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 555 | Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 556 | 2015, . 557 | 558 | 559 | 560 | Muffett Expires 18 September 2020 [Page 10] 561 | 562 | Internet-Draft sooc March 2020 563 | 564 | 565 | Author's Address 566 | 567 | Alec Muffett 568 | Independent 569 | 570 | Email: alec.muffett@gmail.com 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 | 595 | 596 | 597 | 598 | 599 | 600 | 601 | 602 | 603 | 604 | 605 | 606 | 607 | 608 | 609 | 610 | 611 | 612 | 613 | 614 | 615 | 616 | Muffett Expires 18 September 2020 [Page 11] 617 | -------------------------------------------------------------------------------- /text/draft-muffett-same-origin-onion-certificates.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Same Origin Onion Certificates 7 | Independent
8 | alec.muffett@gmail.com 9 |
10 | 11 | Internet 12 | Transport Layer Security 13 | tor 14 | onion 15 | tls 16 | ssl 17 | 18 | 19 | Onion networking offers technical features which obviate 20 | many of the risks upon which led to the development of our modern 21 | Certificate Authority Public Key Infrastructure; as an increasingly 22 | popular technology for networking with strong trust requirements, 23 | onion networking would benefit from easier access to TLS certificates 24 | for HTTPS use. 25 | At the moment only EV certificates are available for onion network 26 | addresses, although DV certificates are under discussion; the 27 | potential downsides of issuing DV certificates for Onion Addresses are 28 | discussed below. 29 | This document defines a third possible mechanism - SOOC: Same Origin 30 | Onion Certificates - that would enable real-time, client-side 31 | validation of per-onion-address TLS certificates, fully equivalent (in 32 | defined circumstances) to validation of a certificate trust chain, but 33 | involving none of third parties, trust chains, or financial cost. 34 | In the simpest possible terms, SOOC is not a "self-signed 35 | certificate" proposal; instead it is a proposal that "in very limited 36 | circumstances, we shall not care about signatures at all", with a 37 | codicil regarding how this may be improved in future. 38 | This distinction is important because it highlights that the initial 39 | implementation of SOOC certificates contain no additional features 40 | above or beyond the specifications of standard DV certificates, and 41 | require no tools to create other than standard openssl or mkcert 42 | to create. This is part of the value proposition of SOOC, in order to 43 | lower the barriers to adoption by small sites and experimenters with 44 | limited experience of TLS. 45 | 46 | 47 | 48 | 49 | 50 | 51 |
SOOC Certificate Specification 52 | Using the Public Suffix List, let baseDomain be the Registrable 53 | Domain of the connected origin, e.g., abcdefghijklmnop.onion 54 | 55 |
    56 |
  1. A SOOC Certificate is a properly formatted DV or EV TLS 57 | certificate, per the browser's concept of web standards 58 |
    2. 59 |
  2. where the certificate, if the browser were to trust the 60 | certificate's trust chain, would otherwise be a fully valid and 61 | trusted certificate 62 |
    3. 63 |
  3. where the certificate, if it has a basicConstraints extension, that 64 | extension MUST only be CA:FALSE 65 |
    4. 66 |
  4. where the certificate, if it has a commonName, that commonName 67 | MUST be equal to the baseDomain as defined above 68 |
    5. 69 |
  5. where the certificate, if it has subjectAlternativeNames, those 70 | subjectAlternativeNames MUST all be of type dNSname, MUST 71 | all be of valid DV format (wildcards permitted) and each of which 72 | MUST have the baseDomain as the rightmost two labels. 73 |
    6. 74 |
  6. where the certificate, if it cites any subjectAlternativeNames or 75 | other regisitrable domains, all of those subjectAlternativeNames or 76 | other registrable domains MUST have the baseDomain as the 77 | rightmost two labels. 78 |
    7. 79 |
80 | If all of these contstraints are satisfied, the certificate is a valid 81 | SOOC certificate. 82 |
83 | 84 |
SOOC Example Protocol 85 | If you are a Browser, and... 86 | 87 |
    88 |
  1. You connect to site.geo.subdomain.foo.onion to GET a URL via 89 | HTTPS in the normal way 90 |
    2. 91 |
  2. and you observe that the rightmost label of the TLD is .onion 92 |
    3. 93 |
  3. and that site.geo.subdomain.foo.onion offers you a certificate 94 | 95 |
      96 |
    1. then you MUST confirm that you have an opt-in setting enabled 97 | (probably default in TorBrowser) 98 |
      2. 99 |
    2. and you MUST confirm that the certificate satisfies ALL of the 100 | conditions of being a valid SOOC certificate with the baseDomain 101 | of foo.onion 102 |
      3. 103 |
    3. and you MUST confirm that the baseDomain for the certificate, 104 | matches the rightmost two labels of the URL site 105 |
      4. 106 |
    4. and you MUST confirm that the certificate's 107 | subjectAlternativeNames would successfully match 108 | site.geo.subdomain.foo.onion 109 |
      5. 110 |
    4. 111 |
  4. If all of the above are confirmed, then your certificate validation 112 | code MUST skip checking the certificiate trust chain. 113 |
    5. 114 |
115 |
116 | 117 |
Why SOOC is Necessary 118 | There are many reasons why the Internet and WWW are equipped with a 119 | public key infrastructure (PKI), and the PKI offers many features and 120 | benefits; however its inarguable primary function is to provide a form 121 | of identity assurance, that when a person types a hostname such as 122 | "www.example.com" into a web browser's URL bar, they should have some 123 | reasonable expectation - and ideally a strong guarantee - that the 124 | network-connected-service from which they are eventually served 125 | content is one that would commonly be accepted as being capable, 126 | permitted and expected to serve content which people who own the 127 | "www.example.com" intentionally supply. 128 | The PKI mechanism has evolved to provide such identity assurance in a 129 | heavily-layered network environment which lacks overarching trust 130 | mechanisms and which is riven with potential for attack at (or: 131 | across) different layers. 132 | For instance: 133 | 134 |
    135 |
  • ARP: first-hop, last-hop, or indeed any other hop may be hijacked 136 | with spoofed layer-2 address resolution; indeed some firewall 137 | devices rely upon this mechanism for their function 138 |
    • 139 |
  • TCP: traffic may be blocked, dropped, modified, injected, or 140 | redirected to fake machines 141 |
    • 142 |
  • BGP: bearer traffic and entire flows may be blocked, dropped, or 143 | redirected to fake machines 144 |
    • 145 |
  • DNS: namespaces can be domain-jacked, responses can be forged, 146 | cache-poisoned, or simply tampered-with in flight, also homoglyph 147 | "lookalike" domains (eg: www.examp1e.com) are also possible 148 |
    • 149 |
150 | The benefits of any intra-layer trust mechanism - eg: IPsec 151 | Authentication Header (AH) & Encapsulating Security Payload (ESP) at 152 | layer-3 - are typically isolated and not known to other layers of the 153 | stack - eg: the web browser - which therefore cannot take 154 | consideration of their benefits. 155 | In this environment our HTTPS ecosystem has evolved in the expectation 156 | of ignoring transport security - such as IPsec - and has instead has 157 | built its own, where a server's "identity" may be provisionally 158 | bootstrapped by DNS resolution of of a layer-3 IP address, however 159 | that identity MUST be proven by proof-of-possession of a 160 | cryptographic key that has been blessed by a trusted authority as 161 | pertaining to "www.example.com". 162 | The extent of such blessing is variable: for DV certificates the 163 | requisite test is one of consistent DNS resolution (eg: LetsEncrypt); 164 | and for EV certificates there are additional, expensive, and arguably 165 | superfluous corporate identity checks. 166 | 167 |
Onion Networking compared to TLS PKI 168 | Tor "onion networking" is an alternate, software-defined, flat layer-3 169 | network space which exists on top of TCP/IP and the rest of the 170 | internet. 171 | Onion addresses are either hashes of (in 80-bit version 2 addresses), 172 | or are literally and entirely (in 256-bit version 3 addresses) the 173 | public keys which sign all data that pertains to communication with 174 | that address. 175 | Like most cryptographic keys, onion addresses appear essentially to be 176 | strings of random bits, although it's possible via "mining" to 177 | eventually generate one which appears meaningful to human beings, eg: 178 | "facebookcorewwwi.onion" 179 | For purposes of PKI, the most interesting aspect of onion addresses is 180 | their textual representation; unlike IPv4's "dotted quads" or IPv6's 181 | colon-separated hexadecimal, onion addresses are required ( 182 | section 1) to be written in a DNS-compatible text format: as base-32 183 | encoded binary with addition of the IANA Special-Use Domain Name 184 | suffix, ".onion", and they are interpreted ignoring any labels other 185 | than the rightmost two. 186 | Thus: the onion address "www.exampleonionaddr.onion" would be a 187 | version 2 onion address representing a server that possesses a 188 | 1024-bit RSA public key which has an 80-bit-truncated SHA-1 hash of 189 | 0x25c0c7ac8e6a1cd00c71 ( base32 "EXAMPLEONIONADDR"); and 190 | where the "www" prefix hostname/subdomain will ignored, although if 191 | specified it will be passed onward in an HTTPS "Host:" header. 192 | This representation pierces all of the layers of the network stack, 193 | and in one encoding it addresses most of the problems which the TLS 194 | PKI stack has gradually evolved to solve for TCP/IP: 195 | 196 |
    197 |
  • There is no DNS name resolution service in onion networking, and in 198 | fact section 2 specifies that there MUST NOT be 199 | overlap with DNS; this is an important point to which we will return 200 | later. 201 |
    • 202 |
  • What the user types into the browser bar will defacto prove what 203 | site they are connected to; the Tor Onion Network at layer 3 will 204 | consequently assert "proof-of-possession of a cryptographic key" 205 | that will correspond absolutely to the remote service; this is 206 | isomorphic to the model of a TLS certificate proving the identity of 207 | a webserver. 208 |
    • 209 |
  • Because onion addresses are layer-3 addresses, there is no concept 210 | of "subdomains" nor of "hostnames" and therefore any such 211 | information is considered "advisory"; however in this format they 212 | are backwards compatible in a way that "subdomains" for "dotted 213 | quad" addresses would not be, eg: "www.192.168.1.1" 214 |
    • 215 |
  • All other connectivity redirections or "hijacks" are inhibited by 216 | the Tor network stack. 217 |
    • 218 |
219 |
220 |
221 | 222 |
SOOC In Context 223 | As described above, the security characteristics and protections of 224 | layer-3 networking (eg: IPsec) are generally not visible to HTTPS 225 | applications at layer-7, and therefore cannot be relied upon. 226 | However: the encoding of onion addresses explicitly solves this problem: 227 | 228 |
    229 |
  • The connection must be an onion connection, because it was made 230 | using Tor-capable software, and because the ".onion" Special Use 231 | Domain Name is reserved for that purpose. 232 |
    • 233 |
  • The connection must be to "exampleonionaddr.onion" because the 234 | Tor network will not permit otherwise. 235 |
    • 236 |
  • Any subdomain or hostname is subordinate to the fact that the 237 | connection is made to "exampleonionaddr.onion", because (as a 238 | layer-3 address) there are actually no such things as "subdomains" 239 | or "hostnames", and thus this information is purely advisory, or for 240 | compatability. 241 |
    • 242 |
243 | Therefore it is possible for a client to assure itself - when 244 | presented with a TLS certificate for "www.exampleonionaddr.onion" - to 245 | assure itself that it is genuinely and authoritatively connected to 246 | "exampleonionaddr.onion" by simply performing a string comparison with 247 | the hostname to which is it connected - without any reference to a 248 | certificate authority trust chain nor any other third party resource. 249 | This observation is the basis of "Same Origin Onion Certificate" 250 | checking; that onion sites may offer (eg: homebrew DV-compliant) TLS 251 | certificates which correspond solely and uniquely to themselves, and 252 | under those limited circumstances the client may skip the certificate 253 | chain checks that might otherwise be required to validate identity. 254 |
255 | 256 |
SOOC Edge-Cases, and "SOOC-EV" 257 | It is necessary to recognise that there is one "weak" spot in the 258 | assertion that string comparison is sufficient to prove the binding 259 | between an Onion Address and a SSL Certificate SubjectAlternativeName, and 260 | that is in a scenario where the content webserver has been been 261 | deployed on one (or more) machines which are separate from the machine 262 | that terminates (i.e.: "hosts") the Onion Address AND, where the Tor 263 | daemon makes a direct TCP-level connection onwards to those servers. 264 | Those unfamiliar with how Tor works, may analogise this as 265 | "port-forwarding over SSH, where a port on the local host is forwarded 266 | to the remote server, which then forwards the data further onwards 267 | over a fresh TCP connection to a given port on a separate, third-party 268 | machine." 269 | The threat is: if a malicious actor can present themselves to the 270 | server-side Tor daemon as the IP address of the "third party" 271 | webserver - for instance a load-balancer, or a member of a 272 | load-balanced server tier - then under SOOC the malicious actor who 273 | achieves this could create a certificate permitthing them to 274 | impersonate a genuine SSL-certificate-enabled system for that onion 275 | address. 276 | This is a question of trust boundaries and real world deployments; at 277 | the moment the "onion networking" service space is broadly comprised 278 | of unencrypted HTTP, and as such any typical onion service deployment 279 | which uses a load-balancer would already be at risk of this attack. 280 | As such, currently lacking TLS-layer security, almost nobody typically 281 | deploys their onion server backend in a manner which could fall victim 282 | to this. Most onion HTTP services are typically served over loopback. 283 | Equally: any onion site which uses a "rewriter" reverse-proxy (e.g.: 284 | New York Times, BBC, Deutsche Welle, Propublica, Internet Archive) is 285 | also typically NOT at risk from this attack, because the inbound HTTPS 286 | request is terminated on the "onion" host, immediately rewritten in 287 | terms of the address of the upstream service, and is passed over 288 | loopback onward as a fresh HTTPS reverse-proxy connection. 289 | As far as the author is aware, the only onion service deployment where 290 | the above threat scenario would be a potential issue, is at Facebook; 291 | and if the Facebook devops team are at risk of someone interposing a 292 | fake server and server certificate into their infrastructure, then 293 | they have far bigger problems than mere onion service impersonation. 294 | 295 |
Advanced Mitigations: SOOC-EV 296 | Generally at this point, enthusiastic cryptographers will point at 297 | Version 3 Onion Addresses and note that they are actual public keys, 298 | and "couldn't they just sign the SOOC Certificate, and the browser 299 | would check the signature, and that would be the end of the problem?" 300 | They are correct to say this, however this raises two problems: 301 | 302 |
    303 |
  1. This would orphan Version 2 Onion addresses without SOOC, expressly 304 | against the intent of this document. 305 |
    2. 306 |
  2. The Version 3 Onion addresses are (by Tor policy) never used to 307 | sign anything https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n557 308 |
    3. 309 |
310 | Quote: 311 |
Master (hidden service) identity key -- A master signing keypair 312 | used as the identity for a hidden service. This key is long term and 313 | not used on its own to sign anything; it is only used to generate 314 | blinded signing keys as described in [KEYBLIND] 315 |
In Version 3 Onion Addressing, the address-key is used to derive 316 | short-term, time-locked, "blinded" keys in a fixed manner that can be 317 | replicated by a client which wishes to connect to the master onion 318 | address. The blinded keys are used to sign connection information 319 | that is loaded up into the "HSDir" distributed hash-table that 320 | describes Onion connectivity. 321 | Ergo: to implement a form of "Extended Validation" certificate 322 | extension that would bind a TLS certificate to an onion address, the 323 | certificate would have to contain the onion public key (for V2) or a 324 | blinded public key for a reasonable timestamp (for V3), and this 325 | public key would be used to validate a hash of some portion of the 326 | certificate, all in order to address this niche deployment risk. 327 | This is certainly possible to achieve, and is fairly straightforward, 328 | however it is a tremendous hassle for a niche risk, and I believe that 329 | it should not be an progress to implmenting SOOC without implementing 330 | these "Extended Validation"-type checks. 331 | My rationale for deferring SOOC-EV - apart from the nicheness aspect - 332 | is also bolstered by the observation that "Appendix F" of CA/B-Forum 333 | Ballot 144: 334 | https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ 335 | This describes the "CAB Forum Tor Service Descriptor Hash Extension", 336 | a hash of the V2 Onion Public Key which Certificate Authorities are 337 | obliged to bind into the EV TLS Onion Certificates that they issue, 338 | ostensibly to both link the onion public key more tightly to the TLS 339 | certificate in the event that a colliding V2 Onion address is 340 | generated, but also to protect against the above described kinds of 341 | attack. 342 | There exists absolutely no client code actually implemented to check 343 | for, nor validate, this descriptor, to the extent that when Digicert 344 | misissued a certificate without the extension (compare 345 | https://crt.sh/?id=240277340 with https://crt.sh/?id=241547157), 346 | no-one actually noticed, except for Digicert. 347 | As such, I don't believe that this attack is currently worthy of 348 | consideration, especially as it is within the power of the service 349 | provider to mitigate in alternative ways, and in any case we may still 350 | evolve towards SOOC-EV as the the technology matures. 351 | To be clear: I do believe that SOOC-EV should probably be done. But I 352 | do not believe that it should be a pre-requisite condition for SOOC, 353 | nor is it necessary to do it "now", nor is any threat great enough to 354 | block SOOC until SOOC-EV is defined. Apart from the reasons stated 355 | above, there is likely still some need for V3 Onion Address blinding 356 | and key-derivation algorithms to mature and prove stability in 357 | deployments for a few years. 358 |
359 | 360 |
Reciprocal Attack: Shared Tor Gateways? 361 | Having comprehended the above, there is also obviously a reciprocal 362 | risk which can be stated: 363 | 364 |
    365 |
  • What about shared onion gateways? What if many people use one Tor 366 | proxy to access Tor? One could interpose a fake SOCKS5 367 | man-in-the-middle and respond to Onion connection requests with a 368 | fake SOOC TLS certificate! 369 |
    • 370 |
371 | The response to which, again, is that although such may happen 372 | experimentally, the overwhelming means by which people access Tor is 373 | by using a local client over loopback, one (or more) per user. At the 374 | "client" end, access to the Tor proxy is within the local trust 375 | boundary, where worse things can happen. 376 |
377 |
378 | 379 |
Linkfarm TBD 380 | For more on Onion Networking as a layer-3 network, see: 381 | https://www.youtube.com/watch?v=pebRZyg_bh8 382 | IANA Special-Use Domain Names 383 | https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml 384 | Facebook Onion Announcement 385 | https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237/ 386 |
387 | 388 |
Topics for possible expansion 389 | 390 |
    391 |
  • SOOC Use Cases 392 |
    • 393 |
  • SOOC and Certificate Transparency 394 |
    • 395 |
  • SOOC and DV Certificates 396 | 397 |
      398 |
    • Potential negative consequences of DV certificates for Onion Addresses 399 |
      • 400 |
    • 401 |
  • SOOC and EV Certificates 402 |
    • 403 |
  • SOOC and HSTS 404 |
    • 405 |
  • SOOC and LetsEncrypt 406 |
    • 407 |
  • SOOC to complement, not replace, EV (and perhaps DV) 408 |
    • 409 |
410 |
411 | 412 | 413 | 414 | 415 | Informative References 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | --------------------------------------------------------------------------------