[TriLUG] Semi-OT: Detecting HTTPS inspection? Does that compromise SSH?

Igor Partola igor at igorpartola.com
Mon Jun 2 16:52:36 EDT 2014


Matt and Chris are correct. Here's the problem with SSL/TLS and the way
HTTPS uses it:

Any domain name can be signed by any CA. Crazy, right? So your OS (or your
browser, depending on the implementation), comes with a bundled trusted set
of CA's. There is also a mechanism for adding additional CA's. This is
often used in corporate environments for something like
foo.bar.example.lan. Nobody is going to issue you a certificate for that
non-Internet domain name, but you still need to secure internal
communication with it, so you create a CA and then issue a cert to the
admin who is running foo.bar.example.lan.

I am sure now you can see the problem with the above: anybody, good or bad,
on purpose or by mistake can give someone a certificate to your domain name
and as long as the user/victim has that CA certificate in their trusted
certificate bundle, nobody would suspect a thing. This has been done by
mistake many a times, but it's also been done by governments state-wide.
This should make you very scared.

One solution to this is to pin certificates. Basically, your browser will
cache the certificate, or rather its fingerprint, and if that changes will
notify you. This does not protect you the first time you connect to a new
host, but it does protect you in the future. See
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning for more.

Another solution is to put on your tinfoil hat, abandon HTTPS and attempt
to build a web of trust based solution where you trust nobody but the
people you have met in person. Thus, to use google.com you better get their
public key in person from one of the Google engineers. This of course could
be automated to an extent, but in the long run I don't believe it will be
sustainable.

Igor


More information about the TriLUG mailing list