[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Specification for 'How to Safely Sign a statement with a .onion key'
Attached is a document written in the specification format for one
aspect of CA-signed .onion addresses - specifically a "What is a safe
way to sign (or not sign) a statement using the .onion key" It
presents a couple options - I'd love to get feedback from folks on
which they prefer.
I recognize that no consensus or decision has been reached on whether
to encourage or guide CAs on issuing .onions. (Although I'm in
favor[0].) Although this is obviously written skewed towards CAs, it
addresses a generic problem, and could be rewritten in that form.
Excerpting from the Introduction/Motivation:
Several organizations, such as Facebook, (collectively,
'applicants') have expressed a desire for an end-entity
SSL certificate valid for their .onion Hidden Service
address signed by a Certificate Authority (CA) present in
browser trust stores.
The existing Facebook .onion URL was issued by Digicert under
a loophole in certificate issuance requirements. The Basic
Requirements [0] is a document created by the Certificate
Authority/Browser Forum that governs acceptable certificate
issuing policies. Adherence to its policies is required for
inclusion in many browsers' trust stores. .onion counts as
an 'internal hostname' as it is not a recognized TLD by IANA.
November 1, 2015 sets the deadline for when all internal server
certificates must be revoked and no new certificates may be
issued. Resolving the requirements and preferences for issuing
.onion certificates before this date is extremely desirable, as
it will determine if organizations such as Facebook will invest
in the time and engineering effort needed to deploy Hidden
Services.
The full requirements for issuing .onion certificates is TBD,
although recognition of .onion by IANA as a reserved domain is
likely required.
During discussions about the requirements for issuing for
.onion one question that has arisen is what is a safe way to
assert ownership of a .onion address and format an x509
certificate with a .onion Subject Alternate Name (SAN).
This document is designed to address some of those questions.
-tom
[0] https://lists.torproject.org/pipermail/tor-dev/2014-November/007786.html
Filename: XXX-recommendations-for-onion-certifiates.txt
Title: Recommendations for CA-signed .onion Certificates
Authors: Tom Ritter
Created: 23 November 2014
Target: n/a
Status: Draft
1. Intro and motivation
Several organizations, such as Facebook, (collectively,
'applicants') have expressed a desire for an end-entity
SSL certificate valid for their .onion Hidden Service
address signed by a Certificate Authority (CA) present in
browser trust stores.
Applicants want a CA-signed .onion address for several reasons,
including:
- Architectural reasons, where the existing web server
expects and requires SSL
- Removing the existing 'Invalid Certificate' warning when
accessing a .onion URL over https
- Public attribution of ownership of the .onion address
The existing Facebook .onion URL was issued by Digicert under
a loophole in certificate issuance requirements. The Basic
Requirements [0] is a document created by the Certificate
Authority/Browser Forum that governs acceptable certificate
issuing policies. Adherence to its policies is required for
inclusion in many browsers' trust stores. .onion counts as
an 'internal hostname' as it is not a recognized TLD by IANA.
November 1, 2015 sets the deadline for when all internal server
certificates must be revoked and no new certificates may be
issued. Resolving the requirements and preferences for issuing
.onion certificates before this date is extremely desirable, as
it will determine if organizations such as Facebook will invest
in the time and engineering effort needed to deploy Hidden
Services.
The full requirements for issuing .onion certificates is TBD,
although recognition of .onion by IANA as a reserved domain is
likely required.
During discussions about the requirements for issuing for
.onion one question that has arisen is what is a safe way to
assert ownership of a .onion address and format an x509
certificate with a .onion Subject Alternate Name (SAN).
This document is designed to address some of those questions.
2. Ownership of a .onion
A .onion address is an 80-bit truncation of the SHA-1 hash of
the Hidden Service's public identity key (which is RSA 1024).
To assert that an entity has control of a .onion address, an
entity could do one of several things.
2.1 Well Known URI
RFC5785 [1] specifies a path prefix for "well known locations".
A CA could require an applicant to post a specific value at
a well-known URI. Because of the nature of .onion addresses,
this ensures that successful completion of this challenge is
limited to:
i. The legitimate owner of the .onion domain
ii. Someone who possessed their private RSA key
iii. Someone who achieved a 2^80 collision of SHA-1(RSA_Pub)
for another RSA_pub
An advantage of this system is that the .onion private key
material is not used in any other situation than the normal
Hidden Services protocol(s).
A disadvantage of this system is that it requires the
application to deploy a HTTP server to apply for their
certificate. While we can expect many if not most of the
applicants are seeking a certificate for a HTTP server,
certificates could also be legitimately requested for
XMPP servers, mailservers, or other protocols. However,
it would not be extremely difficult for an applicant to
temporarily stand up an HTTP server.
2.2 Signing with the .onion key
Because the .onion address is a (truncated hash of a)
representation of the key - the underlying key can be sign
a request for a certificate.
A signature should contain a sufficiently random value
chosen by the CA to assure them a fraudulent applicant
could not obtain a signed statement with it in it.
A signature should also contain a sufficiently random
value chosen by the application to assure them the CA
is unable to completely choose the content of the signed
statement.
A major concern with this approach is reusing the key
material for two purposes: signing a statement at the
request of the CA and participating in the Hidden
Services protocol(s). If one is not careful, one may
enable cross-protocol attacks. There are at least two
approaches to mitigating this concern.
2.2.1 Sign a close-but-invalid HS descriptor
In this approach, the Hidden Service descriptor format,
as specified in spec #114 [2], is carefully taken into
account. Specifically, the signed data is carefully chosen
to almost-parse as a valid descriptor, but fail one or more
specific checks. This is made simpler by there being limited
implementations and opportunities for cross-protocol
attacks.
The descriptor-content format is:
descriptor-content = {
descriptor-id,
version,
public-key,
h(time-period + cookie + replica),
timestamp,
protocol-versions,
{ introduction-points } encrypted with cookie
} signed with private-key
Checks that could fail include:
- The descriptor-id could be invalid
- The version number could != 2 and be reserved for no
future use
- The publication time could be > 24 hours old and out
of date
- The introduction points could contain invalid data, such
as invalid IP addresses or ports
An advantage of this approach is that by following an
existing format but producing invalid data, future development
is extremely unlikely to be affected.
A disadvantage of this approach is it flirts with disaster. If
a present or future implementation had a bug where an invalid
descriptor was accepted, this could enable an attack. But, if
for example an applicant signed an expired descriptor, a
vulnerable client would be vulnerable today and be vulnerable
through many more vectors than the CA signature request.
2.2.2 Sign a completely nonsensical string
In this approach, the applicant signs a long string chosen not
to overlap with any existing formats. For example, this string
may be a long ASCII statement:
"I, applicant, being of sound mind and body, do request...""
An advantage of this approach is that is does not flirt with
disaster as in 2.2.1.
A disadvantage of this approach is that future development
would need to be carefully architected to not enable an attack.
[0] https://cabforum.org/about-the-baseline-requirements/
[1] https://tools.ietf.org/html/rfc5785
[2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/114-distributed-storage.txt#l288
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev