HI everyone. I've just started to play a little with XMPP in java, both server and client side.
On the server side I'm using Apache Vysper 0.7 and on client side I'm using Ignite Smack 3.1.0
I'm using a small XMPP embedded server from the apache vysper demo page using a TLS certificate that comes with the source code:
XMPPServer server = new XMPPServer("localhost");
StorageProviderRegistry providerRegistry = new MemoryStorageProviderRegistry();
AccountManagement accountManagement = (AccountManagement) providerRegistry.retrieve(AccountManagement.class);
Entity user = EntityImpl.parseUnchecked("user#localhost");
accountManagement.addUser(user, "password");
server.setStorageProviderRegistry(providerRegistry);
server.addEndpoint(new TCPEndpoint());
server.setTLSCertificateInfo(new File("bogus_mina_tls.cert"), "boguspw");
server.start();
System.out.println("Vysper server is running...");
The problem is that this is not a correct/valid certificate. If I test my server using pidgin an alert window pops up and tells me the certificate is invalid and a button in case I want to add an exception for this.
What I want is to do the same thing with the Smack api, but I don't know how.
on my smack api I'm using something like this:
ConnectionConfiguration config = new ConnectionConfiguration("localhost",5222, "localhost");
config.setSASLAuthenticationEnabled(false);
connection = new XMPPConnection(config);
connection.connect();
connection.login(userName, password);
So here it is. What do I need to do to accept or decline invalid certificates ?
Thanks for your help.
In the integration tests in Apache Vysper, we use something like:
ConnectionConfiguration connectionConfiguration = new ConnectionConfiguration("localhost", 5222);
connectionConfiguration.setSecurityMode(ConnectionConfiguration.SecurityMode.required);
connectionConfiguration.setSASLAuthenticationEnabled(true);
connectionConfiguration.setKeystorePath("src/main/resources/bogus_mina_tls.cert");
connectionConfiguration.setTruststorePath("src/main/resources/bogus_mina_tls.cert");
connectionConfiguration.setTruststorePassword("boguspw");
See for example: https://svn.apache.org/repos/asf/mina/vysper/trunk/server/core-inttest/src/test/java/org/apache/vysper/xmpp/modules/extension/xep0199_xmppping/AbstractIntegrationTestCase.java
I think you are looking for
config.setSelfSignedCertificateEnabled(true)
Related
I develop a code to access a SOAP-Server via proxy and regarding to the description here I can set a global Proxy. Although my question seems Naive but I have not find any guide how to set Username and Password for this proxy setting in my java code?
you can at runtime get the System's properties and set all what you need to configurate the proxy...
Example:
System.getProperties().put("http.proxyHost", "myProxyURL");
System.getProperties().put("http.proxyPort", "myProxyPort");
System.getProperties().put("http.proxyUser", "myUserName");
System.getProperties().put("http.proxyPassword", "myPassword");
After some days I found the solution in my case and I try to explain it here.
It is important to know which kind of SOAP Client service you have wrote. In my case I used CXF 3.1.7 to generate Java code. To be more explicit I had a WSDL file and Generated the code via wsdl2java plugin in maven with the mentioned version.
In the level of the WebService the follwoing can be done in code to enter the proxy Setting
private void setProxySetting(EventPortType port) {
try{
Client client = ClientProxy.getClient(port);
HTTPConduit http = (HTTPConduit) client.getConduit();
http.getClient().setProxyServer("***host***");
http.getClient().setProxyServerPort(80);
http.getProxyAuthorization().setUserName("***username***");
http.getProxyAuthorization().setPassword("***password***");
}catch (Exception e) {
logger.error("Please Enter your proxy setting in MyClass class", e);
}
}
The port is comming from the Service Level that I got like this
EventService es = new EventService();
EventPortType port = es.getEventPort();
setProxySetting();
I am attempting to connect to an HTTPS endpoint in Java. Every method I have tried (more details below) ends up generating this stack trace:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:753)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
I have tried:
Connecting with the javax SOAP libs and a new URL("https://...")
Connecting with new URL("https://...").openConnection()
Creating an SSL connection by hand:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket socket = (SSLSocket) factory.createSocket("...", 443);
Writer out = new OutputStreamWriter(socket.getOutputStream());
// https requires the full URL in the GET line
//
out.write("GET / HTTP/1.0\r\n");
out.write("\r\n");
out.flush();
// read response
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
int c;
while ((c = in.read()) != -1) {
System.out.write(c);
}
out.close();
in.close();
socket.close();
A few more details:
Every method I have tried has worked against other SSL servers, it's this particular server (I am not at liberty to discuss what server, it's a business partner)
I can connect to this server both with a web browser, and with a faked up SOAP request with curl; This is something Java-specific.
So, it seems pretty clear that there is some disagreement between Java and the HTTPS server over how the handshake should go down, which probably means the server has some strange SSL configuration. However, I don't have direct access to the server, and the people who do are halfway around the world, so communication is a little strained due to very different timezones.
If my assumptions there are correct, what possible SSL problems could there be? What might cause something like this? Where can I ask the people in control of the server to look for issues? When I do the request with curl, I get back these server configuration headers:
Server: Apache/2.2.9 (Debian) mod_jk/1.2.26 PHP/5.2.6-1+lenny10 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
X-Powered-By: PHP/5.2.6-1+lenny10
X-SOAP-Server: NuSOAP/0.7.3 (1.114)
It is an SSL version problem. The server only supports SSLv3, and Java will start at v2, and attempt to negotiate upwards, but not all servers support that type of negotiation.
Forcing java to use SSLv3 only is the only solution I'm aware of.
Edit, there are two ways to do this that I'm aware of:
If you are creating the socket by hand, you can set the enabled protocols
socket.setEnabledProtocols(new String[] { "SSLv3" });
If you are using a higher level library, you probably need to set all SSL requests to use v3 only, which is accomplished with the "https.protocols" system property:
java -Dhttps.protocols=SSLv3
Maybe also try setting the HTTP version to 1.1 instead of 1.0, as there's some real advantages to the newer standard.
I'm trying to make a jersey client call using NTLM proxy? is that possible as i was not able to get any clear information on the same. Did anyone tried before?
Yes it is possible to configure the Jersey Client to connect through a proxy server that requires NTLM authentication.
Here is a simplified code snippet that prepares a suitable ClientConfig that should work with Jersey v2.5+:
final ClientConfig config = new ClientConfig();
config.property(ClientProperties.PROXY_URI, "http://myproxy.com:8000");
CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
final AuthScope ntlmAuthScope =
new AuthScope("myproxy.com", 8000, AuthScope.ANY_REALM, "NTLM");
credentialsProvider.setCredentials(
ntlmAuthScope,
new NTCredentials("user", "password", "hostname", "domain") );
config.property(
ApacheClientProperties.CREDENTIALS_PROVIDER, credentialsProvider);
config.connectorProvider(new ApacheConnectorProvider());
Client client = ClientBuilder.newClient(config);
Please note: I am using the Apache HttpClient connector with Jersey Client - you may require slightly different code if you are using another client transport connector.
You may also need to add the following line to your code if you want your POST/PUT requests to be buffered (and therefore repeatable) in response to any 407 authentication challenges that come back from your proxy server:
config.property(ClientProperties.REQUEST_ENTITY_PROCESSING,
RequestEntityProcessing.BUFFERED);
I need to add TLS support to a simple Java-based SMTP client. The client implements the SMTP protocol over java.net.Socket, i.e. it does not use Java Mail or other high level APIs.
I would like to use BouncyCastle's lightweight TLS API for this task. I have been looking for examples but haven't been able to find too much. Can anyone give any pointers?
Turns out this was much easier than I expected. I could establish a secure SSL connection to a SMTP mail server by just modifying the original SMTP client code from this:
Socket s = new Socket(server, port);
InputStream is = s.getInputStream();
InputStream os = s.getOutputStream();
[...]
To this:
Socket s = new Socket(server, port);
TlsProtocolHandler handler = new TlsProtocolHandler(s.getInputStream(),
s.getOutputStream());
handler.connect(new AlwaysValidVerifyer());
InputStream is = handler.getInputStream();
InputStream os = handler.getOutputStream();
[...]
The server's certificate is not being verified yet (AlwaysValidVerifier is a dummy verifier that will accept anything) but this is a good start already.
I am attempting to connect to an HTTPS endpoint in Java. Every method I have tried (more details below) ends up generating this stack trace:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:753)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
I have tried:
Connecting with the javax SOAP libs and a new URL("https://...")
Connecting with new URL("https://...").openConnection()
Creating an SSL connection by hand:
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket socket = (SSLSocket) factory.createSocket("...", 443);
Writer out = new OutputStreamWriter(socket.getOutputStream());
// https requires the full URL in the GET line
//
out.write("GET / HTTP/1.0\r\n");
out.write("\r\n");
out.flush();
// read response
BufferedReader in = new BufferedReader(
new InputStreamReader(socket.getInputStream()));
int c;
while ((c = in.read()) != -1) {
System.out.write(c);
}
out.close();
in.close();
socket.close();
A few more details:
Every method I have tried has worked against other SSL servers, it's this particular server (I am not at liberty to discuss what server, it's a business partner)
I can connect to this server both with a web browser, and with a faked up SOAP request with curl; This is something Java-specific.
So, it seems pretty clear that there is some disagreement between Java and the HTTPS server over how the handshake should go down, which probably means the server has some strange SSL configuration. However, I don't have direct access to the server, and the people who do are halfway around the world, so communication is a little strained due to very different timezones.
If my assumptions there are correct, what possible SSL problems could there be? What might cause something like this? Where can I ask the people in control of the server to look for issues? When I do the request with curl, I get back these server configuration headers:
Server: Apache/2.2.9 (Debian) mod_jk/1.2.26 PHP/5.2.6-1+lenny10 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0
X-Powered-By: PHP/5.2.6-1+lenny10
X-SOAP-Server: NuSOAP/0.7.3 (1.114)
It is an SSL version problem. The server only supports SSLv3, and Java will start at v2, and attempt to negotiate upwards, but not all servers support that type of negotiation.
Forcing java to use SSLv3 only is the only solution I'm aware of.
Edit, there are two ways to do this that I'm aware of:
If you are creating the socket by hand, you can set the enabled protocols
socket.setEnabledProtocols(new String[] { "SSLv3" });
If you are using a higher level library, you probably need to set all SSL requests to use v3 only, which is accomplished with the "https.protocols" system property:
java -Dhttps.protocols=SSLv3
Maybe also try setting the HTTP version to 1.1 instead of 1.0, as there's some real advantages to the newer standard.