Unable to Connect with safari or chrome canary

[ghost]

Hello Again!

so I tested my deployment today of this since you updated it so kindly! It appears I am running into a bit of a road block and I am unsure if its some setting I'm unaware of on my end or if there is something else at play.

every time I go to visit the page using the http2 server, I got this error:

SSL Error on 9 ('ip_address_redacted', 62999): [SSL: HTTP_REQUEST] http request (_ssl.c:777)

If I use curl (I have the latest version of curl) it works fine, I see the HTML of the page.

I am attempting to connect with Safari 11.1 and Chrome (Canary edition, latest) and Safari Technology Preview. All have the same Problem.

I know that they all support HTTP/2 though https://caniuse.com/#feat=http2

I am not using a self signed certificate either, its bound to my testing domain on the testing address with the correct cert/hostname.

For what its worth (and why I redacted the ip) I work for a large enough company that we can generate signed certs on the fly and I've yet to see them get flagged.

Any thoughts? Any way I can 'allow' this in some way ? right now there is no Nginx between me and the testing server

I am handing the server the full chain and key.

and heres the function I use to create the SSL context:

def create_ssl_context(certfile, keyfile):
    ssl_context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
    ssl_context.options |= (
        ssl.OP_NO_TLSv1 | ssl.OP_NO_TLSv1_1 | ssl.OP_NO_COMPRESSION
    )
    ssl_context.set_ciphers("ECDHE+AESGCM")
    ssl_context.load_cert_chain(certfile=certfile, keyfile=keyfile)
    ssl_context.set_alpn_protocols(["h2"])
    return ssl_context

[bdarnell]

OpenSSL's "http request" error means that you're connecting to a TLS server with what looks like a plaintext HTTP (1.x) request. So first double-check the basics: are you asking the browser for a https:// url?

When you use curl and it works, are you sure curl is using HTTP/2? (you can see this with curl -v) It's not enabled by default in many builds of curl.

Does the same ssl_context work for HTTP/1? (minus the set_alpn_protocols line. BTW, that gets set for you automatically in tornado_http2 so you shouldn't have to touch it)

Try the script in demo/hello.py in this repo. That works for me (I have to click through a self-signed cert warning) in chrome stable at https://localhost:8443.

[ghost]

@bdarnell Thanks for the quick response!

I did check the basics (and double checked them just now) still having the same issue. My curl by default spits verbose output I saw HTTP/2 all the way down (even double checked that I compiled it with http2 support).

With that said, I threw it behind my nginx test server with http2 enabled, worked like a charm.

so I just did some testing before I posted this, and it works (though Its not serving up my files from the locations I've given it, but that might be my weird symlink setup, I find python doesn't always handle that gracefully) and now it works, I changed the protocol [h2] map and called the ssl_context function before passing it to the server, seems to have done the trick. So if anyone sees this, don't set that. I'm not sure why the function needed to be passed to a variable before the setup though, thats odd to me, but I'll chalk that up to my potentially weird code hoops I have to jump through to meet certain annoyances security standards :)

[bdarnell]

I'm not sure why the function needed to be passed to a variable before the setup though, thats odd to me

I don't understand what this is referring to. If you're saying something is odd in tornado or tornado_http2, could you please clarify?

[ghost]

@bdarnell sorry I was writing as fast as I could and I could have explained that better.

In short, tornado http2 is working fine for me thus far without any issue, the thing I ran into here was that I was using a function to define the SSL context and I seemingly had to assign the function to a variable then hand it to tornado_http2 server for it to take SSL on run.

It turns out I was just doing it wrong, it actually works as expected when passed just the function. There's just a bunch of extra hurdles I have to go through when I go to deploy something in internally (this app I'm working on is being used internally where I am) for infosec reasons that I figured it was something weird on my end.

Sorry about the confusion, I'll remember to be more to the point going forward.