[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: TLS NPN (Next Protocol Negotiation)

Thus spake Seth David Schoen (schoen@xxxxxxx):

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

Mike Perry
Mad Computer Scientist
fscked.org evil labs

Attachment: pgpmc21GCpNsU.pgp
Description: PGP signature