HTTP/2 without tls

[jonathan...@gmail.com]

Is it possible to use the new 1.6 HTTP/2 support without TLS? I'd like to use the protocol over a tunnel that is already secure.

[msilv...@cloudflare.com]

Yes, if you wire up your own Transport/Client you can use h2c instead of h2. I can't find the example at the moment, but start digging from here: https://github.com/golang/go/issues/14141

[jonathan...@gmail.com]

Man I don't even know where to start, any idea where abouts the example could be?

[Micky]

Currently, no browser supports HTTP2 on non-secure connections.
Are you sure, you want to do this? It's hard though not impossible. But the effort may not be worth it.

On Fri, Apr 1, 2016 at 8:06 PM, <jonathan...@gmail.com> wrote:

Is it possible to use the new 1.6 HTTP/2 support without TLS? I'd like to use the protocol over a tunnel that is already secure.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jonathan...@gmail.com]

Yes it's to use within a company through an existing secure tunnel, no reason for the extra overhead.

[jonathan...@gmail.com]

Any kind of beginnings of an example would be extremely useful :)

[Micky]

You'll have to replace the stuff that does NPN and ALPN. And rather rely on "Upgrade: h2" for HTTP2 negotiation so both client and server can agree on what to use. This of course costs a full round trip.

If you haven't already looked at the protocol specs, I recommend:

• Read Daniel Stenberg's and Ilya Grigorik's http2 awesome protocol intros
  
• Go through Brad Fitz's recent net/http2 talks (slide 101 onwards)

[jonathan...@gmail.com]

Aw man I was hoping it was something already supported but took some configuration :(

[Micky]

Man, you really have to understand how H2 works. Your overhead for removing TLS will be equivocally the same as cost of extra round trips per connection.

And TLS is not a slow or bad thing, if you know man what i mean ;):

https://istlsfastyet.com/

On Mon, Apr 4, 2016 at 5:21 AM, <jonathan...@gmail.com> wrote:

Aw man I was hoping it was something already supported but took some configuration :(

[jonathan...@gmail.com]

Thanks Micky, I'll start benchmarking a TLS terminating proxy with another TLS connection on the other side instead of a tunnel. Funny thing is I really never say 'man' :) that was just for you :P

[Micky]

Ha ha!

Me too.

:)

On Tue, Apr 5, 2016 at 4:01 AM, <jonathan...@gmail.com> wrote:

Thanks Micky, I'll start benchmarking a TLS terminating proxy with another TLS connection on the other side instead of a tunnel. Funny thing is I really never say 'man' :) that was just for you :P

[not...@google.com]

FWIW:   TLS is fast once the connection is established, but the initial handshake is slow (~10ms of CPU time, when I checked a few months ago). If you are doing lots of connections per second you might start noticing slowdown.  

[jonathan...@gmail.com]

Any guidance on how to make a request on an existing tlc net.Conn? I am assuming that I can serve http2 over an existing tls net.Conn via http2.ServeConn()?

[jonathan...@gmail.com]

So I have a tls.Conn that is past the handshake, and I feed it into http.ServeConn() but once it serves the first request (which is successful) it returns. Is that intended?

[jonathan...@gmail.com]

Should I even be using http2.ServeConn()? I have a single tls.Conn between two machines and I need to take traffic off the tls.Conn and serve it to a local http2 server.

[jonathan...@gmail.com]

Ok i got this to work, for anyone reading this the trick was to provide a ClientConnPool to the http2.Transport. Which is a strange thing because in order to create a *http.ClientConn you have to use the http.Transport.NewClientConn() and yet the ConnPool is a field on the transport. So even in the standard lib you can see they just create an empty pointer to the pool, create the transport, then set the transport in the pool. A bit odd but it seems to work.

[jeffer...@gmail.com]

HTTP2 supports both, decrypt and encrypt ways, however, browsers like  Firefox ,Chrome, and IE, doesn't allowed this protocol without security protocols. 

Ref. http://undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html