SNI support for ADFS

JohnM 2018-01-21 21:03:23 UTC #1

MobileIron Sentry should now be able to support SNI, but I am still having issues with Docs@Work and Web@Work to establish a connection with the use of ADFS Web Application Proxy (Windows Server 2012 R2). Since I can leverage only one external IP address for Core and all the Sentries, I have to publish the URL rules on the ADFS proxy. When publishing these rules everything seems to work fine except the connections to the backend servers for Web@Work and Docs@Work.
I have tested two different Sentrys MICS portals on the ADFS proxy without any issues - the forward is always correct.
For Web@Work or Docs@Work, I can see the correct SNI value while doing a network trace.
0.0.0.0:443 is added correctly on the ADFS - and also the user agents.
Any ideas guys?

Thanks!

daniil_michine 2018-01-21 21:43:40 UTC #2

Does the TLS handshake fail or is it successful?
You might want to post a screenshot of your trace.

JohnM 2018-01-22 17:47:01 UTC #3

The handshake seems ok - let me know which details you need.
Not sure if the Encrypted Alert seems right initiated by the client though?!

192.168.0.204 is my ADFS Web Application Proxy server

BTW: If I connect my devices internally without the use of the ADFS Proxy, Web@Work and Docs@Work connect.

daniil_michine 2018-01-22 23:15:51 UTC #4

TLS handshake looks fine, you will generally get an Encrypted Alert at the end of a TLS session its a notification that the TLS session is ending.

Looks like an application issue, you can try decrypting the trace to identify the problem.

http://joji.me/en-us/blog/walkthrough-decrypt-ssl-tls-traffic-https-and-http2-in-wireshark

brendanmain 2018-01-22 23:39:01 UTC #5

Hey John, have you had a look at this MobileIron community thread https://community.mobileiron.com/thread/2990

JohnM 2018-01-23 04:29:12 UTC #6

Thanks, I will take a look at it. Weird is, that Apps@Work is also not working - but Core MIFS and MICS is…

JohnM 2018-01-23 04:30:13 UTC #7

Hey Brendan, yes I am familiar with your thread and I followed it except for the Kerberos part, since I am not using it.

daniil_michine 2018-01-23 21:27:53 UTC #8

Are you offloading TLS termination to your ADFS proxy?

Web@Work/Docs@Work may use client certificate for auth, and looking at the Wireshark trace above there is no certificate request from the server.

If you capture a network trace internally without going through the ADFS proxy does the TLS handshake look different?

JohnM 2018-01-26 21:32:01 UTC #9

you are absolutely right, Web@Work and Docs@Work use a client cert for the AppTunnel and there is no sign within the trace.
I have to do a trace of the internal traffic, currently I am on vacation!
Good question about the offloading TLS termination - could you give a hint how to find that out?

JohnM 2018-01-27 07:10:59 UTC #10

The only thing I overlooked is check if the HTTP host header is the same:

Where do I find the HTTP hoster header in the traces? I was not able to locate it.

daniil_michine 2018-01-30 02:51:31 UTC #11

SNI is an extension of TLS protocol.
It is generally used to host multiple TLS certificates from the same server and port.

As part of a TLS handshake the client supplies a server name in the Client Hello.
Based on this Client Name the server knows which certificate and web service is being requested.

HTTP host headers do not play any part of this, as once the HTTP header is presented you already have a TLS connection established to the server.

Also you won’t see host headers in your trace since HTTP data is encrypted, unless of course you decrypt the trace.

JohnM 2018-01-30 16:57:47 UTC #12

Ok thanks got it.
You mentioned the SSL termination on the ADFS that might cause the problem - what is the alternative?
Every MobileIron service depending on a user certificate fails.

Will try to decrypt the Wireshark traffic tomorrow and keep you up to date on my findings.

So far thanks to you all.

daniil_michine 2018-01-30 20:42:12 UTC #13

What I suspect is happening here is that you have 2 TLS tunnels.

First between the client device and the proxy
Second between the proxy and the sentry.

Sentry is likely to be challenging for client certificate, however this challenge is in the second tunnel and is not passed through to the device.

I recommend you do a traffic capture on the sentry and see if the client certificate is being requested by the sentry.

If there is a client certificate request you will need to challenge for client certificate at the proxy and pass it through to the sentry.

JohnM 2018-01-31 11:40:57 UTC #14

Good point, sounds logical! Thanks.
I will look into that. And how would I challenge for the client certificate on the proxy?

daniil_michine 2018-01-31 22:48:53 UTC #15

Not sure of the capability of the proxy that you are using

With something like a Citrix Netscaler you would pass the client cert as an HTTP header https://docs.citrix.com/ko-kr/netscaler/11-1/aaa-tm/ns-aaa-client-certs-tsk/ns-aaa-client-cert-passthrough-tsk.html

JohnM 2018-02-01 08:31:44 UTC #16

Currently I am using the ADFS Web Application Proxy with Windows Server 2012 R2.