CODEWITHSUNDEEP
springsecuritytomcatssl
user2337558
user2337558

Reputation: 5

Server to Client SSL Encryption w/o SSL Authentication - Tomcat & Spring

Scenario: Sensitive information is exchanged (1) from client to server AND (2) from server to client.

Problem: Data exchanged is not encrypted, so sniffing is easy (it's always theoretically possible, right?)

Solution: Encrypt all data transmitted in either direction (server-to-client and client-to-server).

Implementation:

(1) Client to server - Generate certificate, install private key on server and configure Tomcat to work on HTTPS (Many tutorials for this online).

(2) Server to client - Private key goes to (or generated by) clients, however it seems that some tutorials strongly emphasize that that every client should have their own certificate for the sake of authentication.

Question: If I am already authenticating my users through a database username/password (hashed with salt) combo, but I still need to encrypt server-to-client data transmissions to reduce chance of sniffing, can I just generate one private key for all clients? Are there other ways of achieving what I need with Tomcat/Spring?

Upvotes: 0

Views: 336

Answers (1)

Olaf Kock
Olaf Kock

Reputation: 48087

It seems you're mixing something up:

Regular https includes encryption in both directions, and only a private key + certificate on the server side. Once a client requests resources through https, they get the answer encrypted. So you'll just need to enforce the https connection (e.g. by redirecting certain requests to https with no delivery of data through http)

If you want client certificates, these are purely used for client authentication, so sharing a common client key/certificate with all possible clients will defeat this purpose. Having client keys/certs does not add any more encryption to your data transfer.

Answering to your follow-up question in the comment:

For https, the server keeps its private key, the public key is what is shared with the client. On typical https, the client can be reasonably sure who the server is (authentication, done through the trustworthy signature on the server's public key. This is what you pay trustcenters for) However, the server has no clue who the client is (here client certificates would come into play, but purely for authentication, not for encryption)

Server and client negotiate a common session key. For this purpose there are many different implementations of the key-exchange protocol. This forum is probably not the right place to describe session negotiation and the ssl handshake again, but you can be sure that you only need a server side key for the purpose you describe above: Take any website as an example: If you go to google mail, their https encryption works through them having a private key and a certified (signed) public key: You have no client side certification, but provide your username and password through the encrypted connection to them. Otherwise you'd have to install a client side key/certificate for a lot of services - and that would be too much of a burden for the average internet user.

Hope that helps.

Upvotes: 1

Related Questions