Shib IdP V3.2.1, Jetty 9.3.6, and HTTP/2

[Tom Scavo]

On Wed, Feb 3, 2016 at 10:29 AM, David Langenberg <davel at uchicago.edu> wrote:
> I found I had to add this to alpn.ini to get older clients to behave.
>
> ## Specifies what protocol to use when negotiation fails.
> jetty.alpn.defaultProtocol=http/1.1

Thanks Dave, that did the trick. We added that stanza to our jetty
config and now the server responds as expected:

$ STATUS_PAGE=https://idp.williams.edu/idp/profile/Status
$ curl --silent --dump-header /dev/tty $STATUS_PAGE > /dev/null
HTTP/1.1 404 Not Found
Set-Cookie: JSESSIONID=fz1p7u4nl6yt1pc0tvaoor18m;Path=/idp;Secure
Content-Type: text/html;charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 334
Server: Jetty(9.3.6.v20151106)

Here's a brief summary of the issue (YMMV):

Some HTTP clients (including popular browsers) fail to negotiate a TLS
session with a Jetty server with the http2 module enabled. [1] Unless
you control the clients, the recommended solution is to configure
Jetty as follows:

## Specifies what protocol to use when negotiation fails.
jetty.alpn.defaultProtocol=http/1.1

Btw, ALPN is the TLS Application-Layer Protocol Negotiation Extension. [2]

That's my two cents anyway. Not sure what the project wants to recommend.

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=479658
[2] https://tools.ietf.org/html/rfc7301

>> On Feb 2, 2016, at 5:25 PM, Tom Scavo <trscavo at gmail.com> wrote:
>>
>> I'm working with a colleague at Williams College to register metadata
>> for a v3.2.1 IdP deployment. Just beneath the surface of this IdP,
>> there is some weirdness going on. We believe we can trace it to Jetty
>> 9.3.6 but first let me provide the symptoms.
>>
>> The URL that exhibits the problem is an old V2 Status URL:
>>
>> https://idp.williams.edu/idp/profile/Status
>>
>> Shib IdP V3.2.1 should return 404 on such a request, and for some
>> browser clients (such as Chrome) that is exactly what happens. Other
>> browser clients are all over the map.
>>
>> Curl on my Mac produces this:
>>
>> $ curl --verbose https://idp.williams.edu/idp/profile/Status
>> *   Trying 137.165.4.25..
>> * Connected to idp.williams.edu (137.165.4.25) port 443 (#0)
>> * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> * Server certificate: idp.williams.edu
>> * Server certificate: COMODO RSA Organization Validation Secure Server CA
>> * Server certificate: COMODO RSA Certification Authority
>> * Server certificate: AddTrust External CA Root
>>> GET /idp/profile/Status HTTP/1.1
>>> Host: idp.williams.edu
>>> User-Agent: curl/7.43.0
>>> Accept: */*
>>>
>> * Connection #0 to host idp.williams.edu left intact
>> invalid_preface
>>
>> Other curls on other client machines produce different results but
>> none of them 404.
>>
>> We've googled and experimented and have come up short. Evidence is
>> pointing to Jetty and its handling of HTTP/2 but we can't be sure.
>>
>> Has anyone else seen anything like this? Other suggestions?
>>
>> Thanks in advance,
>>
>> Tom
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
>
> --
> David Langenberg
> Identity & Access Management Architect
> The University of Chicago
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net