Implement certificate serial number covert channel (part of proposal 179)
This ticket is for tracking the implementation of certificate start time fuzzing and serial number covert channel.
Jake implemented both of these in his prop179 branch.
wrt the serial number thing, if we decide to allow users to input their own TLS certificates, the serial number covert channel will get poluted. I think it's time to think if we really need this covert channel, or if we care that we will get false positives with user-specific certificates.
For link protocol version negotiation, we have the VERSIONS cell. We might need a covert channel on the SSL handshake, if we need to negotiate the link protocol version before the Tor protocol. In which cases do we need such a visible covert channel?
Activity
Replying to asn:
This ticket is for tracking the implementation of certificate start time fuzzing and serial number covert channel.
I'm not sure it makes sense to have both of these in one ticket; are they actually related in some way I'm not getting?
Jake implemented both of these in his prop179 branch.
wrt the serial number thing, if we decide to allow users to input their own TLS certificates, the serial number covert channel will get poluted. I think it's time to think if we really need this covert channel, or if we care that we will get false positives with user-specific certificates.
If we want to do this, we need to care about false positives, or else it's useless. (If there are false positives, then we can't safely use the hypothetical v4 link protocol whenever we see the hypothetical v4 indicator.)
For link protocol version negotiation, we have the VERSIONS cell. We might need a covert channel on the SSL handshake, if we need to negotiate the link protocol version before the Tor protocol. In which cases do we need such a visible covert channel?
The question isn't whether we need a visible one; it's whether we'll ever need to do again what we've done with the v1->v2 and v2->v3 link protocol transition, where the client learns which handshake it is before the handshake is actually done, so that the client can act differently, depending. I think that v3 should be flexible enough to last indefinitely, but we should actually figure this out.
Replying to nickm:
Replying to asn:
This ticket is for tracking the implementation of certificate start time fuzzing and serial number covert channel.
I'm not sure it makes sense to have both of these in one ticket; are they actually related in some way I'm not getting?
It does not make sense. I'm restricting this to the serial number thing.
Jake implemented both of these in his prop179 branch.
wrt the serial number thing, if we decide to allow users to input their own TLS certificates, the serial number covert channel will get poluted. I think it's time to think if we really need this covert channel, or if we care that we will get false positives with user-specific certificates.
If we want to do this, we need to care about false positives, or else it's useless. (If there are false positives, then we can't safely use the hypothetical v4 link protocol whenever we see the hypothetical v4 indicator.)
We will always have false positives with this scheme, till all the non-0.2.3.x relays disappear from the network.
For link protocol version negotiation, we have the VERSIONS cell. We might need a covert channel on the SSL handshake, if we need to negotiate the link protocol version before the Tor protocol. In which cases do we need such a visible covert channel?
The question isn't whether we need a visible one; it's whether we'll ever need to do again what we've done with the v1->v2 and v2->v3 link protocol transition, where the client learns which handshake it is before the handshake is actually done, so that the client can act differently, depending. I think that v3 should be flexible enough to last indefinitely, but we should actually figure this out.
VERSIONS cells should be enough to negotiate future 'in-protocol' link protocols.
A covert channel like the one described in 178 could find use:
a) If we needed to do our link protocol in the initial SSL handshake. But we've grown old for that, no?
b) If we needed to negotiate the link protocol before the Tor protocol hits the wire. This sounds like an anti-bridge-detection measure, but I can't find any scenarios where such a visible covert channel would help [0].
Can you describe a use case where VERSIONS wouldn't do it and this serialNumber covert channel would help?
[0]: On the other hand, a covert channel based on a shared secret has some uses. See 5.1: https://lists.torproject.org/pipermail/tor-dev/2011-November/003070.html
Trac:
Summary: Implement certificate start time fuzzing and serial number covert channel (part of proposal 179) to Implement certificate serial number covert channel (part of proposal 179)-
Replying to 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.
For link protocol version negotiation, we have the VERSIONS cell. We might need a covert channel on the SSL handshake, if we need to negotiate the link protocol version before the Tor protocol. In which cases do we need such a visible covert channel?
The question isn't whether we need a visible one; it's whether we'll ever need to do again what we've done with the v1->v2 and v2->v3 link protocol transition, where the client learns which handshake it is before the handshake is actually done, so that the client can act differently, depending. I think that v3 should be flexible enough to last indefinitely, but we should actually figure this out.
VERSIONS cells should be enough to negotiate future 'in-protocol' link protocols.
A covert channel like the one described in 178 could find use:
a) If we needed to do our link protocol in the initial SSL handshake. But we've grown old for that, no?
Well, we did need to negotiate v1 vs v2 this way, and v2 vs v3 this way. We couldn't use VERSIONS cells, since these connection varieties differ in their TLS handshakes.
b) If we needed to negotiate the link protocol before the Tor protocol hits the wire. This sounds like an anti-bridge-detection measure, but I can't find any scenarios where such a visible covert channel would help [0].
Can you describe a use case where VERSIONS wouldn't do it and this serialNumber covert channel would help?
Yes; the case of how we negotiate v1 vs v2, and v2 vs v3 now. If we need to do some other kind of TLS handshake, then the VERSIONS cell can't help us, since that happens after the TLS handshake.
-
Replying to nickm:
Replying to 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.
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, and it feels very hacky and last-hope to a problem we are not currently having, 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).
Trac:
Cc: N/A to ioerror -
Replying to asn:
Replying to nickm:
Replying to 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.
-
Replying to ioerror:
Why does it kill the ability for people to use their own certs? We should just assume that if someone has supplied a cert, it's the new handshake. Why not?
The point of the special-SN thing was to handle the case where we needed to introduce a new v4 TLS handshake later on. If somebody has supplied a cert, we can indeed conclude that it's a v3 handshake. The idea was to distinguish v3 (the new thing) from the as-yet-undesigned v4 TLS thing.
Trac:
Resolution: N/A to wontfix
Status: new to closed mentioned in issue #4584 (moved)
moved to tpo/core/tor#4570 (closed)
mentioned in issue tpo/core/tor#4584 (closed)