Note: For information about configuring the F5 BIG-IP to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 or Windows Server 2016 to perform IP-HTTPS preauthentication natively, click here.
Introduction
IP-HTTPS is an IPv6 transition technology used by DirectAccess. It enables DirectAccess clients to communicate with the DirectAccess server using IPv6 over the public IPv4 Internet by encapsulating IPv6 packets in HTTP and authenticating (and optionally encrypting) them using SSL/TLS. IP-HTTPS is supported for all DirectAccess network deployment configurations and is enabled by default.
When a DirectAccess client connection is established, only the server is authenticated by the client. The client is not authenticated by the server. The DirectAccess server will thus accept IP-HTTPS connections from any client, valid or not.
IP-HTTPS Connection
Once a client has established an IP-HTTPS transition tunnel, it will go through the standard IPv6 neighbor discovery process to identify routers and obtain an IPv6 prefix for the link. It will use this information to build its own IPv6 address, which it uses to communicate with the DirectAccess server and begin establishing IPsec security associations for DirectAccess.
ICMP and IPsec
By design, ICMP is exempt from DirectAccess IPsec policy processing. If an unauthorized client were to establish an IP-HTTPS transition tunnel, even without authentication (Kerberos Proxy or certificate) it would be able to ping the DirectAccess server tunnel endpoint IPv6 addresses, the DNS64 IPv6 address, and any intranet hosts (assuming host firewalls allow this access).
Security Risk
This default posture opens up the DirectAccess server and intranet to unauthorized remote network reconnaissance and some IPv6-related Denial-of-Service (DoS) attacks. These were demonstrated by security researcher Ali Hardudi at the recent Troopers16 security conference. You can view his very informative session here.
Note: DirectAccess IPsec data connections are unaffected and are completely secure. Data is never exposed at any time with the default configuration.
IP-HTTPS Preauthentication
To mitigate these risks, it is recommended that an Application Delivery Controller (ADC) such as the Citrix NetScaler be configured to preauthenticate DirectAccess clients prior to establishing the IP-HTTPS transition tunnel.
Note: To configure the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.
Citrix NetScaler Configuration
To perform DirectAccess preauthentication, it will be necessary to configure the Citrix NetScaler to perform SSL termination for IP-HTTPS. The virtual server on the NetScaler must use the SSL protocol. In addition, a CA certificate must be bound to the virtual server. Also, Client Authentication must be enabled under SSL Parameters and be set to Mandatory.
Once configured, the NetScaler appliance will ensure that the DirectAccess IPsec certificate is present on the client before establishing the IP-HTTPS IPv6 transition tunnel. This will prevent unauthorized connections to the DirectAccess server.
Important Considerations
Performing IP-HTTPS preauthentication on the Citrix NetScaler is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the NetScaler appliance breaks OTP authentication.
Summary
The default security posture of DirectAccess leaves the internal network open to unauthorized network reconnaissance, and exposes the DirectAccess infrastructure to potential denial-of-service (DoS) attacks. To mitigate these security risks, implement the Citrix NetScaler ADC and enable client certificate authentication.
References
Security Assessment of Microsoft DirectAccess [Overview] – https://www.insinuator.net/2016/04/security-assessment-of-microsoft-directaccess/
Security Assessment of Microsoft DirectAccess [Full Document] – https://www.ernw.de/newsfeed/newsletter-53-may-2016-security-assessment-of-microsoft-directaccess/index.html
Security Assessment of Microsoft DirectAccess Troopers16 Presentation by Ali Hardudi [Video] – https://www.youtube.com/watch?v=wW1x7ow0V9w
Chiron IPv6 Penetration Testing Framework – https://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/
IP-HTTPS specification on MSDN – https://msdn.microsoft.com/en-us/library/dd358571.aspx
Configure F5 BIG-IP to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/
Configure Windows Server 2012 R2 and Windows Server 2016 to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/
Engineering IT
/ May 10, 2016This is quite concerning, that an unauthenticated person can build a topology map of your internal network.
Won’t terminating the SSL on the Netscaler break OTP authentication, where its a requirement that SSL terminates on the DirectAccess servers?
Would a mitigation be to remove PING from been IPSEC exempt?
Has Microsoft been notified of this? It seems like a security breach to me.
Is it possible to do the same pre-authentication using F5 load balancers?
Sorry for so many questions! Keep up the good work.
Richard M. Hicks
/ May 11, 2016To be honest, it isn’t as bad as it seems. It really is trivial to filter ICMP traffic, so that isn’t a huge concern. However, so very few people do it that it does present a potential risk. The biggest issue has to do with IPv6 DoS attacks. The important thing to realize is that it is not possible to compromise the IPsec connection, so there’s no risk of data exposure at all.
You are correct, terminating SSL on an ADC does fundamentally break OTP. Thanks for reminding me of that. I’ve updated the post to reflect that detail. In addition, it is possible to do this with the F5, it’s just not as easy. I’ll be documenting that in the near future, time permitting.
Christoph
/ May 24, 2016Is it possible to do preauthentication for IP-HTTPS with this Microsoft solution https://technet.microsoft.com/en-us/library/ee731901%28WS.10%29.aspx
instead of a Citrix NetScaler or F5 BIG-IP?
Have you tried this solution?
Richard M. Hicks
/ May 24, 2016I believe this still works with DirectAccess in Windows Server 2012 R2, but it isn’t recommended because it disables support for null encryption for IP-HTTPS connections.
Engineering IT
/ May 24, 2016It might not be an option for people using OTP, as that disables null encryption and the SSL must terminate on the DirectAccess servers and not a load balancer in between.
Richard M. Hicks
/ May 28, 2016You’re absolutely right. It’s noted in the “Important Considerations” section in this post. 🙂
Koen
/ June 20, 2016Richard,
I’m trying to promote the use of the ADC for pre auth and NLS, but getting lost in the licensing. If I read the spec sheet correct the VPX Standard license does not support authentication, does this imply we need Enterprise to be able to support DA as you describe it here?
Richard M. Hicks
/ June 20, 2016I’m not that familiar with Citrix licensing at all, but if the standard license doesn’t allow certificate authentication then yes, a different license will be required.
Michael
/ July 12, 2016Can you advise which version of Netscaler software you are using? I have attempted to implement this on 10.5 (61.11), and have working Windows 7 clients, but Windows 10 clients report errors indicating the traffic is being modified by the load balancer. When the Load balancer is put into SSL_Bridge mode, both clients work but I lose the opportunity to pre-authenticate clients & perform the SSL offloading I had hoped to achieve. Curious to know if version 11 fixes this before I embark on the upgrade.
Richard M. Hicks
/ July 13, 2016As it stands today, this will only work on the VPX platform. There is a bug on the MPX platform that results in the issue you are having. I’ve been told that it will be fixed soon. Once I have that information I will post an article on it shortly thereafter. Stay tuned!
Jims
/ July 27, 2016Hi Richard, Do you have any Bug ID or Case ID @Citrix for this particular issue on the MPX appliance? I confirm this is not working again on MPX 11.1 build 47.14 the same build is working on VPX of DA SSL (not SSL_Bridge).
Richard M. Hicks
/ July 28, 2016Not that I can share, sorry. And yes, the bug only affects the MPX platform. No issues at all with any version of VPX so far. I will be making an announcement on this web site as soon as a validated working build for MPX is available though. Stay tuned!
Pekka
/ November 2, 2016Hi all, I am using VPX version 11.0 64.34. I configured client preauthentication and it works fine with Windows 7 clients. However, I am unable to get it working with Windows 10 clients. I run in to this:
https://directaccessguide.com/2014/06/01/getting-ip-https-error-code-0x80090326/
Do you have any idea what I’m doing wrong?
Richard M. Hicks
/ November 2, 2016You have to include null cipher suites for Windows 10 clients to work. For anyone else reading this, please know there’s a bug in the NetScaler MPX and SDX platforms that will produce this same result even with null cipher suites enabled. This is due to a bug in the NetScaler software. Citrix is working to resolve the issue as we speak. Once they have resolved the issue I will post information here.
Pekka
/ November 7, 2016I found the solution to my problem. TLS1.2 Certificate request specifies which signature algorithms it accepts with “supported_signature_algorithms”. The server certificate bound to LB vsrv was signed with RSA SHA256 and therefore NetScaler told the client it wants a RSA SHA256 certificate. My client certificates are signed with RSA SHA1 so the windows replied with empty certificate and NetScaler terminated the handshake. TLS1 and TLS1.1 don’t specify the supported signature algorithms, so I disabled TLS1.2 and it works perfectly.
Better solution of course is to upgrade the certificate authority to support and issue certificates signed with SHA256.
Richard M. Hicks
/ November 7, 2016Most interesting. Thanks for the update! I’ll definitely put that one in the memory banks. 🙂
itismeap
/ September 1, 2016Thanks for this article. In a earlier comment you state ‘It really is trivial to filter ICMP traffic, so that isn’t a huge concern’. Can you elaborate on this, do you mean to say we should simply block IMCP IPv6 on the Direct Access servers via Windows Firewall?
Richard M. Hicks
/ September 3, 2016Correct. To prevent internal network reconnaissance from an unauthorized client, blocking ICMP echo requests anywhere will mitigate this particular risk. It can be done on the DirectAccess server itself using the Windows firewall, or if a firewall exists between the DirectAccess server and the LAN, it could be done there. However, keep in mind that this does not mitigate the risk of DoS attacks against the DirectAccess server or connected clients.