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. 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.
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.) --Richard On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz <bem...@google.com> 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 <r...@ipv.sx> 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 <r...@ipv.sx> 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 <bem...@google.com> 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 <r...@ipv.sx> 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, <internet-dra...@ietf.org> 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 >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>> >>>>> >>>> >>> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
