TLS NPN (Next Protocol Negotiation)
mikeperry at fscked.org
Tue Aug 17 21:23:38 UTC 2010
Thus spake Seth David Schoen (schoen at eff.org):
> Much of the debate centers around the idea that NPN will make it
> harder for network operators to know what protocols users are using
> over TLS and hence to block particular protocols while permitting
> others. One of the proponents (Adam Langley, who has been doing a
> lot of other fantastic work on making TLS better and more ubiquitous)
> mentioned the idea that Tor is an intended use case for this
> behavior, although there hasn't been any other explicit discussion
> of this.
It does seem like something we would try to use, but only if it were
deployed widely enough so that we weren't the only ones using it.
> I'm tempted to reply pointing out that _all_ uses of TLS represent
> at least potential support for a threat model in which a network
> operator is the adversary whom users are trying to defend against.
> So there's not much conceptually new about having TLS reduce network
> operators' control over traffic, although some of the people in
> the discussion seem to feel there is a qualitative difference
> between, say, keyword filtering and protocol filtering.
The point I would make is that its very likely that most services
will continue to operate on their traditional tcp ports, regardless of
Administrators hoping to be able to block protocols by a TLS
fingerprint seem to be barking up the wrong tree. Anyone wishing to
subvert their controls will use a custom TLS/stunnel bridge on an
acceptable port as defined by their policy. I think this indicates
that you are right.
The more effecive way I have seen to do these sorts of controls is by
policy enforcement on the software that the machines themselves can
run, rather than on the network.
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the tor-talk