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

[Tim Jowers]

And, in windows at least, there's always Fiddler II and that ilk. IIRC,
they can filter before the network layer encrypts the traffic. So, that's a
most probable way to snoop on people. No doubt iOS and Lunix/Android have
this same set of ability. E.g. can't you just strace some program to see
what its doing before the traffic gets encrypted? (never played with that,
so don't know the best way). Apple has a patent on disabling people's
camera's in a "no videotape zone"; so, I'd guess they've thought about how
to filter traffic before its encrypted.

Tim


On Mon, Jun 2, 2014 at 5:04 PM, Aaron Joyner <aaron at joyner.ws> wrote:

> I apologize in advance, I hope what I'm about to say doesn't cause undue
> strife to those who by their tinfoil in bulk, on the off chance they
> haven't considered it before.
>
> Sure, your IT company could MITM you by installing an additional
> certificate.  You could then inspect the list of certificates, look for
> unexpected trusted CAs, and compare the usual trusted CAs against their
> published fingerprints.  That leaves a pretty clean trail for you to
> follow, and a pretty easy way to "undo" their handiwork (although
> presumably you'd still be forcibly connected through an HTTPS proxy, it'd
> just no longer be as "transparent").
>
> Another option would be to run a daemon on your machine which watches
> outgoing traffic for SSL negotiations, then grabs the SSL or TLS session's
> symmetric key and ships that off to the transparent packet forwarder, which
> can then use it to decrypt and inspect your session.  Such a daemon would
> need to know a bit about each application it wanted to snarf the symmetric
> key from, but it's not particularly challenging to cover a handful of apps
> and get nearly universal coverage (eg. Firefox, Chrome, OpenVPN, etc.).  A
> Corp IP policy which limits browser choice would help out a lot there.
>  Naturally, this would just be an undocumented "feature" of one of the
> backup, security-update, virus-scanning, or logging daemons you're
> encouraged to run on your machine as part of the corporate IT policy.
>
> Most people would consider that pretty far off into tin-foil-hat territory,
> but if I wanted to monitor your SSL traffic, that's how I'd do it.
>
> The more logical explanation for your IT department talking about "HTTPS
> packet inspection" would be that they're just monitoring the bandwidth
> associated with HTTPS traffic flows, and if it looks like a lot more bits
> are flowing out than the bits that are flowing in, they might investigate
> more thoroughly.  This would be a first-pass attempt against ensuring
> you're not uploading the company's code base via HTTPS to github or similar
> offsite "backup" for your personal use, or later sale to a competitor.
>
> Assuming the latter, your online banking data is "safe".  Even assuming the
> former, your online banking data is probably safe.  It's unlikely they're
> going to start transferring your funds to their personal account, and it's
> unlikely they mind that you're checking your bank balance or paying the
> occasional bill at work (so long as you're not also underperforming at the
> task they're paying you for).
>
> Happy computing!
> Aaron S. Joyner
>
>
> On Mon, Jun 2, 2014 at 5:59 PM, Alan Porter <porter at trilug.org> wrote:
>
> >
> >  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
> >>
> >
> > There is a plugin called "Certificate Patrol" that is supposed to do
> this.
> >
> > I installed this plugin at work right before Oracle acquired my company,
> > thinking that it would tell me if Oracle IT was playing MITM.  However,
> > all of the tests that I ran using my own domains and my own CA's were
> > inconclusive... it never warned me when I changed my own certificates.
> >
> > Alan
> >
> >
> >
> > --
> > This message was sent to: Aaron S. Joyner <aaron at joyner.ws>
> > To unsubscribe, send a blank message to trilug-leave at trilug.org from
> that
> > address.
> > TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> > Unsubscribe or edit options on the web  : http://www.trilug.org/mailman/
> > options/trilug/aaron%40joyner.ws
> > Welcome to TriLUG: http://trilug.org/welcome
> >
> --
> This message was sent to: timjowers <timjowers at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  :
> http://www.trilug.org/mailman/options/trilug/timjowers%40gmail.com
> Welcome to TriLUG: http://trilug.org/welcome
>