Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL failure when using ALPN and http1.1 (not http2) #2791

Closed
jroper opened this issue Oct 30, 2019 · 2 comments · Fixed by #2795
Closed

SSL failure when using ALPN and http1.1 (not http2) #2791

jroper opened this issue Oct 30, 2019 · 2 comments · Fixed by #2795

Comments

@jroper
Copy link
Contributor

@jroper jroper commented Oct 30, 2019

Here's an example of what happens when you make a request using curl to an https and http2 enabled akka-http server using http1.1. I believe that the problem is that akka-http is returning h1, which is incorrect, it should return http/1.1, like curl is offering. It should probably also check that http/1.1 is in the list of protocols requested, rather than just returning it.

$ curl https://34.74.175.178:8443 -k -v --http1.1
* Expire in 0 ms for 6 (transfer 0x559e1d72e5c0)
*   Trying 34.74.175.178...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x559e1d72e5c0)
* Connected to 34.74.175.178 (34.74.175.178) port 8443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS alert, no application protocol (632):
* error:14094460:SSL routines:ssl3_read_bytes:reason(1120)
* Closing connection 0
curl: (35) error:14094460:SSL routines:ssl3_read_bytes:reason(1120)
@jroper

This comment has been minimized.

Copy link
Contributor Author

@jroper jroper commented Oct 30, 2019

This would be a great issue for a new contributor. Here's the registry of ALPN protocol ids:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Here's the code with the bug in it (you can see twice it's selecting h1):

https://github.com/akka/akka-http/blob/master/akka-http2-support/src/main/scala/akka/http/impl/engine/http2/Http2AlpnSupport.scala

There's also a reference to h1 here:

def getChosenProtocol(): String = chosenProtocol.getOrElse("h1") // default to http/1, e.g. when ALPN jar is missing

Though that one's benign because the place that uses it ignores it:

val chosen = chosenProtocolAccessor(first)
chosen match {
case "h2" => install(http2Stack.addAttributes(HttpAttributes.tlsSessionInfo(session)), first)
case _ => install(http1Stack, first)
}

Nevertheless, this code could do with some constants introduced, and if http/1.0 or http/1.1 are selected, they should be returned. And if neither http/1.0, http/1.1 or h2 are selected, then it should not try and return something that the client didn't request. There's a specific error to return:

https://tools.ietf.org/html/rfc7301#section-3.2

Based on the error message from curl above, I guess the JDK is validating what is returned and when it's not one that the client requested, it's doing that appropriately, but presumably the JDK and/or Jetty APIs offer a better way to do that than returning something wrongly (maybe returning null?).

@jrudolph

This comment has been minimized.

Copy link
Member

@jrudolph jrudolph commented Oct 30, 2019

Great finding and write up, thanks @jroper.

jtjeferreira added a commit to jtjeferreira/akka-http that referenced this issue Nov 2, 2019
jrudolph added a commit that referenced this issue Nov 18, 2019
@jrudolph jrudolph added this to the 10.1.11 milestone Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.