3

I'm looking into the possibility of using Windows Server 2016 for a group of web servers which are behind a load balancer that uses SSL offloading.

For me, the biggest advantage of Windows Server 2016 over 2012 is that the HTTP/2 protocol can be used. However, because HTTP/2 is generally being implemented against HTTPS I'm concerned that requests will not be recognised as HTTPS because they arrive as HTTP (albeit with an x-forwarded-proto header). I did look and found a few resources on it but there isn't a lot of concrete evidence.

Does anyone know if IIS will support this setup and still send the response over HTTP/2, or will all traffic simply fall back to HTTP/1.1? Is there a way to configure/trick (!) IIS into using HTTP/2 on a request which may look unsecure?

Thanks.

Edit: To clarify, the load balancer will send x-forwarded-proto:https to the server, but the requesting application sees it as unsecure because of the SSL offloading.

Dan Atkinson
  • 578
  • 1
  • 8
  • 12
  • This is somewhat unclear. It seems like you wish to issue an `http:` call containing `X-Forwarded-Protocol: https` and have it treated as `https:`? This is doubtful as the resource you quoted says: "IIS currently supports HTTP/2 only over TLS". But it should be easy enough to test this on a WS2016 VM. – harrymc Aug 04 '17 at 12:15
  • If Windows Server 2012 supports HTTP/2 then 2016 supports it. Only TLS 1.2+ is considered secure. Going forward that's the only cipher suite you should use. – Ramhound Aug 04 '17 at 12:15
  • @harrymc No, the `x-forwarded-proto` header has the value `https`, indicating that the origin request is `HTTPS`. However, when the web server sees the request, the requesting url will have the `HTTP` protocol. – Dan Atkinson Aug 04 '17 at 12:29
  • @Ramhound That is not correct. Windows Server 2012 does **not** support HTTP/2. It's only available with Windows 10 and Server 2016. You can see the list of supported Windows platforms for HTTP/2 [here](https://en.wikipedia.org/wiki/HTTP/2#Software_and_services_supporting_HTTP.2F2) – Dan Atkinson Aug 04 '17 at 12:31
  • You are reiterating that you will issue an `http:` URL with `X-Forwarded-Protocol: https`. I repeat that this is doubtful and only a test will tell. – harrymc Aug 04 '17 at 12:42
  • @harrymc If my test fails, that doesn't mean that there is conclusively no way of doing it, only that it doesn't support it out of the box.There may be another way of doing it, which my test would not show, hence why I'm here, asking this question! – Dan Atkinson Aug 04 '17 at 12:45
  • 1
    And if it succeeds? I must say that `X-Forwarded-Protocol` seems like a security hole, basically just a "trust me" flag. You might need to turn off some safeguards ([example](https://social.msdn.microsoft.com/Forums/azure/en-US/c3861a4e-67e7-4f59-b8f9-e27e9534fa01/azure-web-app-overriding-xforwardedfor-header-from-reverse-proxy-server?forum=windowsazurewebsitespreview)). – harrymc Aug 04 '17 at 14:20
  • @harrymc Forgive me if I'm wrong but your example relates to the MitM attack used with `x-forwarded-for` and doesn't have anything to do with `x-forwarded-proto`. I'm also not sure what such an attack vector would be for this? Please could you enlighten me? – Dan Atkinson Aug 04 '17 at 14:30
  • That was just an example. I don't have any experience with it and there is absolutely no documentation. You are breaking new grounds there. – harrymc Aug 04 '17 at 15:05
  • **Err... Wasn't expecting to see this message. Never mind. No need to join me in chat!** Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/63333/discussion-between-dan-atkinson-and-harrymc). – Dan Atkinson Aug 04 '17 at 15:14

1 Answers1

3

As pointed out in the blog post you linked (and confirmed when it turned into official docs here), IIS will only use the HTTP/2 protocol when a TLS connection has been established to the IIS server.

As implemented today in IIS 10, HTTP/2 is identified by using ALPN during the TLS handshake. If there's no ALPN nor TLS, there will be no HTTP/2. See this BUILD talk from 2015 starting at about 5'06" and keep in mind that IIS does not implement the HTTP/1.1 upgrade mechanism (as stated at 8'46" in the video).

In your scenario, it's almost certainly the case that the load balancer will establish clear TCP connections and send HTTP/1.1 requests to the back-end servers. By the time IIS can even see the x-forwarded-proto header, the connection has already been established and the HTTP/1.1 protocol has already been identified.

Now, it's possible that your load balancer can support HTTP/2 itself, so your end users' browsers will be able to multiplex requests and responses with the load balancer while it translates those to HTTP/1.1 requests and responses to your back-end servers.

It's also possible that your load balancer could establish TLS connections to the back-end servers and use HTTP/2, but this would mostly defeat the point of SSL offloading.

Mike Schenk
  • 146
  • 3