I have a Node.JS service running, which I am trying to connect from a different system. Currently using POSTMAN to test the service. Postman gives an error - There was an error connecting to https://lddbbtx.wdf......./index.xsjs.
Now, I retried the request by disabling 'SSL certification verification' option in Postman and it seems to work. I can receive the response from the service.
But in production, we will be using Recast.AI to connect to this service. In Recast, they provide a means to set Headers for the GET/POST requests . SO , I wanted to know, is there a way to disable the SSL verification in the header of the request ?
... is there a way to disable the SSL verification in the header of the request ?
Validation of the server certificate is done at the client side. It is done during the TLS handshake and thus before any HTTP request is send. Disabling validation cannot be triggered by the server since otherwise a man in the middle attacker could simply instruct the victim to not check the certificate.
In general - disabling validation or even part of the validation (like checking that hostname in URL matches certificate) is a very bad idea. With disabled certificate validation the transport is still encrypted but the client does not check that it actually communicates with the expected server. This way an attacker could do a simple man in the middle attack to impersonate the server and thus sniff and also modify all traffic.
Related
I am using pyhthon3 requests library and want to request some resources from the server using HTTPS. So I use two way SSL authentication, and I have configured the server in a way which do not REQUEST for client certificate in response of 'client Hello' request.
As You can see IP xxx.xx.xxx.100 is the client and IP xxx.xx.xxx.207 is the server. So when the client sends 'Client Hello' to the sever, in response the server does not REQUEST for the client certificate, even though its two way SSL authentication.
So as per my requirements, how can I stop the process of handshaking and data sharing immediately in such case? Or how to force the server to REQUEST for client certificate?
... even though its two way SSL authentication.
It's not. Just because the client has the certificate to do mutual authentication, does not mean that this certificate is actually used. It is only mutual authentication if the server actually requests it using a CertificateRequest (which is clearly not done) and the client then providing the requested certificate.
... how can I stop the process of handshaking and data sharing immediately in such case?
You can't. There is no API for this.
And I'm not sure what kind of sense such a requirement would make. The client has successfully authenticated the server which should be all needed by the client to exchange data with the server. The server instead might want to know who the client is before sending specific data. So authenticating the client before providing such data makes sense from a server perspective, but not from a client one. This would be like you refusing to drive a car if nobody is checking your drivers license.
Or how to force the server to REQUEST for client certificate?
This fully depends on the kind of server. Different servers need different configuration. For example with nginx see ssl_verify_client.
I am familiar with SSL/TLS and its mechanism to protect data sent over HTTP between the browser and the web server. One of the issues identified by my security testing team is request tampering over SSL where they were able to modify the HTTP request payload of a POST request using man-in-the-middle attack. The browser obviously did show a certificate validity warning and it was ignored.
In my opinion, the application shouldn't handle or remediate such request tampering scenarios because SSL/TLS takes care of it. Server side validation of data that matches any client side validation should suffice to ensure that the HTTP payload is valid.
So my question is basically to confirm my understanding about this. Is request tampering using man-in-the-middle attack over SSL a valid security testing scenario? And should an application do any specific request encoding to protect from such attacks.
Yes, it is a valid testing scenario.
Depending on the threat model of your application, the application might implement Certificate Pinning, to mitigate that threat. With that, you can make sure that only a specific cert (or certs signed by a certain CA are trusted.
See this answer for reference.
I am developing a backend for a mobile application using Node.js to handle HTTPS requests. I have set up an SSL to connect from the client to the server and was wondering if this was secure enough.
I don't have experience with intercepting endpoints from the mobile devices, but I have seen that it is possible for people to monitor internet traffic out of their cellphones and pick up endpoints to server requests. I have seen hacks on tinder where people can see response JSON and even automate swipes by sending http requests to tinder's endpoints.
My real concern is that people will be able to update/read/modify data on my backend. I can implement OAuth2 into my schema as well but I still see cases in which people could abuse the system.
My main question is whether or not using HTTPS is secure enough to protect my data, or if a session authentication system is needed like OAuth2.
Thanks.
HTTPS, providing it is properly configured, will ensure the message was not read or changed en route and that the client can know the server it is talking to is not a fake.
It will secure the transport. It will not secure the application.
For example supposing you have an app that allows you to send a message saying https://www.example.com/transfermoney?from=Kyle&to=BazzaDP&amount=9999.99 and the server does just that based on those parameters. Then I could send that message myself - I've no need to intercept any app messages.
Normally the server needs authentication as well as HTTPS to, for example, verify only Kyle user can send above message and not anyone else. HTTPS normally only gives server authentication not client authentication (unless using two way certificate HTTPS).
So the question is, even if an attacker cannot read or alter any messages between app and server can they still cause harm? That is the measure of whether it is secure enough.
A SSL connection is only secure with the content you are sending.
SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL
So i would say just using the SSL encryption is save to transfer data between - i might consider OAuth2 for password etc.
But i would recommend to use GET for retrieval data and post for authorized data
You're building an armored tunnel between two open fields.
Assuming that you use current SSL protocols and settings, and valid certificates from trusted issuers, you can pretty much assume the network is OK.
However it's still entirely possible to compromise any or all of your transaction from the client. Security really depends on the device and how well it's configured and patched.
When I have been trying to access gmail through browser and when proxy been enabled, I have been getting "sec_error_untrusted_issuer" and can't able to proceed further. I feel this is some security implementation by gmail to not to sniff it's requests & responses. am I right? or is there something that I have to configure in proxy (fiddler/open source tools).
Also, could you please let us know the details/background on this. and how to implement this type of security feature in applications.
The error message in question simply means that the client has not been configured to trust the root certificate authority that issued the certificate it received.
One way this would happen, for instance, is if you enabled HTTPS decryption in Fiddler, but when prompted to configure Windows to trust the Fiddler Root Certificate, you chose No.
this is how I try to the scheduler to work on my azure server, but every time I try set it up as it comes with an error like this:
Http Action - Request to host 'www.blabla.dk' failed: SecureChannelFailure The request was aborted: Could not create SSL/TLS secure channel.
I CloudFlare which makes my ssl, but it would then love to just check my ssl lies with CloudFlare.
This is what my set-up out to the scheduler, which does not make any sense since I have følgt Azure guid to set it up. but it still occurs with errors.
See here