So i was sniffing through the pages of PKI's Overview by Joel Weise (http://highsecu.free.fr/db/outils_de_securite/cryptographie/pki/publickey.pdf) and one thing i didn't quite get is, when to use an OCSP responder over LDAP for checking up the validity of a given certificate ? Say some CA exposes both - when to use the OCSP service, when to use the Certificate Depositories LDAP servers ?
It might be helpful to think this way.
The Certificate Authority generates certificate revocation lists (CRLs). (You could query the CA directly but this is a bad idea due to risk of exposing private keys (secrets)).
The CRLs can then be made available via LDAP or HTTP. (if you have a small deployment you can likely stop here)
An OCSP server (or validation authority depending on the vernacular) can also consume CRLs. Once it does so it can handle validation (certificate status) requests. (if you have a larger deployment and handling CRLs is cumbersome you might consider this option)
There are options (3rd parties, e.g. not Microsoft) for there to be distributed OCSP responders that have pre-signed the responses and then forward and store (as opposed to multiple OCSP servers). (consider if you still have a relatively larger deployment and where you have network availability, scale, loading issues as another option).
Finally make sure that you are not only checking certificate status but also certificate trust. In federated environments you may want to consider the Server Certificate Validation Protocol (SCVP) as a complement to the above.
Related
I have generated a self signed certificate .This self signed certificate is stored in server and accepts request only from clients which is having this self signed certificate is this acceptable. since this HTTPS endpoint is supposed to be used only from our custom HTTPS client I strongly feel that CA signing is not required .
But my colleagues are warning that Self signed certificate should not be used in production environment no matter what .what should I do ??
There is a whole infrastructure in place to manage the life-cycle of the certificates, it is called PKI (Public Key Infrastructure). The CA's are part of it, and help you manage the certificate issuance and revocation.
It is not advised to use self-signed certificates in production environment, because you loose the life-cycle management of the certificate. Lets say if the client is compromised, any one in possession of that self-signed certificate can talk to the server. There is no way you can manage to revoke that certificate or maintain the CRL.
The ideal solution/implementation in your case, will actually be issuing the clients their own PKCS12 from the CA as well, which means they will have their own private key (this might get expensive, if you have many clients). But this is most secure way of doing it. If you know a client is compromised, you can revoke that client's certificate from the CA, and if the client does certificate validation (ideally should), it should no longer be able to communicate with the server. You can simply decommission that client.
Just an idea
But if you are looking for cost effective way (since you mentioned internal calls), you could have your server issue P12's to the clients, and your server maintaining a record of which client has what certificate. This gives you little control of managing the clients. You could enable certificate based authentication on the server side for those services (the server will receive the subjectDN of the client), and by referring to the stored record, you can identify which client is trying to communicate. And if you want to disable that client from being served by the server, simple update the record.
But to answer your concern, it is not ideal to use self-signed certificate because, in real world, you should be able to manage the certificates in real time or near to real time, which will not be possible if you use self-signed certificates.
Can someone explain the difference between validating a certificate like described with a self-signed certificate here:
https://jetforme.org/2013/05/validating-a-self-signed-ssl-certificate-in-ios-and-os-x-against-a-changing-host-name/
and SSL pinning like described here:
https://infinum.co/the-capsized-eight/how-to-make-your-ios-apps-more-secure-with-ssl-pinning
What does SecPolicyCreateSSL means?
What in detail is SecTrustEvaluate doing?
Is the procedure in the first link including SSL pinning?
If not, is it a good idea to implement both?
Thanks
First let's clarify the terminology in the Cocoa world:
A SecPolicyRef is a policy that defines the rules when validating a certificate chain: the things to check for in the certificates within the chain (signature, expiration date, etc.), which determine whether the certificate chain is valid/trusted or not.
A SecTrustRef object is the combination of a certificate chain (basically an array of SecCertificateRef) and a SecPolicyRef. This object represents all the things needed to validate a certificate chain (the certificates + the policy).
Validating a server's certificate chain involves two steps:
The certificate path needs to be validated (the signatures, the expiration date, etc.) to ensure that the server certificate was issued by a trusted CA.
The name for which the server certificate was issued (Common Name or Subject Alternative Name) needs to match the name of the server the App is trying to connect to.
These steps are expressed by a SecPolicyRef:
SecPolicyCreateBasicX509() returns a policy that has all the things to check for 1; this is there for historical reasons but it should never be used.
SecPolicyCreateSSL() returns a policy that has all the rules for both 1 and 2; this is the one you must use.
You then use SecTrustEvaluate() to validate the server's SecTrustRef. The result will tell you if the server's certificate chain is trusted based on the SecPolicyRef that was passed.
Lastly, SSL pinning means adding a third step to this whole process:
The certificate chain must contain a specific key or certificate. This ensures that only the certificate you know you deployed on your servers will be accepted by the App, instead of any certificate issued by any CA for your domain.
I would advise against writing your own implementation of SSL validation (with or without pinning) as, you can tell, the APIs are extremely complex and there is a big potential for huge mistakes that would make your extremely App insecure.
I have worked on a library to make it easy to do SSL pinning; it's available at https://github.com/datatheorem/TrustKit and takes care of all the heavy lifting.
I have an asp.net mvc web app that has been running in production for about 4 years. Suddenly since about a week ago, I am getting this error being returned for all calls to 3rd-party secure API's:
System.Net.WebException: The underlying connection was closed: Could
not establish trust relationship for the SSL/TLS secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
This is for calls to SendGrid for sending emails, calls to Azure Blob Storage for uploading of documents, calls to Connect.io for logging.
I have managed to resolve the Azure Blob Storage problem temporarily by changing the connection string to use http instead of https.
Clearly something has broken on my app server, and I have no idea where to start looking.
Please help.
Edit:
Turns out I was using a sample library provided by one of my (lesser-used) 3rd party API's, and this library had an override of
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors)
which had it's own logic about what constitutes a valid certificate!!! AARGH!
This part become key information for your problem:
I am getting this error being returned for all calls to 3rd-party
secure API's
According to MSDN blog:
This error message is caused because the process is not being able to
validate the Server Certificate supplied by the Server during an HTTPS
(SSL) request. The very first troubleshooting step should be to see
if the server supplied certificate and every certificate in the chain
is trouble free.
Because it seems that one or more third party certificates are rejected, you may configure Trusted Roots part of your certificate trust lists to include all required third party CA as part of chain to work with secure APIs from trusted sources, including reissued certificates if any.
Further details: https://technet.microsoft.com/en-us/library/dn265983.aspx
NB (Optional):
As temporary measure, you can implement this certificate validation handler in WebRole.cs until all related third-party certificates has reissued (remember this setting will trust all issued certificates, hence it's not recommended for long term usage):
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
Additional reference: http://robertgreiner.com/2013/03/could-not-establish-trust-relationship-for-the-ssl-tls-secure-channel/
Similar thing happened in our system. Our problem was TLS version. The SSL offload appliance was configured to accept only TLS 1.2. One week ago this configuration accepted all TLS versions 1.0 to 1.2.
We had to reconfigure .NET's SecurityProtocol settings like:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
You can use this site to test which TLS version you are using: https://www.ssllabs.com/ssltest/index.html
Try to get some information about the certificate of the servers and see if you need to install any specific certs.
The server(s) may had a cert signed by a 3rd party CA which you hadn't trusted yet. The solution is to add that CA to the Trusted Root CA list.
As per my understanding, SSL Pinning is to compare the public key or certification of a server with the copies bundled in the client beforehand.
I saw in Stackoverflow that many developers use SSL Pinning by AFNetwork libraries, but most of them use it along with a self-signed certificate.
I have bought a valid certificate from a CA and passed the test to verify it worked fine. I mean, I set the following and it worked
...
_sharedHttpsInstance.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
_sharedHttpsInstance.securityPolicy.allowInvalidCertificates = NO;
...
What I am wondering is that if set the Pinning mode to AFSSLPinningModePulicKey, my application would be more secure in communication with the server in addition to what the valid certificate have provided?
thanks a lot.
I'm don't know the exact implementation of SSL pinning in iOS, but in principle pinning provides definitely more security than the default verification against a set of builtin certificate agencies. By default systems trust more than 100 different CA from all over the world and each of the CA has the ability to issue any certificate it wants, even if another CA has already issued the same or a similar certificate. So if any of these 100+ CAs gets compromised they can issue a certificate for your domain, which would pass the checks in your application unless you use certificate pinning. Such compromises happened in 2011 with DigiNotar (no longer existent because of that) and Comodo (was too big to fail).
Probably the most prominent user of certificate pinning is Google Chrome, where it is used for the google domains and this helped to detect the compromises of DigiNotar and Comodo.
A downside of certificate pinning might be, that the application will stop working inside networks which do SSL interception for security reasons. Google Chrome seems to deal with this situation by accepting the certificate if it is signed by a CA explicitly added by the user (i.e. no builtin) alternatively to the pinning checks.
Another question which might be interesting is if SSL pinning is secure 'ENOUTH' for 'Most' of the application, even if working along with self-signed certification?
Checking against a fixed certificate or public key (e.g. certificate pinning with or without self-signed) is more secure than only checking if the certificate is signed by any of the 100s CAs trusted by the system. And as long as the developer has full control about both sides (e.g. application and server) it also scales well. The only advantage of additionally using the usual infrastructure is the use of the certificate revocation mechanism. But because the developer has control of the application (s)he could just replace the appplication in case the certificate gets compromised. So yes, in most cases it is secure enough do do SSL pinning with a self-signed certificate and it is more secure than using the standard certificate validation without pinning.
It's very difficult to say categorically whether pinning is better or worse, since it shifts the risk to a different party.
Pinning will essentially protect you better against a potential breach in any of the CA you trust. If a CA is compromised and made to issue a certificate for the host you're trying to contact, pinning will protect you against that because you will compare with the specific reference you've pinned, instead of going through the CA.
The downside is that it will prevent you from using the mechanisms in place at the CA to deal with a compromised host: certificate revocation. If the host's private key is compromised, going through the PKI verification mechanism should allow you to check for revocation, and be warned that such a problem happen. In contrast, you won't be able to know that with pinning, since you're not going through the CA to check the certificate at all.
Of course, you could combine both approaches, but this could cause additional problems (you'd need a strategy to deal with conflicting outcomes in both evaluations, otherwise a compromised CA revoking a valid cert could cause a DoS).
I don't know whethet AFNetworking's pinning mechanism replaces the PKI validation or complements it.
In general, choosing between using pinning or PKI validation depends on whether you think that particular host's private key is more or less likely to be compromised than the CAs you trust.
Another downside of pinning is that you need to update the application (or let the user "re-pin") every time the server certificate (or at least the key-pair, depending on what you've pinned) is changed legitimately. It's probably not a bad idea to re-key once in a while.
(To be clear, I'm not saying that CAs are better, just that pinning changes the set of problems.)
I have seen many examples on verifying client or server certificates using Security framework APIs but this will solve only problem of Identification of security features but what about Confidentiality of data? How do I exchange private and public keys between client and server? What about Interception, Modifications, or Fabrication attacks? What if someone pretending and sending correct certificate as expected by client?
Identification is provided by verifying the cert as you note. Confidentiality is provided via encryption. Authentication is provided by signing the data. Together they are often implemented via TLS over a network connection.
In short, if you properly implement and deploy HTTPS, and validate your certificates, then you will get all of the things you're describing. NSURLConnection will do almost all of this for you by default if you just use an "https" URL.
If you deploy a certificate on the server and protect its private key, then it is not feasible for an attacker to pretend to have that certificate. Only the server has the server's private key (it is up to you to protect the private key from copying or theft).
A typical approach is to use a commercial certificate, in which a certificate authority (CA) like Verisign attests that the private key was issued to the owner of a given host (known as the CN or common name). This is a simple-to-use approach and generally cost effective. Go to one of the well-known CAs and buy a cert.
However, you can also create your own public/private server keypair, protect the private key, and distribute the public key in your client. You can then configure your client to only accept that one certificate and no others. This is actually more secure than the commercial certificate. For an example of this, see SelfCert. This is from my CocoaConf-RTP-2012 talk. I'll be giving a similar talk at CocoaConf-DC-2013. It is also discussed at length in chapter 15 of iOS:PTL.
Client certificates are less common. They are used to authenticate the client, not the server. For a client certificate to work correctly, each client must have its own certificate. You can't ship a private key as part of your bundle. If you do, anyone can use that private key to impersonate a client. (Conversely, it is completely fine to put the server's public key in the bundle. It's public; you don't care who sees it.)
With CFNetwork, after connecting, you would need to use CFReadStreamCopyProperty to fetch the kCFStreamPropertySSLPeerTrust. You could then evaluate the returned SecTrust object. That said, I recommend the NSURLConnection code if you can use it. If you need lower-level access, you could still use NSStream. Jeff Lamarche discusses this in NSStream: TCP and SSL. But I'd recommend a tool like AFNetworking or CocoaAsyncSocket instead if you need lower-level control over TCP+SSL.