[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29583 [Core Tor/Tor]: HSv3: Faulty cross-certs in introduction point keys (allows naive onionbalance for v3s)
#29583: HSv3: Faulty cross-certs in introduction point keys (allows naive
onionbalance for v3s)
-----------------------------------------+---------------------------------
Reporter: asn | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs scaling onionbalance | Actual Points:
Parent ID: #26768 | Points:
Reviewer: | Sponsor:
-----------------------------------------+---------------------------------
Description changed by asn:
Old description:
> During a discussion with Nick and David, we figured out that we messed up
> the cross certificates of the introduction point keys in the HSv3
> descriptors.
>
> In particular the spec asks to cross-certificate the descriptor signing
> key using the introduction point auth key, but it seems like we are doing
> it the other way around in the code:
> {{{
> desc_ip->auth_key_cert = tor_cert_create(signing_kp,
> CERT_TYPE_AUTH_HS_IP_KEY,
> &ip->auth_key_kp.pubkey,
> nearest_hour,
> HS_DESC_CERT_LIFETIME,
> CERT_FLAG_INCLUDE_SIGNING_KEY);
> }}}
> same goes for the intro point encryption key. However, it seems that the
> legacy encryption key cross-cert was made properly.
>
> This is very related to the onionbalance for v3 ticket (parent of this)
> because these two cross-certs certs was exactly what was preventing us
> from doing the naive onionbalance for v3s.
>
> So here are some steps forward:
>
> a) Figure out if there are any other points where we have messed up cross
> certs in the code. Figure out the precise dangers of the cross certs we
> messed up.
>
> With David we scanned the HSv3 code and it seems like these two are
> the only certs we messed up. If we are right, this means that this bug
> allows some fairly low-severity attacks like `FairPretender` from #15951.
> We should make sure we know exactly what attacks this opens us up to.
>
> b) We should decide if we want to fix this or not. Fixing this would
> likely involve making a new descriptor version with the right cross-
> certs, so that clients can verify both the old version and the new one.
> It will require some engineering but not too much. If we care about the
> attacks, we shoul fix it. However, if we don't care about these attacks,
> we can "not fix it", which will also probably allow us to do naive
> onionbalance for v3s.
>
> As a side-task that can be done paralelly we should revise and improve
> the spec when it comes to cross-certs because it's currently quite
> confusing. We should properly define cross-certs and what they do, and we
> should also improve the wording in places (e.g. there is bad wording even
> in `descriptor-signing-key-cert` even tho the code is right), and we
> should update the spec based on what we decide in this ticket.
>
> I have CCed twim who reported the FairPretender attack in this ticket,
> and we should think about this more!
New description:
During a discussion with Nick and David, we figured out that we messed up
the cross certificates of the introduction point keys in the HSv3
descriptors.
In particular the spec asks to cross-certificate the descriptor signing
key using the introduction point auth key, but it seems like we are doing
it the other way around in the code:
{{{
desc_ip->auth_key_cert = tor_cert_create(signing_kp,
CERT_TYPE_AUTH_HS_IP_KEY,
&ip->auth_key_kp.pubkey,
nearest_hour,
HS_DESC_CERT_LIFETIME,
CERT_FLAG_INCLUDE_SIGNING_KEY);
}}}
same goes for the intro point encryption key. However, it seems that the
legacy encryption key cross-cert was made properly.
This is very related to the onionbalance for v3 ticket (parent of this)
because these two cross-certs certs was exactly what was preventing us
from doing the naive onionbalance for v3s.
So here are some steps forward:
a) Figure out if there are any other cases where we have messed up
cross certs in the code. Figure out the precise dangers of the cross certs
we messed up.
With David we scanned the HSv3 code and it seems like these two are the
only certs we messed up. If we are right, this means that this bug allows
some fairly low-severity attacks like `FairPretender` from #15951. We
should make sure we know exactly what attacks this opens us up to.
b) We should decide if we want to fix this or not. Fixing this would
likely involve making a new descriptor version with the right cross-certs,
so that clients can verify both the old version and the new one. It will
require some engineering but not too much. If we care about the attacks,
we shoul fix it. However, if we don't care about these attacks, we can
"not fix it", which will also probably allow us to do naive onionbalance
for v3s.
As a side-task that can be done paralelly we should revise and improve the
spec when it comes to cross-certs because it's currently quite confusing.
We should properly define cross-certs and what they do, and we should also
improve the wording in places (e.g. there is bad wording even in
`descriptor-signing-key-cert` even tho the code is right), and we should
update the spec based on what we decide in this ticket.
I have CCed twim who reported the FairPretender attack in this ticket, and
we should think about this more!
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29583#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs