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

[matt at noway2.thruhere.net]

> Hi!
>
> So I've recently heard our IT group say they're using HTTPS packet
> inspection (!).  So a question that immediately comes to my
> less-than-expert mind is, "are they compromising my SSH traffic?"
>
> Reading that I've done so far suggests that HTTPS inspection is achieved
> via a MITM attack; doing so without detection involves various
> manoeuvres involving CAs and such.  So my browser could be quietly
> accepting the MITM-ed HTTPS sessions if IT has already told it to accept
> the different cert.
>
> Seems like a MITM attack could also be used with an SSH session, but I
> don't know enough about it to feel certain.  What I've done so far is
> verify that my client does see the correct RSA fingerprint of the
> intended server.  Is that enough for me to feel confident in the
> security of my SSH tunneled traffic from our IT department's prying eyes?
>
Once or twice, I've experienced where trying to go to an HTTPS page
generated a warning about a changed certificate.  In those instances, I
was in a place like a hotel that used a proxy for web access.  As they
were not able to put a CA certificate on my machine it was not recognized
as being valid and the alterations were caught.

This could be problematic with company machines where root CA certificates
could be installed and could act as a man in the middle.  In order for
this to work, the client (you) machine needs to be told that this 'fake'
certificate is real.

This has historically been the weak link in the "web of trust" regarding
SSL certificates.  You're browser is automatically programmed to recognize
certain certificates as valid if they've been signed by certain parties -
the CA.  See the wiki page on certificate authority:
https://en.wikipedia.org/wiki/Certificate_authority

By putting the CA certificate on your machine, they can then "sign" the
page with their fake certificate and your machine will accept it as valid.
 Depending on how insidious they are they might be able to spoof enough of
the fields, rendering checking the certificate information futile.

With SSH, I assume you established the original connection outside of your
company (suspect) network?  This would have caused the fingerprint hash of
the SSH server to be stored in the client.  If the certificate were forged
or altered you would get a very prominent message about an altered
fingerprint asking you if you wish to trust it.

In other words, as long as you didn't create the initial connection and
accept a fingerprint that could have been compromised then I seriously
doubt that they can decrypt your SSH traffic.  If you did, then you should
be getting warnings if you try to connect via SSH when your NOT behind
their MITM proxy.