Support for HTTP/2 Protocol in ArcGIS Enterprise

[Felipe_Costa]

Hello everyone,

I’d like to ask if anyone has experience with enabling or configuring HTTP/2 for ArcGIS Enterprise (Portal, ArcGIS Server, and related components). Does ArcGIS Enterprise natively support HTTP/2, or does it depend entirely on the web server/reverse proxy (e.g., IIS, or Apache)?

We received a request from our security team to check "HTTP/1.1 request smuggling vulnerabilty" within ArcGIS Enterprise components.

We are considering enabling HTTP/2 in our environment to optimize client connections and would and minimize the risk of attacks, and appreciate any insights or experiences from the community, but I did no find how to implement it on ArcGIS Server and Portal so far.

Thanks in advance!

[Leena_Abdulqader]

Hi @Felipe_Costa, That is tricky, I have never tried such thing, but I believe ArcGIS Enterprise itself does not currently support HTTP/2 directly, it's limited to HTTP/1.1. To enable HTTP/2 I guess you could configure it at the web adaptor in IIS /reverse proxy layer.

[BillMitchell]

Hi @Felipe_Costa, we have tried to update some configuration files and it seems to have worked, at least in initial testing (non-production environment).

The :7443 and :6443 ports are served under the hood by Tomcat.  Tomcat >=8.5 supports HTTP/2.  You don't mention what version of ArcGIS Enterprise you're running, but my Enterprise 11.2 instance is on Tomcat 9, and Enterprise 11.5 (where I tested) is on Tomcat 10.1.

The configuration files you're looking for are `server.xml`:

C:\Program Files\ArcGIS\Portal\framework\runtime\tomcat\conf\server.xml

C:\Program Files\ArcGIS\Server\framework\runtime\tomcat\conf\server.xml

Within these, you're looking for the lines that look vaguely like this (simplified here):

<Connector SSLEnabled="true" [...] maxThreads="150"
port="7443" protocol="org.apache.coyote.http11.Http11Nio2Protocol"
relaxedQueryChars="" scheme="https" secure="true" server=" ">
      <SSLHostConfig [...]>
        <Certificate certificateKeyAlias="portal"
          certificateKeystoreFile="../../../etc/ssl/portal.ks"
          certificateKeystorePassword="portal.secret"
          certificateKeystoreType="PKCS12"/>
      </SSLHostConfig></Connector>

From there, you need to add 
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/>  before the <SSLHostConfig>.

That leaves us with something like this:

<Connector SSLEnabled="true" [...] maxThreads="150"
port="7443" protocol="org.apache.coyote.http11.Http11Nio2Protocol"
relaxedQueryChars="" scheme="https" secure="true" server=" ">
      <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/>
      <SSLHostConfig [...]>
        <Certificate certificateKeyAlias="portal"
          certificateKeystoreFile="../../../etc/ssl/portal.ks"
          certificateKeystorePassword="portal.secret"
          certificateKeystoreType="PKCS12"/>
      </SSLHostConfig></Connector>

Restart the Portal or ArcGIS Server service (via the Windows Services utility, or simply a reboot) and you should be able to verify with developer tools that a browser to :6443 and :7443 shows a protocol of h2.  

This largely follows a simpler explanation (non-ArcGIS related).

[MikeDolbow]

If, like me, you're just running Server, that server.xml file can be found in C:\ArcGIS\Server\framework\runtime\tomcat\conf

My testing so far looks successful too.

[BillMitchell]

As for the HTTP Request Smuggling, it seems like that is primarily an issue when you have HTTP/2 traffic to a proxy/load balancer which then downgrades to HTTP/1.1 with the backend.  Using HTTP/2 to the backend, as you are trying to do, cuts out those attacks.  For more info, there are some talks by James Kettle from DefCon that go into how the attacks work and what mitigations can be used (e.g. why this was brought up and why HTTP/2 for the backend is a necessary default), for instance DefCon29 - HTTP/2 The Sequel is Always Worse and DefCon33 - HTTP 1.1 Must Die, and a write-up from 2019 that goes into a little more detail.