I have written simple app which uses Spring RestTemplate to Another REST API.
Sample :
SomeClassresponse = restTemplate.postForObject("https://rest-endpoint.com", body, SomeClass.class);
"https://rest-endpoint.com" is using SSL. But my application is not, however according spring documentation RestTemplate "Spring's central class for synchronous client-side HTTP access.". So I'am using Client, as far as I understand I don't need to use SSL for data protection from sniffing packets? Or I'am I wrong?
That is correct.
The server hosting the RESTful endpoint is responsible for providing SSL. The SSL handshake occurs before your client delivers the payload. During the SSL handshake, the server shares its public asymmetric key with the client, and retains its private asymmetric key which it never shares with anybody. These keys are used to establish a single session key which will be used for encrypting all communication (except for IP addresses) during the session.
You can verify this with a network protocol analyzer such as Wireshark which allows you to inspect packets traversing your network. Run Wireshark and capture the packets that your client sends to the endpoint and you should see that they are encrypted.
Related
I would appreciate it if you could confirm the following for me:
Assuming I implement the following protocol using NodeJS over an insecure socket connection (I believe it is a common implementation and it is how SSL works), will my communication end up being safe by the end of it? It would be nice if you could confirm that this manual implementation is in fact an alternative to certificates.
There are other posted questions similar to this one, but I couldn't find one that confirms the signature part of the protocol which, according to my knowledge, beats the MITM attack.
Server sends his public key to the connected client
Client sends his public key to the server
Server sends a challenge to the client to ensure he has the private key to the public key that was exchanged (asking the client to prove himself)
Client sends a signed challenge to the server using his private key
Server verifies the signature using the client's public key
If the verification works, the client is who he claims he is (beats MITM attack)
If the verification fails, it means that the client lied about who he is by sending a public key he does not own
At this point, the server either fully trusts the client or not.
The server can now generate an AES key and send it in an encrypted manner to the client using the client's public key
Both ends have the AES key and all future communication is encrypted.
Thank you.
I am trying to add an API Gateway to a client-server system, which communicates through WebSockets.
The Server is an audio recognition engine that sits in a remote machine, and clients are connecting to it through WebSockets ('wss://...'), sending audio files and receiving their text translate representation.
My main goal is to add a free open-source API Gateway in the middle in order to authenticate\authorize\rate limit\etc (Tried Kong\Tyk\krakenD, but they are not free).
After searching the web, I focused on Apache APISIX gateway.
As a test, I managed to connect the APISIX to a client-server which communicates by http/https and it worked fine.
Moreover, I managed to connect the client with the server on regular websocket connection (ws://) and the data transactions were successful, but no matter what I do I cant connect to the secured connection. Are there any special configurations I should edit in the dashboard?
I'm wondering if anyone knows from experience if it's possible to use
the secured WebSockets with Apache APISIX and if yes, how exactly it should be done - because the docs are missing any informative info\examples, or if there are better solutions known to my problem.
The only WebSocket reference in APISIX dashboard -
What you should do is create an SSL object (you can find it in the sidebar on the left side). See https://apisix.apache.org/docs/apisix/admin-api/#ssl to learn the APISIX SSL object.
You can see an example at https://apisix.apache.org/docs/apisix/certificate
The SSL object provides the required TLS Certificate and Private Key so that this key pair can be used in a TLS handshake according to the TLS SNI sent from clients. After that, your client established a secured connection with APISIX, and now you can send the WebSocket traffic securely.
Is this supported?
A controller with incoming https request on one port, the controller calling a https web service with RestTemplate and forwarding the service response.
That isn't really multiple SSL connections. If you look at it as incoming and outgoing requests. On the incoming request to support SSL the server has to emit a certificate. It can be self signed or from a root authority. For the outgoing request the app is specifying that the protocol is HTTPS and then validating the server certificate is valid. If the certificate being validated is from a know root cert then the http client handles that on your behalf. If not then you would have to add the root cert to your keychain.
Now with that understanding there is nothing stopping you from configuring multiple incoming SSL endpoints and as well making multiple outgoing SSL requests. It is just a matter of configuring the specific connections. For that I would refer you to the Spring reference documentation as it has a lot of information on it as well as examples.
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?
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.
I wanted to understand the mechanism of message encryption and signing used by NetTcpBinding when 'Windows' credentials are being used with Transport security. What if my AD uses NTLM instead of Kerberos? Will the messages still get signed and encrypted?If so, how?
Thanks in Advance,
Akshat
The short answer is that, yes, with NTLM authentication the messages will still get signed and encrypted if you have set the Transport security ProtectionLevel to EncryptAndSign (the default).
Here's an outline of how it works:
selecting Transport security
configures a
WindowsStreamSecurityBindingElement
in the channel stack. This inserts a
stream upgrade provider (see below)
in the NetTcpBinding, message
exchange between the client and
service happens within the .NET Message
Framing Protocol, which provides both
message framing and a mechanism for
client and service to negotiate
stream upgrades, the principal use of
which is to establish transport
security. If there is a stream
upgrade provider configured in the
channel stack, this will be invoked
during the Preamble stage of the
Framing Protocol when the client
opens the channel.
the upgrade
provider for
WindowsStreamSecurityBindingElement invokes an SSPI handshake between the client and the server using the SPNEGO security package: in the NetTcpBinding this will normally result in Kerberos being selected as the underlying security provider if available, but will choose NTLM if not.
if NTLM is the resulting authentication provider, the SSPI handshake will involve the three-leg NTLM challenge-response exchange of tokens described in the NTLM specification. This protocol includes a mechanism for exchanging keys for message signing and encryption. Once the SSPI handshake has generated an appropriate security context, thereafter all messages exchanged are signed and encrypted in the sending channel stack's stream upgrade provider, and decrypted and verified in the receiving channel stack's stream upgrade provider, in each case by using calls to the NTLM security provider via the abstracted SSPI message support functions.
This is a Microsoft propriety implementation and not properly documented and perhaps on purpose to prevent intruders to take advantage of it.
As far as I know, this usually happens at the TCP level with a special token is generated by the user's credentials and passed along with the request. This is intercepted by windows security channel and authenticated against the AD.
This token is used as a key (or as a basis for generating the key) for encrypting the communication.
I think if you look at the TCP packet, you must be able to see the token - although I have never seen it.
If you are doing this all in code then you can find out the options here (search for 'NetTcpBinding'). Transport security is via Windows builtin TLS.
The diagram here should be helpful for your scenario.