SNI support for ADFS

JohnM · January 21, 2018, 9:03pm

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 · January 21, 2018, 9:43pm

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

JohnM · January 22, 2018, 5:47pm

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 · January 22, 2018, 11:15pm

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.

brendanmain · January 22, 2018, 11:39pm

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

JohnM · January 23, 2018, 4:29am

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

JohnM · January 23, 2018, 4:30am

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 · January 23, 2018, 9:27pm

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 · January 26, 2018, 9:32pm

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 · January 27, 2018, 7:10am

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 · January 30, 2018, 2:51am

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 · January 30, 2018, 4:57pm

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 · January 30, 2018, 8:42pm

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 · January 31, 2018, 11:40am

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

daniil_michine · January 31, 2018, 10:48pm

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 · February 1, 2018, 8:31am

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