Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8270290

NTLM authentication fails if HEAD request is used

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b18
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        When HEAD request to HTTPS resource is used with a proxy server that requires NTLM, authentication fails when server returns large (8kb+) body along with NTLMSSP_CHALLENGE response.

        Failure example:

        java.util.NoSuchElementException
        at java.base/java.util.StringTokenizer.nextToken(StringTokenizer.java:347)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.doTunneling0(HttpURLConnection.java:2191)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:2136)
        at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:181)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
        at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
        at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:224)

        Problem happens because HttpURLConnection#reset() is called on NTLM stage 2 to consume (and discard) NTLMSSP_CHALLENGE response body. But reset() does not discard the body when the request method (of the initial client request) is HEAD. If HTTPS resource is requested (in this case CONNECT request is sent to proxy server to establish TLS tunnel) and NTLMSSP_CHALLENGE response size is larger than a buffer in BufferedInputStream, then status code of the following response (to NTLMSSP_AUTH request) cannot be read (because there is stale data in socket) and authentication fails.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                akasko Alex Kasko
                Reporter:
                akasko Alex Kasko
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: