Situation
We have a Windows Service that is listening on a TCP port. This service is responsible for capturing a user's fingerprint using the Windows Biometric Framework, when requested to do so by a client. It then sends the image through the socket back to the client. Important: it should only answer requests coming from local clients (127.0.0.1). The firewall makes sure the port cannot be reached from the outside. Then, this image is NOT be processed by the client, but it will be sent to yet another service (let's call this the final destination). This final destination might be hosted on another machine.
The socket thus only exists between the client and the windows service. The client and the final destination talk with each other through https.
socket | https
Windows service (TCP) ----------- Client---- |----------------- Final destination
|
|
|
LOCAL MACHINE | INTERNET
Rationale to start using SSLsockets
I am wondering whether or not I should turn the socket into an ssl socket with client authentication. In my view, doing so would help me in achieving the following:
- Verify that it is actually the real server that the client is talking to
- Encrypt the fingerprint data that is travelling through the socket
- Prevent the data that is travelling through the socket from replays
- Verify that only a trusted client is talking to the service
What is the threat?
However, I am at a point where I wonder whether or not all of the above is worth the trouble. In order for an attacker to break the original plain socket system, he or she would have to have access to my machine (e.g. with malware). So, there is only a threat in case my machine is compromised.
When using plain text sockets, the malware would be able to intercept my fingerprint when flowing through the socket.
<=> When using ssl sockets, the malware could just as well intercept the data before it enters the ssl tunnel (i.e. intercept the service call to the WBF).
When using plain text sockets, the malware could easily modify the data in transit.
<=> When using ssl sockets, the malware could just as well modify the data before it enters the ssl tunnel. Moreover, this attack would only compromise the availability (send unknown fingerprints).
When using plain text sockets, the malware could easily replay the data.
<=> When using ssl sockets, the malware could just as well kick out the original service, take its private key, impersonate it, and send whatever data he or she likes.
When using client authentication, the service would be able to verify all calls from the client. However, the malware could replace the original service and just verify anything.
My question is: would using SSL sockets really improve the security of this set-up, or is it not worth the effort? Am I forgetting threats here and/or are there better ways to achieve better security here?
Difference with this question:
The answers to the other question merely talk about the security of the socket itself. I want to make sure that my whole set-up is secure. (e.g. how easy would it be for an attacker to capture data before it enters the socket).
I want to make sure that I do not overlook any possible threats, such as:
a. Unintential exposure (e.g. firewall management mistake) (thanks @gowenfawr)
I want to make sure that I make it as hard as possible for an attacker:
a. It might be a lot easier to capture the plain text socket traffic, than to go ahead and capture the traffic before it enters the socket.
b. At first sight, it seems that encryption of the fingerprint before entering the plain text socket would make it much harder for an attacker to get a valid representation of my fingerprint (more or less the same point as the previous one) => I do not need SSL for this, I can just encrypt my data before it enters the socket. Still, is it worth it?
c. Does it make sense to use asymmetric cryptography for the fingerprint encryption, or will symmetric encryption be just as secure? (i.e. if they can get to the key, they probably are just as well able to access the raw fingerprint data).
d. In my set-up, it seems very easy for an attacker to just ‘hijack’ my port, run its own service, and take fingerprints from that service. However, it is probably harder to do (as it requires higher privileges) than just calling my existing service. Reading that question, and rethinking my own question has brought me to believe that SSL itself would not be any more secure. What would seem more secure to me is encrypting the fingerprint data before it goes through the socket, with the public key of the final destination.
I guess in the end my question should be: does encryption add any security to my set-up, or will it just as easy for an attacker to get the data before it becomes encrypted?
