On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes <[email protected]> wrote: > It requires awareness in the following sense: If by chance the client is > in a nice, open network and the base TLS connection goes directly to the > server, CONNECT is kind of unnatural; you would want the client to do > something different in that case. >
Surely this is equally true/untrue of ATLS. Why do double-TLS if it can be avoided? But then, how does the application know whether to do ATLS encapsulation? It's the same question in both cases. > You're correct that you *could* configure the server to handle connect > properly, but all of the options for doing this are kind of cumbersome -- > either you have to stick a possibly-unnecessary proxy in front of the > server, or handle CONNECT on the server, which is not really well-supported > by web application frameworks. By contrast, running data over POST is > ubiquitous. > This makes a certain amount of sense to me. If it were up to me, rather than design a TLS-specific transport, I'd be more inclined to propose a standardized version of something like Crowbar <https://github.com/q3k/crowbar>. (Or just document that reverse proxies and frameworks ought to do something reasonable with CONNECT.) Otherwise this seems to be ossifying the proxy, privileging TLS and preventing deployment of Noise protocol <http://noiseprotocol.org/> or whatever the future may hold. It was also pointed to me off-list that you can generate POST requests from > Javascript in XHR, but not CONNECT requests. So doing this over POSTs also > makes it accessible to web apps. (`emscripten libssl.a` left as an > exercise to the reader.) > It seems your threat model assumes an adversary who is an active intermediary in your HTTP session. If so, then this wouldn't seem to protect the user against the threat. > > > --Richard > > > On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz <[email protected]> wrote: > >> I don't understand why ATLS allows the app to be less "aware" than HTTP >> CONNECT. I also don't understand how an ATLS client is closer to "one code >> path" than HTTP CONNECT. It seems to me that your description of client >> behavior applies equally to ATLS and HTTP CONNECT. >> >> On Mon, Oct 30, 2017 at 6:38 PM, Richard Barnes <[email protected]> wrote: >> >>> But I agree, it would be good to have some more clarity around use cases >>> and why not other solutions. >>> >>> On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes <[email protected]> wrote: >>> >>>> HTTP CONNECT is not great for some use cases because it requires the >>>> app to be aware that it's dealing with a proxy. It's simpler if you can >>>> just have one code path that works whether your TLS is intermediated or >>>> not. With the solution outlined in the draft, you can just always ignore >>>> the certificate the server sends in the first TLS connection (because it >>>> might be from a MitM), and then do all your cert validation, pin checks, >>>> etc. at the application layer. >>>> >>>> On Mon, Oct 30, 2017 at 6:26 PM, Ben Schwartz <[email protected]> >>>> wrote: >>>> >>>>> Why not use HTTP CONNECT? Or rather, it would be helpful to have a >>>>> section on when/why one would do this vs. CONNECT. >>>>> >>>>> On Mon, Oct 30, 2017 at 6:17 PM, Richard Barnes <[email protected]> wrote: >>>>> >>>>>> Hey TLS folks, >>>>>> >>>>>> Owen, Max, and I have been kicking around some ideas for how to make >>>>>> secure connections in environments where HTTPS is subject to MitM / >>>>>> proxying. >>>>>> >>>>>> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of >>>>>> creating a channel you could use when you really need things to be >>>>>> private, >>>>>> even from the local MitM. >>>>>> >>>>>> Feedback obviously very welcome. Interested in whether folks think >>>>>> this is a useful area in which to develop an RFC, and any thoughts on how >>>>>> to do this better. >>>>>> >>>>>> Thanks, >>>>>> --Richard >>>>>> >>>>>> >>>>>> On Mon, Oct 30, 2017 at 3:47 PM, <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-friel-tls-over-http-00.txt >>>>>>> has been successfully submitted by Owen Friel and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Name: draft-friel-tls-over-http >>>>>>> Revision: 00 >>>>>>> Title: Application-Layer TLS >>>>>>> Document date: 2017-10-30 >>>>>>> Group: Individual Submission >>>>>>> Pages: 20 >>>>>>> URL: https://www.ietf.org/internet- >>>>>>> drafts/draft-friel-tls-over-http-00.txt >>>>>>> Status: https://datatracker.ietf.org/ >>>>>>> doc/draft-friel-tls-over-http/ >>>>>>> Htmlized: https://tools.ietf.org/html/d >>>>>>> raft-friel-tls-over-http-00 >>>>>>> Htmlized: https://datatracker.ietf.org/ >>>>>>> doc/html/draft-friel-tls-over-http-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> Many clients need to establish secure connections to application >>>>>>> services but face challenges establishing these connections due to >>>>>>> the presence of middleboxes that terminate TLS connections from >>>>>>> the >>>>>>> client and restablish new TLS connections to the service. This >>>>>>> document defines a mechanism for transporting TLS records in HTTP >>>>>>> message bodies between clients and services. This enables clients >>>>>>> and services to establish secure connections using TLS at the >>>>>>> application layer, and treat any middleboxes that are intercepting >>>>>>> traffic at the network layer as untrusted transport. In short, >>>>>>> this >>>>>>> mechanism moves the TLS handshake up the OSI stack to the >>>>>>> application >>>>>>> layer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission >>>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>>> >>>>> >>>> >>> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
