25

I am building a client application that will consume a web-service application provided by a third party service provider. The service is exposed with a HTTPS URL that is not signed by a trusted certificate authority.

Is it secure to consume their services with the current situation? Note that the service provider company is known to us and we have a business agreement with them.

  • 1
    I guess it is signed by some CA related to the service provider though? – Marcel Mar 27 '17 at 11:41
  • 33
    On a related note: Google takes Symantec to the woodshed for mis-issuing 30,000 HTTPS certs ... so maybe it's just a valid to ask if it's "secure" to consume services over HTTPS which are signed by a trusted CA... – HopelessN00b Mar 27 '17 at 14:18
  • 7
    URLs aren't signed by certificate authorities. – user253751 Mar 27 '17 at 21:13
  • 1
    Since they already set up HTTPS, can't they just have a generally trusted CA sign their certificate? That should be cheap or free and simple enough. – David Foerster Mar 28 '17 at 8:43
  • @DavidFoerster Third party company will purchase the new certificate signed by trusted CA after we rise the issue with them. – Salman Apr 3 '17 at 4:32
40

You can use it safely if you pin their certificate. This adds complexity to the maintenance and deployment but it does actually improve security.

If you do not, then it depends on how they built their trust chain: if they are only using self-signed certificates, then you're out of luck and can't securely use their services. If they just use a private CA, you can still import their CA and trust it.

Overall, I would recommend you implement certificate (or root) pinning.

Edit @LieRyan made a good comment that I'd like to expend on.

In some configuration, pinning a certificate will require your to add it to the machine's root anchors lists. For instance, this is required if you're using IIS on Windows to host your application.

Now, depending on how the certificate was generated, this might be or might not be an issue. Specifically: if the certificate does have a "key usage" property and if that property does NOT list "Certificate Signing", then it can safely be used because it can't be used to sign other certificates (details are a bit more complex but that is the most important one).

If the certificate does NOT have a "key usage" property or if that property has "certificate signing", then it could potentially lead to other certificates signed by that cert to be trusted by the OS. If you implemented certificate pinning, that should not be an issue for your app (since pinning will prevent even otherwise valid certs to be used) but it might be for other part of the OS.

  • 8
    Self signed certificate can be pinned or stored in your certificate store. Using self signed certificate does make replacing certificates more complex, but you don't actually need a CA to securely communicate provided that you have a way to verify the identity of the other party. – Lie Ryan Mar 27 '17 at 13:22
  • 2
    To avoid some of these challenges, the third-party could act as a CA. This would reduce the effort associated with certificate expiration. – JimmyJames Mar 27 '17 at 14:05
  • Is pinning essentially what ssh does? Why it warns about the host key on first connection and if the host key for an address changes? – Captain Man Mar 27 '17 at 14:51
  • 1
    Been there, done that. Cert pinning works great. In fact I trust it better than importing their root. – Joshua Mar 27 '17 at 19:04
  • 1
    @LieRyan: One problem with the latter is that some OSes start to trust the cert as a CA... – user1686 Mar 28 '17 at 5:21
26

Is it secure to consume their services with the current situation ?

That's a loaded question. Let me break it down:

Can I communicate with them securely, in a way that cannot be intercepted by any third party?

Yes, you can. However, you'll need to do key exchange ceremony and identity verification manually instead of depending on the CA to do so. This can be done for example by having trusted representative(s) from each company meet regularly to exchange identifying information and to exchange keying materials (certificates). The security of your connection depends on the security of this exchange, so you need to make sure you secure such exchange with the right level of security.

Can I trust this company to not scam me?

That's a legal issue. Note that even public CA don't actually make this assertion. All that a public CA does is assert that a key belongs to a specific organization, they don't assert the morality of the company they certify. You may want to ensure you have contracts over what kind of services you are going to provide each other, and whether you need any payments to be settled, and what happens if one party unilaterally breaks contract.

Can I trust this company to be competent in managing their security, to avoid undue losses?

That's also a difficult question. You'd want to ensure your contract specified what happens if the other party is unable to fulfill their security requirements and caused losses to other of you. You may also want to demand the other company to produce an audit certificate by an independent financial and/or security auditor.

  • 2
    This is missing the obvious. (Can you trust that you are communicating with them and not an impostor? No, unless you do some sort of pinning.) – Tgr Mar 28 '17 at 7:06
  • 1
    @Tgr: pinning is covered under the first section of my answer. Doing a key pinning is simply one way to "exchange keying materials", which uses the TOFU model instead of properly authenticating the certificate. – Lie Ryan Mar 28 '17 at 10:21
6

As always, this is about you trusting the provider of that service.

In this case you can not relay on a globally known CA (Certificate Authority) to ensure the trust, which is questionable anyway.

You should, as always, when connecting, check the issuer of the certificate (the CA), and whether you trust that CA via your local store. If you trust the locally stored CA's certificate this is no less safe than (or even safer than) using a 3rd party CA.

2

The risk of using a self signed certificate is to the client. SSL certificates are used by client to know servers public key which is later used for encryption. Using a certificate signed by trusted CA guarantee the client, that the key belongs to the intended server.

When a client accepts a certificate that is not signed by a trusted CA, then there is risk of client talking to a fake server(man-in-middle attack comes here). If the client confirms that the certificate is genuine for one time, then the browser will remember the certificate and will not show warning for next visit.

It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten).

So it is recommended to use certificates signed by trusted CA. If you cant afford to get a certificate from CA then its better to go for Certificate Pinning as suggested in stephane answer.

  • At least Firefox will allow you to delete a saved certificate, so the clients can do that if the private key is stolen. – Martin Bonner supports Monica Mar 27 '17 at 13:49
  • Yes, it is possible to delete a saved certificate by client in browser, if the server intimates the client that its private key was stolen.But What if the client doesnt comes to know that the private key is stolen. – jey Mar 27 '17 at 13:57
1

Your question can end in can I trust a HTTPS URL that is not signed by a trusted certificate authority?

IMHO, it is not exactly the correct question. I would prefere What can ensure that I consult the right service? The difference is not simply wording. It is in what you can and want to trust. The answer to the first question is immediately the service should use a certificate from a well known CA. The answer to the second is I must know the certificate or certificate authorithy of the service, but that certificate can be a self-signed one provided the service gives it by an alternate channel. Then you just declare that certificate or any self-signed certificate that would validate it in the application configuration and you can trust it.

0

It is not the consumption of the service that gives you security (authenticity), it is instead the awareness of how you verify the certificate received from the server that makes you sure of the authenticity.

The fact that you are asking shows the level of security you have: passive user wanting to move up in security.

The use of a known (by the OS) CA makes the consumption of a signed certificate secure to any passive user, because the trusted system can warn with precise information for any sign of possible non authenticity (explaining the "possible" in well understood condition), or no warning if all is fine (or the whole system is compromised, which is out of scope).

You said that you are "building an application" despite the application itself could technically contain any public key for comparison and behave securely (being capable to verify authenticity). As a developer, I'm noticing a recent tendency to obstacle in the provided library and public application approval process, even more than necessary, self-signed CA (where self is well defined), e.g. this emerge in https://stackoverflow.com/questions/30337322/how-do-i-register-my-own-root-certificate-authority-in-swift

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.