0

My organisation is concerned about viruses and attacks coming into our network.

Since http traffic has been declared persona non grata by some browser makers and other parties, it becomes increasingly difficult to perform such function.

As many sites nowadays block http:// access (instead simply redirecting to their https:// version), we're forced to do MitM to continue our scans effectively.

Which means that we must perform certificate authentication on a central basis, since it'll be our proxy that'll be doing the client-side TLS.

Not desiring to block self-signed certs of third parties, in such MitM setup, is there anything we can do to ensure our users can distinguish between downstream websites with self-signed and CA-based certificates? E.g., if our upstream themselves does a MitM on our traffic, is there a way for us to let our user know, without blocking the connection (e.g., let them decide)?

cnst
  • 1,884
  • 2
  • 19
  • 30

1 Answers1

1

I don't think it is a good idea to let users decide which certificates are nice and which are not or to accept self-signed or invalid certificates at all on a general basis. At least I do not believe that most users understand the underlying problems and would be able to make the proper decision. But maybe all your users have a deeper understanding of the topic and of the problems involved when making the wrong decision, so here is a way to transfer at least part of this information to the user:

  • For proper TLS connections which have a valid certificate the new certificate generated on the SSL interception device will be signed by the proxy CA of the device. This way no warnings in the browser occur as long as the proxy CA is imported as trusted.
  • TLS connections with an invalid certificate (expired, wrong subject, self-signed...) instead will not be signed by the proxy CA but a self-signed certificate will be created which will contain most of the original information (subject, expiration...). This will result in a warning inside the browser because it is not signed by a trusted CA and the user can look at the certificate details and decide to accept it anyway.

This way only valid certificates are silently accepted by the browser and all the others need manual intervention of the user. Note that I'm pretty sure that not all SSL interception devices will deal with invalid certificates the way I've described so you should check the details with the specific product or implementation you have in mind. Also, not all information about the reasons why a certificate was invalid are transferred this way. Especially you cannot distinguish between originally self-signed certificates and certificates with an otherwise broken trust chain (like missing chain certificates or untrusted root CA) this way and you have no way to look at the original issuer of the certificate.

But again, I don't recommend to fully trust users to decide what are good and bad certificates, so this practice should be restricted to only a few bad sites. From my experience the only valid self-signed certificates you have are for local devices (router etc) and thus should usually not be affected by SSL interception at all. Public sites on the internet instead should use public CA's and almost all do it. If they don't do it or do it wrong than these sites should better be blocked. From my experience the common sites on the internet will not cause any problems because this would cause problems in the browsers too and they would loose visitors this way.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • A lot of sites do use https with certs by CAcert, which is not generally trusted, for example, undeadly.org, part of the OpenBSD community; outright blocking all such sites surely wouldn't be ideal. – cnst Dec 12 '15 at 07:30
  • 1
    @cnst: if you trust CAcert then you could simply add it as a trusted CA in the SSL interception device. This way no users will see any problems. What you cannot do with SSL interception is to have individual trust settings for each user because the trust chain is validated on the interception device. – Steffen Ullrich Dec 12 '15 at 07:31
  • I would also not say that a lot of sites use CAcert because this would only mean problems for the site. The inclusion status for this root CA is marginal: It was never included in a major browser and it got removed from Debian and even OpenBSD because they were not able to provide the necessary security audits which all CA should have. See also http://wiki.cacert.org/InclusionStatus – Steffen Ullrich Dec 12 '15 at 07:39
  • To have the record straight, the only reason it was removed from OpenBSD was because CAcert's root certificate apparently didn't have a free licence! – cnst Dec 12 '15 at 07:52
  • @cnst: the process is not very transparent but there were [discussions before](http://openbsd-archive.7691.n7.nabble.com/Please-remove-CAcert-org-certificate-from-rootcerts-td237820.html) so it might have been that the argument with the license only finally sealed it. But anyway, anybody needing a certificate trusted by a larger number of users did never use CAcert because it never was trusted by enough clients. – Steffen Ullrich Dec 12 '15 at 08:19
  • The link you provide doesn't support your rhetoric -- people basically say that CAcert is not any more or less trustworthy than any of the other CAs. – cnst Dec 12 '15 at 10:12
  • @cnst: let's concentrate on the fact that CAcert never established itself as a serious choice if you were looking for a CA, no matter what each of us reads out of the various discussions. – Steffen Ullrich Dec 12 '15 at 10:16