[jira] [Reopened] (HTTPCLIENT-1383) NTLM authentication can enter in infinite loop
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ricardo Pereira reopened HTTPCLIENT-1383: - Sorry to bother you again with this. It's still possible to get the authentication to enter in infinite loop (happens in both trunk and branch 4.2.x). NTLM authentication can enter in infinite loop -- Key: HTTPCLIENT-1383 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1383 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpAuth Affects Versions: Snapshot Reporter: Ricardo Pereira Fix For: 4.2.6, 4.3 Beta3 Attachments: ClientNtlmProxyAuthentication.java, HTTPCLIENT-1383_patch_tests, wire.log If the NTLM proxy sends, always, a challenge message the authentication enters in infinite loop. This happened with an user account that got suspended because of too many failed authentication attempts, after that the server started to send, always, the (same) challenge message causing an infinite loop with the HttpClient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1383) NTLM authentication can enter in infinite loop
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ricardo Pereira updated HTTPCLIENT-1383: Attachment: HTTPCLIENT-1383_patch_tests_non_unicode Attached a patch (for trunk) with some changes to the NTLM tests: - Adds a new test which enters in infinite loop (uses a non unicode NTLM challenge message); - Minor changes to use the same response handler (that sends only challenge messages). NTLM authentication can enter in infinite loop -- Key: HTTPCLIENT-1383 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1383 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpAuth Affects Versions: Snapshot Reporter: Ricardo Pereira Fix For: 4.2.6, 4.3 Beta3 Attachments: ClientNtlmProxyAuthentication.java, HTTPCLIENT-1383_patch_tests, HTTPCLIENT-1383_patch_tests_non_unicode, wire.log If the NTLM proxy sends, always, a challenge message the authentication enters in infinite loop. This happened with an user account that got suspended because of too many failed authentication attempts, after that the server started to send, always, the (same) challenge message causing an infinite loop with the HttpClient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1383) NTLM authentication can enter in infinite loop
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski resolved HTTPCLIENT-1383. --- Resolution: Fixed To the contrary I am very happy you are helping us find ways to break NTLM auth. The patch and a fix committed to SVN trunk and 4.2.x. Please review / re-test. Oleg NTLM authentication can enter in infinite loop -- Key: HTTPCLIENT-1383 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1383 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpAuth Affects Versions: Snapshot Reporter: Ricardo Pereira Fix For: 4.2.6, 4.3 Beta3 Attachments: ClientNtlmProxyAuthentication.java, HTTPCLIENT-1383_patch_tests, HTTPCLIENT-1383_patch_tests_non_unicode, wire.log If the NTLM proxy sends, always, a challenge message the authentication enters in infinite loop. This happened with an user account that got suspended because of too many failed authentication attempts, after that the server started to send, always, the (same) challenge message causing an infinite loop with the HttpClient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: svn commit: r1500401
On Sun, 2013-07-07 at 20:18 +0100, sebb wrote:
On 7 July 2013 11:20, ol...@apache.org wrote:
Author: olegk
Date: Sun Jul 7 10:20:33 2013
New Revision: 1500401
URL: http://svn.apache.org/r1500401
Log:
Follow up to HTTPCLIENT-1381: fixes another NPE
Contributed by Ricardo Pereira thc202 at gmail.com
Modified:
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
httpcomponents/httpclient/trunk/httpclient/src/test/java/org/apache/http/impl/client/integration/TestClientAuthenticationFakeNTLM.java
Modified:
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
URL:
http://svn.apache.org/viewvc/httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java?rev=1500401r1=1500400r2=1500401view=diff
==
---
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
(original)
+++
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
Sun Jul 7 10:20:33 2013
@@ -624,7 +624,7 @@ final class NTLMEngineImpl implements NT
final MD4 md4 = new MD4();
md4.update(unicodePassword);
return md4.getOutput();
-} catch (java.io.UnsupportedEncodingException e) {
+} catch (UnsupportedEncodingException e) {
throw new NTLMEngineException(Unicode not supported: +
e.getMessage(), e);
}
}
@@ -641,9 +641,11 @@ final class NTLMEngineImpl implements NT
final HMACMD5 hmacMD5 = new HMACMD5(ntlmHash);
// Upper case username, upper case domain!
hmacMD5.update(user.toUpperCase(Locale.US).getBytes(UnicodeLittleUnmarked));
-
hmacMD5.update(domain.toUpperCase(Locale.US).getBytes(UnicodeLittleUnmarked));
+if (domain != null) {
+
hmacMD5.update(domain.toUpperCase(Locale.US).getBytes(UnicodeLittleUnmarked));
Note that getBytes(String) is also Locale-sensitive; should probably
use Locale.ENGLISH.
(Locale.ROOT is 1.6+)
Sebastian,
I am not sure I follow you. String#getBytes only takes charset encoding
as a parameter (either as string prior to 1.6 or Charset in 1.6+), not a
locale. In any way just go ahead and commit the fix if you see a problem
with this code.
Cheers
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: svn commit: r1500401
On 8 July 2013 10:34, Oleg Kalnichevski ol...@apache.org wrote:
On Sun, 2013-07-07 at 20:18 +0100, sebb wrote:
On 7 July 2013 11:20, ol...@apache.org wrote:
Author: olegk
Date: Sun Jul 7 10:20:33 2013
New Revision: 1500401
URL: http://svn.apache.org/r1500401
Log:
Follow up to HTTPCLIENT-1381: fixes another NPE
Contributed by Ricardo Pereira thc202 at gmail.com
Modified:
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
httpcomponents/httpclient/trunk/httpclient/src/test/java/org/apache/http/impl/client/integration/TestClientAuthenticationFakeNTLM.java
Modified:
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
URL:
http://svn.apache.org/viewvc/httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java?rev=1500401r1=1500400r2=1500401view=diff
==
---
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
(original)
+++
httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/impl/auth/NTLMEngineImpl.java
Sun Jul 7 10:20:33 2013
@@ -624,7 +624,7 @@ final class NTLMEngineImpl implements NT
final MD4 md4 = new MD4();
md4.update(unicodePassword);
return md4.getOutput();
-} catch (java.io.UnsupportedEncodingException e) {
+} catch (UnsupportedEncodingException e) {
throw new NTLMEngineException(Unicode not supported: +
e.getMessage(), e);
}
}
@@ -641,9 +641,11 @@ final class NTLMEngineImpl implements NT
final HMACMD5 hmacMD5 = new HMACMD5(ntlmHash);
// Upper case username, upper case domain!
hmacMD5.update(user.toUpperCase(Locale.US).getBytes(UnicodeLittleUnmarked));
-
hmacMD5.update(domain.toUpperCase(Locale.US).getBytes(UnicodeLittleUnmarked));
+if (domain != null) {
+
hmacMD5.update(domain.toUpperCase(Locale.US).getBytes(UnicodeLittleUnmarked));
Note that getBytes(String) is also Locale-sensitive; should probably
use Locale.ENGLISH.
(Locale.ROOT is 1.6+)
Sebastian,
I am not sure I follow you. String#getBytes only takes charset encoding
as a parameter (either as string prior to 1.6 or Charset in 1.6+), not a
locale. In any way just go ahead and commit the fix if you see a problem
with this code.
Sorry, brain-fart!
The code is fine as is - though it might be worth considering using a
constant for the charset.
This could then be documented.
Cheers
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
UnicodeLittleUnmarked or UTF-16LE in NTLM code?
The NTLM code uses the charset UnicodeLittleUnmarked a lot. The official page: http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html says they are the same, but different APIs use a different canonical name. I assume the methods will therefore take either. Might be worth changing to the slightly shorter - but more obviously 16 bit - name? In any case, extracting as a constant and documenting the choice would be a good idea. Especially since the code also uses US-ASCII or ASCII sometimes (why?) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: UnicodeLittleUnmarked or UTF-16LE in NTLM code?
On Mon, 2013-07-08 at 11:10 +0100, sebb wrote: The NTLM code uses the charset UnicodeLittleUnmarked a lot. The official page: http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html says they are the same, but different APIs use a different canonical name. I assume the methods will therefore take either. Might be worth changing to the slightly shorter - but more obviously 16 bit - name? In any case, extracting as a constant and documenting the choice would be a good idea. Especially since the code also uses US-ASCII or ASCII sometimes (why?) Sebastian, I would like to propose to move to Java 1.6 at some point (rather sooner than later). One of the reasons to make this move is to be able to use Charset variant of String#getBytes() method and to clean up the use of various charsets throughout the code base, not just NTLM code. Maintaining Java 1.5 compatibility has been getting increasingly difficult and increasingly pointless. The question is whether this is too later for 4.3 or not. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: UnicodeLittleUnmarked or UTF-16LE in NTLM code?
On 8 July 2013 11:10, sebb seb...@gmail.com wrote: The NTLM code uses the charset UnicodeLittleUnmarked a lot. The official page: http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html says they are the same, but different APIs use a different canonical name. I assume the methods will therefore take either. Might be worth changing to the slightly shorter - but more obviously 16 bit - name? In any case, extracting as a constant and documenting the choice would be a good idea. Especially since the code also uses US-ASCII or ASCII sometimes (why?) I've just been looking at http://davenport.sourceforge.net/ntlm.html and this says that certain fields always use OEM encoding. This is documented as being the local machine's native character set (DOS codepage), however the code seems to use ASCII (or US-ASCII) for this. That seems wrong - although ASCII is likely to be a subset of the default encoding, this is not 100% guaranteed. If the code does make this assumption, I think it should be documented. - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: UnicodeLittleUnmarked or UTF-16LE in NTLM code?
On 8 July 2013 11:29, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2013-07-08 at 11:10 +0100, sebb wrote: The NTLM code uses the charset UnicodeLittleUnmarked a lot. The official page: http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html says they are the same, but different APIs use a different canonical name. I assume the methods will therefore take either. Might be worth changing to the slightly shorter - but more obviously 16 bit - name? In any case, extracting as a constant and documenting the choice would be a good idea. Especially since the code also uses US-ASCII or ASCII sometimes (why?) Sebastian, I would like to propose to move to Java 1.6 at some point (rather sooner than later). One of the reasons to make this move is to be able to use Charset variant of String#getBytes() method Yes, that's definitely easier. and to clean up the use of various charsets throughout the code base, not just NTLM code. Not sure that requires Java 1.6. Maintaining Java 1.5 compatibility has been getting increasingly difficult and increasingly pointless. The question is whether this is too later for 4.3 or not. There's still quite a lot of Java 1.5 out there, so I would suggest holding off requiring 1.6 until after 4.3. There are a lot of useful fixes etc in 4.3, so why not make them available to people still stuck on Java 5? Also conversion to Java 1.6 requires lots of changes to @Override. It's more work than might at first appear. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: UnicodeLittleUnmarked or UTF-16LE in NTLM code?
On Mon, 2013-07-08 at 11:35 +0100, sebb wrote: On 8 July 2013 11:29, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2013-07-08 at 11:10 +0100, sebb wrote: The NTLM code uses the charset UnicodeLittleUnmarked a lot. The official page: http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html says they are the same, but different APIs use a different canonical name. I assume the methods will therefore take either. Might be worth changing to the slightly shorter - but more obviously 16 bit - name? In any case, extracting as a constant and documenting the choice would be a good idea. Especially since the code also uses US-ASCII or ASCII sometimes (why?) Sebastian, I would like to propose to move to Java 1.6 at some point (rather sooner than later). One of the reasons to make this move is to be able to use Charset variant of String#getBytes() method Yes, that's definitely easier. and to clean up the use of various charsets throughout the code base, not just NTLM code. Not sure that requires Java 1.6. Maintaining Java 1.5 compatibility has been getting increasingly difficult and increasingly pointless. The question is whether this is too later for 4.3 or not. There's still quite a lot of Java 1.5 out there, so I would suggest holding off requiring 1.6 until after 4.3. There are a lot of useful fixes etc in 4.3, so why not make them available to people still stuck on Java 5? All right. Fair enough. Let's discuss the move post 4.3 Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: UnicodeLittleUnmarked or UTF-16LE in NTLM code?
On Jul 8, 2013, at 6:30, Oleg Kalnichevski ol...@apache.org wrote: On Mon, 2013-07-08 at 11:10 +0100, sebb wrote: The NTLM code uses the charset UnicodeLittleUnmarked a lot. The official page: http://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html says they are the same, but different APIs use a different canonical name. I assume the methods will therefore take either. Might be worth changing to the slightly shorter - but more obviously 16 bit - name? In any case, extracting as a constant and documenting the choice would be a good idea. Especially since the code also uses US-ASCII or ASCII sometimes (why?) Sebastian, I would like to propose to move to Java 1.6 at some point (rather sooner than later). One of the reasons to make this move is to be able to use Charset variant of String#getBytes() method and to clean up the use of various charsets throughout the code base, not just NTLM code. Maintaining Java 1.5 compatibility has been getting increasingly difficult and increasingly pointless. The question is whether this is too later for 4.3 or not. I would move to Java 6 now, a major release is as good a time as any and gives us the opportunity for changes that are easier to make than in a minor release. I would not want to be stuck with supporting Java 5 until the next major release. Gary Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPCLIENT-1383) NTLM authentication can enter in infinite loop
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ricardo Pereira closed HTTPCLIENT-1383. --- Tested with both the latest trunk and branch 4.2.x with no problems. Once again, thank you. NTLM authentication can enter in infinite loop -- Key: HTTPCLIENT-1383 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1383 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpAuth Affects Versions: Snapshot Reporter: Ricardo Pereira Fix For: 4.2.6, 4.3 Beta3 Attachments: ClientNtlmProxyAuthentication.java, HTTPCLIENT-1383_patch_tests, HTTPCLIENT-1383_patch_tests_non_unicode, wire.log If the NTLM proxy sends, always, a challenge message the authentication enters in infinite loop. This happened with an user account that got suspended because of too many failed authentication attempts, after that the server started to send, always, the (same) challenge message causing an infinite loop with the HttpClient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
