I've got backend running on the tomcat server and client running in the browser. Application is built on Spring 3 MVC + Spring security framework. How to secure the communication ? Is there other option than just to set the server to be accessed only via HTTPS ? I've got no experience with this so it might be a stupid question, but will this affect my application and do I have to set something up in my app, when the server shall communicate with client via GET/POST request via https ?
It depends somewhat what you mean by "secure." If you want privacy, you must use TLS (SSL) as a transport.
If you're only concerned with authentication, then you have another option: Digest Authentication.
Digest Authentication allows the client (browser, usually) and the server to exchange authentication credentials in a secure manner without securing the entire communication. If you use Digest Authentication, then third parties can still:
See what data the client and server exchange
Insert themselves between the client and server and alter the exchange
What third parties cannot do is spoof the authentication or steal username/passwords in transit.
If that's not secure enough, you need TLS. You do not necessarily have to purchase a certificate. You can use OpenSSL to generate your own. This certificate will not automatically be trusted by browsers, however, so you can't really use it for public sites.
You will need to consult your server documentation for how to set up HTTPS or Digest Authentication, depending on which fits your needs.
Your application should not be affected by switching from HTTP to HTTPS, Tomcat handles this or maybe an Apache in front. It's important to understand, that HTTPS is a server-thing, not an application topic, because the client makes a connection to the server (Tomcat), not to your application. Check out the Tomcat documentation, it's pretty clear about how things work.
And, like the others said: From what you've said it's best to use HTTPS (TLS/SSL). Certificates are a bit frightning at the beginning, but it's worth to invest the time.
HTTPS is the (S)ecure form of HTTP, since you have an HTTP client server application I would certainly used HTTPS. All you need is to create an SSL certicate for your website and restrict access to your website to HTTPS only, then you are 99.99% secure.
Your certicate can be either commercial from Versign or equivalent or some open source engine.
for the clients nothing needs to be done to support HTTPS
Related
I am trying to build a client / server servlet application with these general requisites:
both the client and the server are jetty embedded;
the server expose a servlet in order to receive json data via POST;
the connection must be secured via SSL (i.e. the connection will be done via Internet via https);
I want that only my Jetty client be able to send data to my server, all other tentative must be refused by the server;
the server and the client are unattended machines (i.e. not password via command line could be inserted by human);
no password in clear must be stored on the client device. In general I don't want someone could open the remote client device and stole the password and building a fake remote device capable to send data to my server too.
I have build a perfectly working client / server application via HTTP but I am confused about the security.
I have read that there is the possibility to use client / server mutual authentication and seems what I am looking for but I can't get the complete picture.
In this document client-certificate-authentication there is a more or less clear explanation about how to build a shared trusted CA but the password for accessing the TrustStore and the KeyStore are in clear in the code.
I think I am missing a tile in the puzzle.
Could someone point me in the right direction?
Thanks,
S.
I'm going with a simple answer (for now).
If you just want only your clients to talk to the server, then yes, Client SSL/TLS certificates are the way to go.
You'll want the server's SslContextFactory.Server.setNeedClientAuth(true) set to true. That will in turn cause Java's javax.net.ssl.SSLParameters.setNeedClientAuth(true) to be set on incoming connection establishment. If the client fails to provide the client certificate, the connection is closed, and no HTTP request is sent or processed.
As for securing the client certificate, that's up to you, you can do anything you want to do, as long as it results in a valid client SslContextFactory.Client that the Jetty client can access. This includes ...
Using plaintext passwords
Using obfuscated passwords (minimal effort, minimal security)
Encrypted keystore/truststore passwords elsewhere in your client, provided to the SslContextFactory.Client at the last minute. (modest security, wouldn't be that hard to figure out)
Creating the java.security.KeyStore object yourself and handing it to SslContextFactory.Client.setKeyStore(KeyStore) and SslContextFactory.Client.setTrustStore(KeyStore) methods prior to starting the Jetty Client. (a bit better security wise, puts more work on your behalf)
You might want to consider having the client certificates be short-lived (24 hours?) dynamically refreshed from the server, and have the client certificates be revokable (at the server/CA side) if you encounter abuse. (such as the same client certificate from multiple different client IPs)
I am new in authentication/authorization. I need to expose some authenticated apis to be consumed by third parties (server to server). I read how I can do this and figured out that a good option is to use oauth2.
I want to implement this using java with spring boot. My first problem is how to generate client id and client secret. Can you help me with some advice/materials to implement this?
Thanks
For generating the Client-Id and Secret, this guide might be useful.
In all cryptographic affairs, try to find solid / well tested libraries, as mentioned in the article.
Client id and client secret is just a simple login / password pair. Usual constraint apply, just ensure that your secret is not too simple.
As there is only two party implied, the oauth flow is very simple (client credentials).
One server (the client) will consume resources on the other one (the resource server #EnableWebSecurity, #EnableResourceServer) using an access token acquired against the authorizations server beforehand. The resource server may also act as the authorization server (#EnableAuthorizationServer). The client is annotated using #EnableOAuth2Client.
If communication is bidirectionnal, both "server" must be resource server and client (and so have its own client id / secret pair), the authorization server may be independent or hosted by one or both server.
I want to be able to accept both web browser clients and (automated) service clients to a single servlet running in my application. Some of the service clients will authenticate with TLS client certificates, but some will not. I do not want web browser clients to be prompted for a certificate ever, even if the user has some installed in their browser. The decision on whether to prompt for a client certificate is dynamic and based on policy according to the client, so cannot be statically configured in web.xml.
Is there a way to dynamically trigger TLS renegotiation to request a client certificate from within a servlet? If I had access to the raw SSLSocket then I could configure it to require a client certificate and then call startHandshake() to force renegotiation. As far as I can tell, there is no portable way to get hold of the SSLSocket associated with a servlet request/response though.
My application has to run in a variety of servlet containers, so I'd prefer to avoid container-specific solutions if possible. Ideally the solution would not involve a redirect, but I will accept that if it is the only way.
You wrote in comments above:
because that setting will cause a web browser to prompt the user to
choose a certificate if they have one installed that matches one of
the configured CAs. I never want that to happen for web browser
clients
Then I vote for this is impossible to achieve from server side. TLS takes first before any data sent through secure channel. You can't determine is it web browser or not knocking at your door not asking for client identity. From TLS point of view this is just yet another unnamed network client attempts to connect. After secure connection established, data is sent, and you can determine this is browser or not.
You may want to pipe browsers (1 way ssl) and server client (2 way ssl) through different endpoints.
Otherwise you may want to implement you own TLS protocol handshake procedure.
You may want to configure browsers not to answer to client certificate requests instead of configure server not to ask if (if it would be possible) to determine this is browser-based client. May be try to guess it through the cypher suit (list of supported crypto modes) but this is definitely not servlet level of interaction.
I am curious somebody know ho to solve you question.
I have a requirement to use client/server architecture and with Open SSL authentication.
Here, how server to know the connect client using their OPen SSL certificate?
Anyone knows the link, sample then please reply me.We have to develop it in Java.
OpenSSL is not Java, so your solution cannot be both - but I think I know what is intended.
Normally OpenSSL is used as part of Apache http as part of mod_ssl. This in turn uses a "connector" to send the requests to an application server, e.g. Apache Tomcat. You can configure this connector to also send the SSL certificates to tomcat if that is required, but normally the authentication/verification is handled within the deamon.
All this is pretty easy to Google, although you should factor in some time to fully understand the connectors. You've the keywords, now use them :)
I have the following question on SSL/TLS.
After the server hello, starts the authentication phase of the server.
From various articles/books, it appears that this phase is optional. E.g. in wiki
The server sends its Certificate
message (depending on the selected
cipher suite, this may be omitted by
the server).
But I do not understand what it means to say that it depends on the encryption suite.
So my understanding is either a ServerKeyExchange or a Certificate follows a ServerHello.
So my question is, can the server authentication be omitted all together?
For example to omit client aunthentication in Tomcat, you just configure the connector to not request it.
How can the server authentication be omitted? Does it depend on the java framework I use, if it supports it?
And what does it mean to omit the server authentication? If the certificate is not send then the ServerKeyExchange becomes mandatory, or usually frameworks allow provisioning of a local public key instead if one wants to by pass-authentication phase for performance or because it does not make any sense?
Or does this depends on the encryption suite somehow, as wiki seems to imply?
NOTE:
I understand that server should always be authenticated. The context of my problem though is a client app and server running on the same machine (and java runtime I guess) so it can be considered safe to bypass server authentication (I think).
Any input is highly welcome!
Thanks!
In TLS/SSL, server authentication is optional.
If you choose TLS/SSL cipher suite without authn (such as TLS_NULL_WITH_NULL_NULL (turns off authn and encryption) or TLS_DH_anon_XXXX (use only encryption) in TLS specification), server certificate won't be sent.
TLS/SSL without authn doesn't seem to be supported pure-Java connector.
But I think the native-connector with SSLCipherSuite=aNULL supports it.
I don't know it's safe to disable authn, i.e., attacks such as DNS-spoofing might be threats.
I think you'd better to use server authn if performance is not problem.
Or, turning off TLS/SSL itself might be choice. (Encrypting server-client communication might be meaningless because administrator of the computer can steal certificate files and dump JVM heap.)
Authentication and Encryption are important when data travels across an untrusted network or when one of the endpoints is not trusted. If you application only makes connections on localhost, then Authentication and Encryption aren't important (the fact that your data and application are on locahost implies a trust in localhost).
you can get ssl configuration for tomcat 6 from
http://nayanmali.blogspot.com/
you got whole configuration and how to create keytool and how to generate certificate form that