[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4570 [Tor Bridge]: Implement certificate serial number covert channel (part of proposal 179)
#4570: Implement certificate serial number covert channel (part of proposal 179)
------------------------+---------------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge | Version:
Keywords: | Parent: #3972
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by nickm):
Replying to [comment:4 asn]:
> Replying to [comment:3 nickm]:
> > Replying to [comment:2 asn]:
> >
> > > We will always have false positives with this scheme, till all the
non-0.2.3.x relays disappear from the network.
> >
> > Unless we use the other v3-indicating cert features plus the SN to
indicate
> >
> > Let's take a step back -- do you currently think this feature is a
good idea? I don't think it's workable if we have user-provided certs,
and I think that getting user-provided certs to work is more important
than this.
> >
>
> I don't think it's a good idea.
Then let's not do it, if neither one of us is advocating for it. We don't
need to reach agreement about why we don't want to do it in order not to
do it. :)
I'm going to mark this as wontimplement and close it. After responding
below, of course!
>
> I can see a use for it, but like you said, it kills the user-provided
/CA-signed certs idea (which is *very* important). Less importantly, it
provides a "at 75% this is a Tor relay" fingerprint to censors
Probability error.
Suppose there are 1e6 SSL sites, and 1e4 tor nodes. (I'm deliberately
skewing the estimates.) Suppose that if you see a "special" SN, you can
conclude that it might be a Tor node, but if you see a "non-special" SN,
you can conlude that it is definitely not a Tor node. Suppose that 25% of
all other nodes have a special SN by accident.
If you see a special SN, would you know with P=75% that it's a Tor node?
Nope! Bayes's Theorem gives P(tor|special) = P(special|tor) * P(tor) /
P(special) = 1 * (1e4/[1e4+1e6]) / ([1e4 + .25 * 1e6] / [1e4+1e6]) =
about 3.8%.
>, and it feels very hacky and last-hope to a problem we are not currently
having
"we are not having this problem currently" is not a great argument against
future-proofing.
>, since:
> - v3 seems good.
> - future 'in-protocol' link protocols can be negotiated by sending a
v3-signaling SSL handshake and then negotiating v4 over VERSIONS.
> - if we ever need to negotiate 'some other kind of TLS handshake' (for
whatever reason) we can use signalling in the SSL handshake but outside of
the Certificate. For example, we can use the SessionTicket field in the
ServerHello (which relays currently send empty), or use another TLS
extension (which are getting popular lately with ECC).
This last one actually _is_ pretty persuasive. So, as mentioned, closing.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4570#comment:6>
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