[jira] [Created] (HTTPCLIENT-1669) Integrated NTLM Windows Authentication doesn't work over HTTPS
Reinhold Früsmer created HTTPCLIENT-1669: Summary: Integrated NTLM Windows Authentication doesn't work over HTTPS Key: HTTPCLIENT-1669 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1669 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5 Environment: Win7 / Squid Proxy 2.7.STABLE8 Reporter: Reinhold Früsmer Priority: Blocker Hi, integrated NTLM Windows Authentication is working properly over HTTP connections, but not over HTTPS. The wireshark sequence is as follows: 323 10.584292000192.168.85.96 192.168.85.236 HTTP182 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 325 10.584539000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 336 10.645235000192.168.85.96 192.168.85.236 HTTP266 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 338 10.658532000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) Connection is closed then. With a modified version of MainClientExec#createTunnelToTarget at line 457 it works when adding the following header to the connect request connect.addHeader(Proxy-Connection, Keep-Alive); I am not very familiar with the HttpClient code, maybe there's a cleaner solution for this or it maybreak other things I am not aware of, but it works in our test cases. The Wireshark sequence then becomes: 174 4.457754000 192.168.85.96 192.168.85.236 HTTP212 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 176 4.458258000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 198 4.513611000 192.168.85.96 192.168.85.236 HTTP296 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 200 4.519928000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required , NTLMSSP_CHALLENGE (text/html) 202 4.545414000 192.168.85.96 192.168.85.236 HTTP504 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_AUTH, User: TEAMTRAINING\FruesmerRe 224 4.606172000 192.168.85.236 192.168.85.96 HTTP93 HTTP/1.0 200 Connection established And continuing happily -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1246) Patch for JmxEnabledHttpClient
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642940#comment-14642940 ] Oleg Kalnichevski commented on HTTPCLIENT-1246: --- The project you are referring to looks inactive and I have no control over the repository and cannot merge the PR in question. I am also no longer sure if HttpClient, as a project, should even ship a JMX module. I am going to close this issue as WONTFIX. Oleg Patch for JmxEnabledHttpClient -- Key: HTTPCLIENT-1246 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1246 Project: HttpComponents HttpClient Issue Type: New Feature Components: HttpClient Reporter: Mike Boyers Fix For: Future Attachments: jmx-enabled-httpclient.patch Oleg asked me to submit this patch via JIRA. This is an initial version of code to enable JMX for requests/timeouts/etc. I've uploaded the patch as an attachment. Here are my comments about what I have and have not done. This is from an email earlier in the week: What I have at this point is a version of a JmxEnabledHttpClient that implements the HttpClient interface. You can instantiate a JmxEnabledHttpClient given an HttpClient. I have decoupled it from the work I had done previously (Spring-dependent), so it works without any additional dependencies. I probably just need a couple more hours to clean this area up. I did work on it a bit yesterday. But I have not made progress in integrating the stats more closely with the HttpClient codebase. So it doesn't currently have visibility into some of the underlying behavior of HttpClient and some of the mechanisms for retaining and managing statistics could probably be done more cheaply if they were integrated more closely. This is the area I just don't think I'm going to be able to find the time to do, sadly. So what I'm thinking at this point: I'll hand off what I've done (which is functional) and you guys can decide on whether or not to use it as the basis for anything going forward. Even if you decide not to ultimately check it in with the rest of the HttpClient code, it could still be useful to you in the short-term, as it could easily be turned into its own jar and used with the existing HttpClient. I'm pretty sure it records everything we talked about previous except the current pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1246) Patch for JmxEnabledHttpClient
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski resolved HTTPCLIENT-1246. --- Resolution: Won't Fix Fix Version/s: (was: Future) Patch for JmxEnabledHttpClient -- Key: HTTPCLIENT-1246 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1246 Project: HttpComponents HttpClient Issue Type: New Feature Components: HttpClient Reporter: Mike Boyers Attachments: jmx-enabled-httpclient.patch Oleg asked me to submit this patch via JIRA. This is an initial version of code to enable JMX for requests/timeouts/etc. I've uploaded the patch as an attachment. Here are my comments about what I have and have not done. This is from an email earlier in the week: What I have at this point is a version of a JmxEnabledHttpClient that implements the HttpClient interface. You can instantiate a JmxEnabledHttpClient given an HttpClient. I have decoupled it from the work I had done previously (Spring-dependent), so it works without any additional dependencies. I probably just need a couple more hours to clean this area up. I did work on it a bit yesterday. But I have not made progress in integrating the stats more closely with the HttpClient codebase. So it doesn't currently have visibility into some of the underlying behavior of HttpClient and some of the mechanisms for retaining and managing statistics could probably be done more cheaply if they were integrated more closely. This is the area I just don't think I'm going to be able to find the time to do, sadly. So what I'm thinking at this point: I'll hand off what I've done (which is functional) and you guys can decide on whether or not to use it as the basis for anything going forward. Even if you decide not to ultimately check it in with the rest of the HttpClient code, it could still be useful to you in the short-term, as it could easily be turned into its own jar and used with the existing HttpClient. I'm pretty sure it records everything we talked about previous except the current pool size. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1669) Integrated NTLM Windows Authentication doesn't work over HTTPS
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642953#comment-14642953 ] Michael Osipov edited comment on HTTPCLIENT-1669 at 7/27/15 4:34 PM: - This seems to be a problem with squid and not httpclient. It either does not persist the connection or downgrades to HTTP 1.0. Therefore, httpclient dies in the loop. Talk to your local admin. was (Author: michael-o): This seems to be a problem wird squid and not httpclient. IT Esther does not persist the connection or downgrades to HTTP 1.0. Therefore, httpclient dies in the loop. Talk to your local Administration. Integrated NTLM Windows Authentication doesn't work over HTTPS -- Key: HTTPCLIENT-1669 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1669 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5 Environment: Win7 / Squid Proxy 2.7.STABLE8 Reporter: Reinhold Früsmer Priority: Blocker Hi, integrated NTLM Windows Authentication is working properly over HTTP connections, but not over HTTPS. The wireshark sequence is as follows: 323 10.584292000192.168.85.96 192.168.85.236 HTTP182 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 325 10.584539000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 336 10.645235000192.168.85.96 192.168.85.236 HTTP266 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 338 10.658532000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) Connection is closed then. With a modified version of MainClientExec#createTunnelToTarget at line 457 it works when adding the following header to the connect request connect.addHeader(Proxy-Connection, Keep-Alive); I am not very familiar with the HttpClient code, maybe there's a cleaner solution for this or it maybreak other things I am not aware of, but it works in our test cases. The Wireshark sequence then becomes: 174 4.457754000 192.168.85.96 192.168.85.236 HTTP212 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 176 4.458258000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 198 4.513611000 192.168.85.96 192.168.85.236 HTTP296 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 200 4.519928000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required , NTLMSSP_CHALLENGE (text/html) 202 4.545414000 192.168.85.96 192.168.85.236 HTTP504 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_AUTH, User: TEAMTRAINING\FruesmerRe 224 4.606172000 192.168.85.236 192.168.85.96 HTTP93 HTTP/1.0 200 Connection established And continuing happily -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1669) Integrated NTLM Windows Authentication doesn't work over HTTPS
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642953#comment-14642953 ] Michael Osipov commented on HTTPCLIENT-1669: This seems to be a problem wird squid and not httpclient. IT Esther does not persist the connection or downgrades to HTTP 1.0. Therefore, httpclient dies in the loop. Talk to your local Administration. Integrated NTLM Windows Authentication doesn't work over HTTPS -- Key: HTTPCLIENT-1669 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1669 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5 Environment: Win7 / Squid Proxy 2.7.STABLE8 Reporter: Reinhold Früsmer Priority: Blocker Hi, integrated NTLM Windows Authentication is working properly over HTTP connections, but not over HTTPS. The wireshark sequence is as follows: 323 10.584292000192.168.85.96 192.168.85.236 HTTP182 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 325 10.584539000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 336 10.645235000192.168.85.96 192.168.85.236 HTTP266 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 338 10.658532000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) Connection is closed then. With a modified version of MainClientExec#createTunnelToTarget at line 457 it works when adding the following header to the connect request connect.addHeader(Proxy-Connection, Keep-Alive); I am not very familiar with the HttpClient code, maybe there's a cleaner solution for this or it maybreak other things I am not aware of, but it works in our test cases. The Wireshark sequence then becomes: 174 4.457754000 192.168.85.96 192.168.85.236 HTTP212 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 176 4.458258000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 198 4.513611000 192.168.85.96 192.168.85.236 HTTP296 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 200 4.519928000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required , NTLMSSP_CHALLENGE (text/html) 202 4.545414000 192.168.85.96 192.168.85.236 HTTP504 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_AUTH, User: TEAMTRAINING\FruesmerRe 224 4.606172000 192.168.85.236 192.168.85.96 HTTP93 HTTP/1.0 200 Connection established And continuing happily -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1669) Integrated NTLM Windows Authentication doesn't work over HTTPS
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643378#comment-14643378 ] Reinhold Früsmer commented on HTTPCLIENT-1669: -- Squid 2.7 is not HTTP 1.0 compliant. I'm going to upgrade the instance to version 3.3 and check the results - just wondering because modern browsers handle this without problems in the way I described before, simply by adding the initial keep-alive header. Integrated NTLM Windows Authentication doesn't work over HTTPS -- Key: HTTPCLIENT-1669 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1669 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5 Environment: Win7 / Squid Proxy 2.7.STABLE8 Reporter: Reinhold Früsmer Priority: Blocker Hi, integrated NTLM Windows Authentication is working properly over HTTP connections, but not over HTTPS. The wireshark sequence is as follows: 323 10.584292000192.168.85.96 192.168.85.236 HTTP182 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 325 10.584539000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 336 10.645235000192.168.85.96 192.168.85.236 HTTP266 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 338 10.658532000192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) Connection is closed then. With a modified version of MainClientExec#createTunnelToTarget at line 457 it works when adding the following header to the connect request connect.addHeader(Proxy-Connection, Keep-Alive); I am not very familiar with the HttpClient code, maybe there's a cleaner solution for this or it maybreak other things I am not aware of, but it works in our test cases. The Wireshark sequence then becomes: 174 4.457754000 192.168.85.96 192.168.85.236 HTTP212 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 176 4.458258000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required (text/html) 198 4.513611000 192.168.85.96 192.168.85.236 HTTP296 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_NEGOTIATE 200 4.519928000 192.168.85.236 192.168.85.96 HTTP1436 HTTP/1.0 407 Proxy Authentication Required , NTLMSSP_CHALLENGE (text/html) 202 4.545414000 192.168.85.96 192.168.85.236 HTTP504 CONNECT marjory-ttkf.ttsdev.de:443 HTTP/1.1 , NTLMSSP_AUTH, User: TEAMTRAINING\FruesmerRe 224 4.606172000 192.168.85.236 192.168.85.96 HTTP93 HTTP/1.0 200 Connection established And continuing happily -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
