Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#4570 closed defect (wontfix)

Implement certificate serial number covert channel (part of proposal 179)

Reported by: asn Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-bridge
Cc: ioerror Actual Points:
Parent ID: #3972 Points:
Reviewer: Sponsor:

Description

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?

Child Tickets

Change History (9)

comment:1 in reply to:  description ; Changed 8 years ago by 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?

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.

comment:2 in reply to:  1 ; Changed 8 years ago by asn

Summary: Implement certificate start time fuzzing and serial number covert channel (part of proposal 179)Implement certificate serial number covert channel (part of proposal 179)

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

comment:3 in reply to:  2 ; Changed 8 years ago by 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.


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.

comment:4 in reply to:  3 Changed 8 years ago by asn

Cc: ioerror added

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).

comment:5 Changed 8 years ago by 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?

comment:6 Changed 8 years ago by nickm

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.

comment:7 in reply to:  5 Changed 8 years ago by nickm

Resolution: wontfix
Status: newclosed

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.

comment:8 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:9 Changed 7 years ago by nickm

Component: Tor BridgeTor
Note: See TracTickets for help on using tickets.