What are the checks that will be performed when we call the method WL.Client.pinTrustedCertificatePublicKey for MobileFirst hybrid app ?
This is all explained in the documentation. See here: http://www.ibm.com/support/knowledgecenter/SSHSCD_7.1.0/com.ibm.worklight.dev.doc/monitor/c_cert_pinning_intro.html
Certificate pinning is the process of associating a host with its expected public key. Because you own both the server-side code and the client-side code, you can configure your client code to accept only a specific certificate for your domain name, instead of any certificate that corresponds to a trusted CA root certificate recognized by the operating system or browser.
A copy of the certificate is placed in your client application. During the SSL handshake (first request to the server), the IBM MobileFirst Platform Foundation for iOS client SDK verifies that the public key of the server certificate matches the public key of the certificate that is stored
in the app.
If pinning is successful, the public key inside the provided certificate is used to verify the integrity of the MobileFirst Server certificate during the secured request SSL/TLS handshake. If pinning fails, all SSL/TLS requests to the server are rejected by the client application.
The API initiates the pinning process.
Related
Currently I want to expose a gRPC Method as Public API and protected by Auth0 (JWT Token), with Istio(Envoy Proxy) will help validating the token on server side. Since the JWT Token is not encrypted by the standard (it is only used to end-user authentication and authorization layer), I want to encrypt the communication using TLS. Also, my public server already have valid certificate.
The problem is on the gRPC Client side. Every example I look, the gRPC Client have to initialize the TLS Connection with server cert pem file. Is it really necessary? Because it adds operational burden and complexity, where we have to distribute our server pem file everytime we renew the certificate AND/OR the client side has to restart the application.
Thanks,
Agung
If you are using a self signed certificate, then yes you must explicitly trust it in your client. If you use a publicly signed certificate on your Server, gRPC will use the Operating System's certificate authorities to verify the cert. (In the case of Java, it uses the JVMs cert authorities.)
If you are using a self-signed certificate you need to specify the server's root certificates in the pem_root_certs member of the SslCredentialsOptions struct passed in when creating a channel, as Carl says.
However if you are using a CA issued certificate, leaving the pem_root_certs member empty will cause gRPC to default to its own master list (reviewable online), not any OS-specific list.
If Tomcat is set up for SSL mutual authentication you can get the client javax.servlet.request.X509Certificate from the servlet request.
In the server app I need a key to encrypt a file.
Is it a good idea to use a part of the Client X509Certificate, e.g. the SubjectPublicKeyInfo as encryption key?
The client Certificate should be as secret as any password, shouldn't it?
(this question has Java API example, but is not Java specific)
I have installed a SSL certificate (comodo PositiveSSL) for my domain and forced NGINX to only use HTTPS.
I run the test on SSL analyzer
https://sslanalyzer.comodoca.com/?url=domain.com
Validation Type Domain Validated (DV)
Trusted by Microsoft? Yes
Trusted by Mozilla? Yes
We have our mobile app for Android and IOS getting some data from our https://example.com/api webservices.
So i have installed Packet Capture mobile app on my android to verify whether the data transferred between the webservice api and our mobile app is secured.
First i tried with enabling the following in Packet capture mobile app :-
I have contacted comodo ssl support, they said
that the certificate is installed well and its working fine. There is
nothing wrong with the certificate and installation process and the
web-site https://example.com/ is also completely secured with Green Pad
lock on it.
I run the same test on instagram app, when open instagram , showing network error. Like instagram discovering by some way that i am trying to capture a network packets so their app network will be disabled.
I want to do the same way of what instagram did .
Please Advice.
Don't worry, if your certificate is valid and contains the right domain name then you've already done everything needed.
A "man in the middle attack" is an attack done on the client.
The client think the attacker is the website by compromising his DNS
Then the attacker relay in and out traffic from/to the real server.
The server is secure but not the client.
Like RamKumar said the client need to trust the attacker certificate like you did
EDIT:
You can also use TLS with mutual authentication (mTLS).
With this protocol the client AND the server exchange certificate public keys.
It work as follow:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
Some sample:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/october/mutual-authentication-in-android-and-ios/
With this protocol the man in the middle attack is still possible but the attacker's certificates need to be trusted by both client and server
Another custom approach would be to add another layer of encryption using asymetric cipher.
To remove that possibility you can use Certificate Pinning to make sure that only the specific Certificate you use can be used to prevent the device from using any other Certificate, even if it was signed from a trusted CA. This may still be circumvented by a user, but now he has to modify the application itself in order to disable the check, or change the pinned certificate
Have a look at how Certificate Authority (CA) works. In your case, what happens is that the Packet capture mobile app installs it's own CA. Now Packet capture becomes a trusted CA for your device and certificates signed by them are accepted. Then this app creates its own certificate saying example.com and signs it.
So when it performs man in the middle attack, the client (your app) communicates with Packet capture and not example.com, but your app believes it's communicating with the example.com, since the certificate provided by Packet capture is signed by a trusted CA (Packet capture CA itself).
Hence this works only when your install their CA. However a secured connection is made between Packet capture and example.com
I have the following setup:
A self signed certificate for development purposes
An OWIN hosted Web API, deployed on a local Azure Service Fabric Cluster as a ASF service. The Web API uses HTTPS facilitated with the dev certificate in question.
A simple .net client application that calls the Web API. In that application the ServicePointManager.ServerCertificateValidationCallback method is set so it always returns true (since the CA is not trusted)
Both the client application and the Web API are on the same local development machine. The certificate is installed in that same machine on the "machine store"
Now I am able to make calls to the web api using Fiddler by providing the required client certificate. However when I try to do the same via .net code (be it RestSharp or WebRequest) the client certificate is not present in the RequestContext object on the server side. This result in an Unauthorized response. I do not think the problem is with the client code, the certificate is loaded correctly and assigned to the http client or request. Fiddler shows encrypted tunneling to the server. However the client certificate does not seem to be present at the server side.
I am at a complete loss regarding what am I missing that could cause this behavior. Any help will be deeply appreciated.
Install the certificate into the 'Local Machine/Trusted People'.
The server needs to already trust the certificate before it asks. The CertificateRequest message that it sends lists the acceptable CAs that can sign the client certificate. If the client certificate's signer isn't in that message, it can't send it.
How you accomplish that in your environment is left as an exercise for the reader. In general now that SSL certificates are available free there is little reason to indulge in the time costs and administrative inconveniences of self-signed certificates. IMHO there wasn't even if you were paying for a CA signature.
I had a problem when a service called another service over HTTPS and it couldn't setup a secure connection. My problem was that since the service is running as NETWORK SERVICE, it couldn't find the certificate, because it was looking in the localmachine/my certificate store.
When I was running from my web browser it was working fine because then, my browser found the certificate in the currectuser/my certificate store.
Add the certificate to the machine/my store and see if it helps.
I am working on a product that would be http POSTing some data to my server everyday. The server doesn't send any data/REQUESTS to my device (other than the HTTP status). I use a redpine wireless module RS9113 that does the connectivity piece for me. I want this communication to be https enabled and my web server already has a CA-issued certificate.
Question is :
When I do a POST from my embedded device, my understanding is that the SSL library would check the validity of the server certificate. Am I right ?
If my client doesnt need a certificate, does it mean the public key of the server is stored on the wireless module (and this is used for encryption everytime) ? I can guess that this is something I need to ask the redpine wireless folks, but can you give me a general idea how this works ?
In this setup, do I need to have any certificate ON my embedded device ? I am ok if anybody POSTs the data to the server because we have identifiers that would flush out the non-conforming structure of data. If there is no cert on the device and if we POST, does it mean that the data is encrypted from device-server ?
Bonus question : In this setup, if my cert on the server is renewed, will it cause any problems in sending the data ?
I do not know the redpine wireless module, so take this response as a resolution of doubts about SSL in general
When I do a POST from my embedded device, my understanding is that the SSL library would check the validity of the server certificate. Am I right ?
Yes, the SSL library should check that the issuer of the certificate (the root CA) or the certificate itself are present in the trust store. If you use a self-signed certificate or a CA that is not present in the truststore, you have to include the public key in the truststore
If my client doesnt need a certificate, does it mean the public key of the server is stored on the wireless module (and this is used for encryption everytime) ?
The two things are not related. You need the public key of the server in the wireless module to establish trust. A client certificate would be needed if you use two-ways authentication. The client certificate is presented during SSL handshake to authenticate the client to the server
In this setup, do I need to have any certificate ON my embedded device ?
No, if two ways authentication are not required
If there is no cert on the device and if we POST, does it mean that the data is encrypted from device-server ?
The client certificate, if any, is not used to encrypt. Is used to authenticate during the initial handshake. The handshake stablish a symmetric key used to encrypt and decrypt the communication in both sides.
In this setup, if my cert on the server is renewed, will it cause any problems in sending the data ?
Depending on the setup of the server certificate on your client truststore. If the new certificate is issued on the same side, it is enough to have imported the root CA. If you use self-signed certificate, you will need to import the new one