Knowledge Search


[Junos Content Encore - JCE (formerly MFC)] and NTLM related issues

  [KB26011] Show Article Properties

This article provides information about certain issues that are related to NTLM and the JCE. One of them is a security vulnerability and another is related to a functionality limitation.



Bypassing the cache logic. When tunneling, the JCE still behaves as a HTTP proxy; that is, it terminates the TCP connection with the client, makes a new TCP connection to the origin, and proxies requests and responses between the two connections. The requests and the responses on tunneled connections bypass the caching logic; so they are not considered for caching.

Origin connection pooling:

When enabled, the JCE will take requests from many different clients, which are bound for a single origin, and send these requests to the origin on a single TCP connection. This reduces the origin server load by minimizing the number of connections that it is required to service.


Security Vulnerability

Websites that use NTLM authentication will not work properly in JCE versions that are prior to 11.B.4. Between versions 11.B.4 and 11.B.7, if there is a layer-7 load balancer that performs connection pooling, some users can gain access to origins, to which another user has authenticated; effectively using the other user’s credentials.

This was resolved in the 11.B.7 release by bypassing the origin connection pooling for all NTLM-authenticated connections. This security vulnerability exists, outside of the MFC, with layer-7 load balancers that use connection pooling to the origin. It can be addressed by configuring the layer-7 load balancer to do any one of the following tasks:

  • Disable connection pooling to the origin altogether (in this case, the origin is the MFC).

  • Disable connection pooling for any NTLM-authenticated connections.

  • Restrict connection pooling to connections between an individual client and an individual origin server. Connections from multiple clients will not be pooled into a single origin connection.

Functionality limitation

Prior to the 11.B.4 release, NTLM functionality would not work properly. NTLM authentication is connection-based; which means that the client opens a connection with the origin server, authenticates, and then keeps that connection open. All subsequent requests on that connection are considered authenticated by the origin server; so the client keeps that connection open, as long as it requires access to the content requiring authentication. Newer versions of IIS do not allow more than one request on a single NTLM connection due to a potential security issue with proxies.

If either the client or the origin server closes the connection, the client must open a new connection with the origin and re-authenticate. Prior to 11.B.4, TLM-authenticated requests that transverse the MFC may be interrupted, as the MFC may close the origin connection before the client or the origin closes the connection. This would require the client to unexpectedly re-authenticate.

This issue has been addressed in the 11.B.4 release of the JCE, by tunneling all NTLM authentication traffic to the origin. Additionally, in the 11.B.7 release, JCE disables connection pooling on all connections that are tunneled to the origin, based on NTLM. This same failure mechanism will occur, if there is a layer-7 load balancer in use and the load balancer closes the connection to the origin (in this case, the JCE), before the client or the origin closes the connection.
Related Links: