As difficult as what you describe below
would be, using draft-rhrd-tls-tls13-visibility to snoop would be
much more complicated. They would need to need to get their
"special" browsers onto all of the students' devices, but then,
unlike in the scenario below, that would only be the beginning of
what they need to do. They would need to active cooperation of
every TLS-protected server that the students could connect to and
they would need an infrastructure for obtaining and managing all
of the keys that they would be getting from all of these servers.
[In practice, of course, there wouldn't be that many keys since
practically no servers would cooperate in this scheme.]
So, yes, setting up a scheme to snoop on all outgoing TLS-protected traffic would not be easy. However, draft-rhrd-tls-tls13-visibility would not make it easier than it currently is, as implementing something based on draft-rhrd-tls-tls13-visibility would be far more difficult than using currently available methods. And, I don't buy the idea that if this extension is standardized that it will be implemented in commonly-used browsers. We don't have to "keep all the plates spinning" in order to prevent this extension from "escaping" on to the public Internet. This isn't something that could "accidentally" be implemented in browsers if browser vendors don't take extreme precautions to prevent it from happening. Browser vendors would have to pro-actively decide to implement this, and I don't see that happening. The idea that someone would set up a service that would only work if browsers implemented this extension, and then browsers would be "forced" to implement the extension so that this service would work isn't realistic. A server that wanted to allow third party interception of traffic between itself and its clients wouldn't require this extension and then wait for browsers to implement the extension. It would just use TLSv1.2 with RSA key exchange (or something like draft-green-tls-static-dh-in-tls13), and then set up the interception capability without the client's knowledge. On 10/24/2017 04:38 PM, Yoav Nir wrote: On 24 Oct 2017, at 22:54, David A. Cooper <david.coo...@nist.gov> wrote:Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the schools? If a school wants to snoop on its students' traffic, it would do so in a much easier way than using draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today use middleboxes to inspect all outgoing traffic.Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all but the most orderly of enterprises. You need to have all clients trust the middlebox CA. Fine, so the Windows computers get that installed through SMS or GPO or whatever the central configuration feature is called these days. The people with Macs have to figure it out for themselves, and the same goes for people with phones. Oh, and also for people who use Firefox, because that browser comes with its own trust store. The people on this list can probably figure it out with a little web search. A school with a thousand students all bringing their own devices? Good luck.This browser that students would be required to use would be one that has a CA controlled by the middlebox installed as a trust anchor. Whenever one of the students' clients tries to connect to an external secure site, the middlebox-controlled CA issues a certificate for that site so that the connection can be terminated at the middlebox. The middlebox then establishes a secure connection with the end server, thus setting up the middlebox as a MiTM.It’s one thing to say that SchoolBrowser (conveniently located in the app stores of all phone and computer OS-es) works in this school (and all the others). It’s a totally different thing to fill the app stores with “GrizzlyBrowser for Logan High School students” and “MustangBrowser for Mountain Crest High School students"There are already middleboxes on the market today that do this. They work for all outgoing connections and don't require any cooperation whatsoever from the outside servers that the clients are trying to connect to, and only expert users would notice the presence of the MiTM.Unless they had to configure their browser themselves. The support costs of these is tremendous.
|
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls