Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:01:00Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20051Unit tests for ed25519 link handshake code2020-06-13T15:01:00ZNick MathewsonUnit tests for ed25519 link handshake codeWe can't do a halfway job on unit tests for the link handshake; we need to make sure everything invalid fails. So I can't put 15055_wip into needs_review until the test coverage is much higher, and we really test all the different ways ...We can't do a halfway job on unit tests for the link handshake; we need to make sure everything invalid fails. So I can't put 15055_wip into needs_review until the test coverage is much higher, and we really test all the different ways a handshake can go wrong.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20027Ed25519 certificate parsing does badly with expirations after 20382020-06-13T15:00:53ZNick MathewsonEd25519 certificate parsing does badly with expirations after 2038We deliberately chose an hour-based expiration counter for ed certs, because of 32-bit issues. But when we parse them, we just multiply the 32-bit field by 3600. That results in an overflow if the time is greater than UINT32_MAX.
The ...We deliberately chose an hour-based expiration counter for ed certs, because of 32-bit issues. But when we parse them, we just multiply the 32-bit field by 3600. That results in an overflow if the time is greater than UINT32_MAX.
The impact here isn't too bad. First, it only affects certs that expire after 32-bit signed time overflows in Y2038. Second, it can only make it seem that a non-expired cert is expired: it can never make it seem that an expired cert is still live.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19958Implement proposal 264 (protocol versioning)2020-06-13T15:03:40ZNick MathewsonImplement proposal 264 (protocol versioning)This is not 100% strictly necessary for #15055 to work, but every time we change a protocol, we will wish that we had included this feature.
Mostly implemented in a fit of C while I was on vacation.This is not 100% strictly necessary for #15055 to work, but every time we change a protocol, we will wish that we had included this feature.
Mostly implemented in a fit of C while I was on vacation.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19470Match 15055_wip commits to #15055 subtickets2020-06-13T14:58:52ZNick MathewsonMatch 15055_wip commits to #15055 subticketsSome parts of #15055 are done; I should figure out which.Some parts of #15055 are done; I should figure out which.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19160[prop220] Advertise support for Ed25519 link authentication2020-06-13T14:57:50ZNick Mathewson[prop220] Advertise support for Ed25519 link authenticationIn order to (finally) have authentication happen with ed25519 on link connections, we need to advertise we support it. Responders just do that by unconditionally sending all their certs, and by adding AUTH0002 to their AUTH_CHALLENGE ce...In order to (finally) have authentication happen with ed25519 on link connections, we need to advertise we support it. Responders just do that by unconditionally sending all their certs, and by adding AUTH0002 to their AUTH_CHALLENGE cells. That should make clients do the right thing.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19159[prop220] Add ed25519-ID field to channel and/or or_connection2020-06-13T14:57:49ZNick Mathewson[prop220] Add ed25519-ID field to channel and/or or_connectionOnce we support links authenticating by Ed25519, we'll need to store the Ed25519 keys in the channel or or_connection objects (or both), and index those by their keys.
We should set these keys, of course, only when they are really authe...Once we support links authenticating by Ed25519, we'll need to store the Ed25519 keys in the channel or or_connection objects (or both), and index those by their keys.
We should set these keys, of course, only when they are really authenticated.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19158[prop220] Understand and validate ed25519-signed AUTH0002 cells2020-06-13T14:57:49ZNick Mathewson[prop220] Understand and validate ed25519-signed AUTH0002 cellsWhen a server receives a connection from another server with an AUTH0002 cell, it should parse the cell, check it for correctness, and make sure the signature is valid.
Partially implemented in my work-in-progress #15055 branchWhen a server receives a connection from another server with an AUTH0002 cell, it should parse the cell, check it for correctness, and make sure the signature is valid.
Partially implemented in my work-in-progress #15055 branchTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19157[prop220] Check all new certificate types (incl cross-cert and ed25519)2020-06-13T14:57:48ZNick Mathewson[prop220] Check all new certificate types (incl cross-cert and ed25519)If we're using ed25519 authentication, we should understand and check all the relevant certificate types when they're presented in the CERTS cell.
Partially implemented in my work-in-progress #15055 branch.If we're using ed25519 authentication, we should understand and check all the relevant certificate types when they're presented in the CERTS cell.
Partially implemented in my work-in-progress #15055 branch.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19156[prop220] send AUTHENTICATE cells with correct ed25519 signatures2020-06-13T14:57:48ZNick Mathewson[prop220] send AUTHENTICATE cells with correct ed25519 signaturesWhen we're using AuthType2, we send a new AUTH0002 cell, with a slightly different format from the one we use today. It's documented in section 4.2 of prop220.
It's mostly implemented in my work-in-progress Ed25519 branch.When we're using AuthType2, we send a new AUTH0002 cell, with a slightly different format from the one we use today. It's documented in section 4.2 of prop220.
It's mostly implemented in my work-in-progress Ed25519 branch.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19155[prop220] send CERTS cells correctly for Ed255192020-06-13T14:57:47ZNick Mathewson[prop220] send CERTS cells correctly for Ed25519Part of implementing proposal 220 is to make sure that severs receiving connections send all the new certificate types, including:
* identity->signing cert (type 4)
* signing->TLS-RSA (6) (respondor only)
* signing->link (5) cert (...Part of implementing proposal 220 is to make sure that severs receiving connections send all the new certificate types, including:
* identity->signing cert (type 4)
* signing->TLS-RSA (6) (respondor only)
* signing->link (5) cert (initiator only)
* RSA identity cross-cert (7)
This code is mostly implemented in my WIP #15055 branch.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19020RSA cross-certification of ed25519 keys differs from spec2020-06-13T14:57:14ZJohn BrooksRSA cross-certification of ed25519 keys differs from specProposal 220 section 4.2 defines a means of certifying an ed25519 key using an RSA key:
Certificate type [07] (Cross-certification of Ed25519 identity
with RSA key) contains the following data:
ED25519_KEY ...Proposal 220 section 4.2 defines a means of certifying an ed25519 key using an RSA key:
Certificate type [07] (Cross-certification of Ed25519 identity
with RSA key) contains the following data:
ED25519_KEY [32 bytes]
EXPIRATION_DATE [4 bytes]
SIGNATURE [128 bytes]
Here, the Ed25519 identity key is signed with router's RSA
identity key, to indicate that authenticating with a key
certified by the Ed25519 key counts as certifying with RSA
identity key. (The signature is computed on the SHA256 hash of
the non-signature parts of the certificate, prefixed with the
string "Tor TLS RSA/Ed25519 cross-certificate".)
We implement this in the rsa_ed_crosscert_t trunnel structure and the tor_make_rsa_ed25519_crosscert function. There are two issues with this implementation, compared to the proposal:
Firstly, this code includes a 1 byte SIG_LEN field before the signature, and a signature of variable size. We should just change this in the proposal.
More significantly, this code signs the 36 byte structure directly rather than a SHA256 digest of the structure, and of course also doesn't have the prefix string in that signature. I doubt we can change this format easily now.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17779Memory leak in routerkeys.c2020-06-13T14:52:00ZcypherpunksMemory leak in routerkeys.cThe `rsa_ed_crosscert` variable is assigned a cross-certification object in the `load_ed_keys` function but is never freed. Secondly, the variable is only used by the `get_master_rsa_crosscert` function which, in turn, is not used by the...The `rsa_ed_crosscert` variable is assigned a cross-certification object in the `load_ed_keys` function but is never freed. Secondly, the variable is only used by the `get_master_rsa_crosscert` function which, in turn, is not used by the current code base.
My suggestion is to remove the `rsa_ed_crosscert` variable and the `get_master_rsa_crosscert` function to fix the memory leak (unless they have some future use-case).
The variable and function were added in 3bee74c6d115131f4850a07a5c12db21ae6f3193.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16035Implement proposal 244: RFC5705 for exporting key material in tls handshake2020-06-13T14:46:12ZNick MathewsonImplement proposal 244: RFC5705 for exporting key material in tls handshakeFrom the proposal:
{{{ We use AUTHENTICATE cells to bind the connection-initiator's Tor
identity to a TLS session. Our current type of authentication
("RSA-SHA256-TLSSecret", see tor-spec.txt section 4.4) does this by
signing a d...From the proposal:
{{{ We use AUTHENTICATE cells to bind the connection-initiator's Tor
identity to a TLS session. Our current type of authentication
("RSA-SHA256-TLSSecret", see tor-spec.txt section 4.4) does this by
signing a document that includes an HMAC of client_random and
server_random, using the TLS master secret as a secret key.
There is a more standard way to get at this information, by using the
facility defined in RFC5705. Further, it is likely to continue to.
work with more TLS libraries, including TLS libraries like OpenSSL 1.1
that make master secrets and session data opaque.
}}}
This is easy, and easily done as part of #15055Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/13752Extend TLS RSA link keys to 2048-bit2020-06-13T14:40:16ZNick MathewsonExtend TLS RSA link keys to 2048-bitWhen we implement proposal 220 , we'll need to have stronger per-connection TLS link keys, or else the link key will be the weak point.
In #6088, we investigated this; I made a branch called "ticket6088_hax" to try out the right fix.When we implement proposal 220 , we'll need to have stronger per-connection TLS link keys, or else the link key will be the weak point.
In #6088, we investigated this; I made a branch called "ticket6088_hax" to try out the right fix.Tor: 0.2.9.x-finalNick MathewsonNick Mathewson