if you have a look at the RFC where the TLS is specified and the 'Client
Hello' therein you can see that a random number -> session ID is required.
http://tools.ietf.org/html/rfc5246#section-7.4.1.2
In the Wireshark trace I see the correct session ID of length 32 in the
browser trace and of length 0 in the Java trace.
Therefore the Java implementation is wrong. But coming back to my
question. How can I set the session ID in the HTTP client? In my opinion
it should be done automatically. It might be an issue in the HTTP client
development.
Why do you think a keystore is required?
At first I tried to debug with Firebug without success - that's why I
traced with Wireshark (much more low level than Firebug).
kind regards
Horst
Am 05.11.2013 23:02, schrieb kim young ill:
not sure if i understand you correctly but what's the sessionid you mention
? do you want to authenticate yourself with server with your private
certificate (ssl/tls layer) or with username/password (http-layer) ? with
the first case you need to customize your keystore, for the 2nd case you
just need to open firebug or chrome-dev tool or sth similar to see what's
going on.
On Tue, Nov 5, 2013 at 6:44 PM, Horst Weigelt <[email protected]> wrote:
Thank you Kim,
yes I did not mention how I came up with the idea of a missing session ID.
I traced the network communication with Wireshark and compared the
successful browser trace with the Java trace.
The first difference in the traces is that the client does not send a
session ID in the Java case. In the browser case the session ID is sent by
the client and responded by the server. I am not 100 % sure but the session
ID might be required for the data encryption.
The protocol is explained here
http://en.wikipedia.org/wiki/Transport_Layer_Security#Basic_TLS_handshake
where the random number is the session ID
and here
http://commons.wikimedia.org/wiki/File:SSL_handshake_with_
two_way_authentication_with_certificates.svg
kind regards
Horst
Am 04.11.2013 23:25, schrieb kim young ill:
200 is a http-response code, only means the request comes & handled by
server correcly, no error/exception, doesnt mean the username/password is
correct.
try to use the browser to see how the login-request looks like in both
cases or simply log the server-response.
hth
On Sat, Nov 2, 2013 at 2:39 PM, Horst Weigelt <[email protected]>
wrote:
|I want to logon to a https URL using Apache HTTP Client 4.3
The login fails. However I receive HTTP status 200 when posting the
request.
One issue for the login failure might be that there is no session ID send
in the|
|TLSv1 handshake protocol (Length: 0)
That raises 2 questions:
1) Is a session ID required for the login. If yes how can I set the
session ID.
2) Is there something else missing in the Java code below (except for the
correct URL + login/password ;-) )
This question is also posted (more or less identically) in
http://stackoverflow.com/questions/19737218/session-id-
missing-in-https-post-using-apache-httpclient-4-3
HttpClientContext context= HttpClientContext.create();
/* to follow redirections */ RedirectStrategy
redirectStrategy=
new LaxRedirectStrategy();
RequestConfig globalConfig= RequestConfig.custom()
.setCookieSpec(CookieSpecs.BEST_MATCH)
.build();
RequestConfig localConfig= RequestConfig.copy(globalConfig)
.setCookieSpec(CookieSpecs.BROWSER_COMPATIBILITY)
.build();
try {
SSLContext sslcontext= SSLContexts.custom()
.build();
SSLConnectionSocketFactory sslsf= new
SSLConnectionSocketFactory(sslcontext,
SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_
VERIFIER);
/* setup client for https and redirections */
httpclient= HttpClients.custom()
.setRedirectStrategy(redirectStrategy)
.setSSLSocketFactory(sslsf)
.build();
HttpPost httpost= new HttpPost("https://myURL";);
httpost.setConfig(localConfig);
/* set login and password */
httpost.setEntity(new UrlEncodedFormEntity(login_and_passwd,
Consts.UTF_8));
CloseableHttpResponse httpresponse=
httpclient.execute(httpost);
}
} finally {
httpclient.close();
}
return httpclient;
Thanks for any help
Horst
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
