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