1

We recently decided to pay an ISP (a substantial sum, mind) for a managed internet service up to and including the router in our head office.

Part of the initial discussions made it clear that whatever solution the ISP thought was best it had to include a VPN as various members of staff are on the road a lot, coffee shops and trains and the like.

The ISP delivered a VPN solution in the form of Cisco AnyConnect which keeps showing security warnings as the certificate is self-signed. The certificate is also SHA-1.

1) My main question is this. Is this adequate security for a paid-for solution?

2) My second question (although it may be out of place in this area of SE) is this. Is it reasonable to assume the ISP would provide an adequate solution certificate given that the sensitive nature of the data we transmit was divulged to them?

3

Use of SHA-1 is irrelevant here.

The problem with a self-signed certificate is that there is no way for anybody to verify that the certificate is the correct one or not; this is exactly what the client warnings mean. When one of your staff sees the warning, and he clicks through to connect nonetheless, then that user could be connecting to a fake VPN server, ran by an attacker, who could then forward the data to the true server but also inspect it as it goes: a classical Man-in-the-Middle attack.

One may even say that with the self-signed certificate, you are training your staff to disregard warning messages, so, in all generality, you have lowered your security.

One way to fix the problem is to install the VPN certificate as "trusted", explicitly, in each client machine. This means that you instruct the client machine to accept that exact certificate as the right one. The Cisco documentation should tell you how to do it.

Another method is to have the ISP buy and install a certificate obtained from one of the "commercial CA" that existing machines already trust; this is the same kind of certificate as what you need for an https:// Web site that does not insult its users. This is traditionally known as an "SSL certificate" and you can have one for a few dollars per year (even for free with some CA).

  • I'll just add a question-test for the OP to this great answer: If a MITM attacker replaced your self-signed cert with an attacker-generated self-signed cert, how would you know? If your employees installed the real certificate as trusted, you'd know because the attacker's cert is not trusted. If you get a CA-signed cert, you'd know because the attacker's cert is not signed by a CA (or is signed for a different domain). If you don't do either of these things, there's no way to distinguish your real cert from any other. – apsillers Mar 13 '15 at 12:32
  • @ThomasPornin, can you clarify, is SHA-1 irrelevant because it's used to validate the trust chain, and with the self-signed cert there's no trust chain? And if the OP gets a CA certificate then the choice of signature will become relevant and they should look for SHA-256 instead? – gowenfawr Mar 13 '15 at 12:50
  • 1
    SHA-1 is used as a component of the signature algorithm. Here, it is a self-signature that, by definition, nobody verifies, since it proves nothing. So use of SHA-1 does not matter. (Self-signatures on certificates exist because the X.509 format for a certificate calls for a non-optional field for the signature, so such an auto-issued certificate must have something which syntactically looks like a signature; otherwise, many implementations would fail to decode it. That the dummy signature is a self-signature is just Traditional.) – Thomas Pornin Mar 13 '15 at 14:31

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.